この概要ページでは、Google Distributed Cloud（GDC）エアギャップで、ゾーン ネットワーク構成とグローバル ネットワーク構成の両方に対して内部ロードバランサと外部ロードバランサを構成する方法について説明します。
GDC のロード バランシングにより、バックエンド ワークロード間でトラフィックを効率的に分散し、アプリケーションの可用性とパフォーマンスを向上させることができます。トラフィックの分散に使用されるアルゴリズムは Maglev です。詳細については、ロード バランシング アルゴリズムをご覧ください。
このページは、組織のネットワーク トラフィックの管理を担当するプラットフォーム管理者グループのネットワーク管理者、またはアプリケーション オペレーター グループの開発者を対象としています。詳細については、GDC エアギャップの対象読者に関するドキュメントをご覧ください。
ロード バランシングのアーキテクチャ
GDC は、アプリケーションがサービスを相互に公開できるようにするロードバランサを提供します。ロードバランサは、一連のバックエンド ワークロード間でトラフィックを分散する安定した仮想 IP（VIP）アドレスを割り当てます。GDC のロードバランサはレイヤ 4（L4）ロード バランシングを実行します。つまり、構成された一連のフロントエンド TCP ポートまたは UDP ポートを対応するバックエンド ポートにマッピングします。ロードバランサはプロジェクト レベルで構成されます。
ロードバランサは、次のワークロード タイプ用に構成されています。
- VM で実行されているワークロード。
- Kubernetes クラスタ内のコンテナ化されたワークロード。
GDC でロードバランサを構成するには、次の 3 つの方法があります。
- Networking Kubernetes Resource Model（KRM）API を使用します。この API を使用して、グローバル ロードバランサまたはゾーン ロードバランサを作成できます。
- gdcloud CLI を使用します。この API を使用して、グローバル ロードバランサまたはゾーン ロードバランサを作成できます。
- Kubernetes クラスタから Kubernetes Service を直接使用します。このメソッドは、ゾーン ロードバランサのみを作成します。
ロードバランサ コンポーネント
KRM API または gdcloud CLI を使用してロードバランサを構成する場合は、L4 パススルー ロードバランサを使用します。
- L4 は、プロトコルが TCP または UDP のいずれかであることを意味します。
- パススルーとは、ワークロードとクライアントの間にプロキシがないことを意味します。
ロードバランサは、次の構成可能なコンポーネントで構成されています。
転送ルール: 転送するトラフィックと、その転送先のバックエンド サービスを指定します。転送ルールの仕様は次のとおりです。
- クライアントがアクセスするための 3 つのタプル（CIDR、ポート、プロトコル）で構成されます。
- TCP プロトコルと UDP プロトコルをサポートします。
- 内部転送ルールと外部転送ルールを提供します。クライアントは、Virtual Private Cloud（VPC）内から内部転送ルールにアクセスできます。クライアントは、GDC プラットフォームの外部から、または
EgressNAT値が定義されたワークロードによって内部から外部転送ルールにアクセスできます。 - 転送ルールはバックエンド サービスに接続します。複数の転送ルールで同じバックエンド サービスをポイントできます。
バックエンド サービス: 転送ルール、ヘルスチェック、バックエンドをリンクするロード バランシング ハブです。バックエンド サービスは、ロードバランサがトラフィックを転送するワークロードを識別するバックエンド オブジェクトを参照します。1 つのバックエンド サービスが参照できるバックエンドには制限があります。
- ゾーンごとに 1 つのゾーン バックエンド リソース。
- クラスタごとに 1 つのクラスタ バックエンド リソース。プロジェクト バックエンドと混在させることはできません。
バックエンド: 作成されたバックエンド サービスのバックエンドとして機能するエンドポイントを指定するゾーン オブジェクト。バックエンド リソースはゾーンにスコープ設定する必要があります。ラベルを使用してエンドポイントを選択します。セレクタのスコープをプロジェクトまたはクラスタに設定します。
プロジェクト バックエンドは、
ClusterNameフィールドが指定されていないバックエンドです。この場合、指定されたラベルは、特定のプロジェクトの特定の VPC 内のすべてのワークロードに適用されます。ラベルは、複数のクラスタにわたる VM と Pod のワークロードに適用されます。バックエンド サービスがプロジェクト バックエンドを使用する場合、そのバックエンド サービスでそのゾーンの別のバックエンドを参照することはできません。クラスタ バックエンドは、
ClusterNameフィールドが指定されているバックエンドです。この場合、指定されたラベルは、指定されたプロジェクト内の名前付きクラスタ内のすべてのワークロードに適用されます。1 つのバックエンド サービスで、クラスタのゾーンごとに最大 1 つのバックエンドを指定できます。
ヘルスチェック: バックエンドの特定のワークロード エンドポイントが正常かどうかを判断するプローブを指定します。正常でないエンドポイントは、再び正常になるまでロードバランサから除外されます。ヘルスチェックは VM ワークロードにのみ適用されます。Pod ワークロードは、組み込みの Kubernetes プローブ メカニズムを使用して、特定のエンドポイントが正常かどうかを判断できます。詳細については、ヘルスチェックをご覧ください。
Kubernetes ユーザー クラスタから Kubernetes Service を直接使用する場合は、前に説明したコンポーネントではなく Service オブジェクトを使用します。ターゲットにできるのは、Service オブジェクトが作成されたクラスタ内のワークロードのみです。
外部ロード バランシングと内部ロード バランシング
GDC アプリケーションは、次のネットワーキング サービスタイプにアクセスできます。
- 内部ロードバランサ（ILB）: 組織内の他のクラスタにサービスを公開できます。
- 外部ロードバランサ（ELB）: 外部ワークロードからルーティング可能な範囲から仮想 IP（VIP）アドレスを割り当て、GDC 組織外のサービス（GDC インスタンスの内外の他の組織など）を公開します。ELB にセッション アフィニティを使用して、クライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。
グローバル ロードバランサとゾーン ロードバランサ
グローバル ロードバランサまたはゾーン ロードバランサを作成できます。グローバル ロードバランサのスコープは、GDC ユニバース全体に及びます。各 GDC ユニバースは、相互接続され、コントロール プレーンを共有するリージョンに編成された複数の GDC ゾーンで構成できます。たとえば、それぞれ 3 つのゾーンがある 2 つのリージョンで構成されるユニバースは、us-virginia1-a、us-virginia1-b、us-virginia1-c と eu-ams1-a、eu-ams1-b、eu-ams1-c のようになります。
ゾーン ロードバランサのスコープは、作成時に指定されたゾーンに限定されます。各ゾーンは独立した障害ドメインです。ゾーンは、ローカル コントロール プレーンを使用するインフラストラクチャ、サービス、API、ツールを管理します。
GDC ユニバースのグローバル リソースとゾーンリソースの詳細については、マルチゾーンの概要をご覧ください。
グローバル ロードバランサは、次の方法で作成できます。
- Networking Kubernetes Resource Model（KRM）API を使用します。API バージョン
networking.global.gdc.googを使用してグローバル リソースを作成します。 - gdcloud CLI を使用します。gdcloud CLI コマンドを使用してグローバル スコープを指定する場合は、
--globalフラグを使用します。
ゾーン ロードバランサは、次の方法で作成できます。
- Networking Kubernetes Resource Model（KRM）API を使用します。API バージョン
networking.gdc.googを使用して、ゾーンリソースを作成します。 - gdcloud CLI を使用します。gdcloud CLI コマンドを使用してロードバランサを作成するゾーンを指定する場合は、
--zoneフラグを使用します。 - Kubernetes クラスタから Kubernetes
Serviceを直接使用します。
サービス仮想 IP アドレス
ILB は、組織内でのみ使用される VIP アドレスを割り当てます。これらの VIP アドレスは組織外から到達できないため、組織内の他のアプリケーションにサービスを公開する場合にのみ使用できます。これらの IP アドレスは、同じインスタンス内の組織間で重複する可能性があります。
一方、ELB は組織外から外部にアクセス可能な VIP アドレスを割り当てます。そのため、ELB VIP アドレスはすべての組織間で一意である必要があります。通常、組織で使用できる ELB VIP アドレスの数は少なくなります。
ロード バランシング アルゴリズム
Google のロードバランサは、コンシステント ハッシュ法アルゴリズムである Maglev を使用して、着信トラフィックをバックエンド ターゲットに分散します。このアルゴリズムは、高パフォーマンスと復元力を実現するように設計されており、トラフィックが均等かつ予測可能に分散され、バックエンドのデータ局所性が最大化されます。
Maglev の仕組み: ハッシュ メカニズム
Maglev は、各受信パケットのプロパティをハッシュ化して転送の決定を行います。これにより、特定の接続のすべてのパケットが同じバックエンドに一貫して送信され、データ局所性が最大化されます。
- ハッシュ入力（5 タプル）: アルゴリズムは、パケットのヘッダーから標準の 5 タプルを使用してハッシュを生成します。このタプルは次の要素で構成されます。
- 送信元 IP アドレス
- 送信元ポート
- 宛先 IP アドレス
- 宛先ポート
- プロトコル（TCP、UDP など）
- 転送の決定: このハッシュの結果により、接続がロード バランシング プール内の正常なバックエンドのいずれかに決定論的にマッピングされます。その接続の存続期間中、すべてのパケットが同じバックエンドに転送されます。
- バランシングのエントロピー: タプルの 5 つの要素すべてを使用することで、Maglev は十分なエントロピーを生成し、使用可能なすべてのバックエンドに異なる接続が均等に分散されるようにします。
バックエンドの正常性と障害の処理
Maglev は、利用可能なバックエンドのセットが変更されたときに復元力を発揮し、中断を最小限に抑えるように設計されています。
- バックエンドの障害: バックエンドがヘルスチェックに失敗すると、使用可能なターゲットのリストから削除されます。以前に失敗したバックエンドに転送された接続は終了します。新しい接続は、ハッシュ アルゴリズムに基づいて、残りの正常なバックエンド間で自動的に再分配されます。重要なのは、他の正常なバックエンドへの接続は影響を受けず、再ルーティングされないことです。
- バックエンドの復元: 正常でないバックエンドが再び正常になり、プールに追加されると、ハッシュの一貫性により、このバックエンドが最小限の中断でプールに追加されます。LB は、この新しく正常になったバックエンドを使用して負荷の再調整を行います。この「最小限の中断」アプローチにより、既存のすべての接続の大規模な再シャッフルを防ぎます。再シャッフルを行うと、アプリケーションのキャッシュや状態が過負荷になる可能性があります。
マルチゾーン デプロイでの動作
Maglev はトポロジを認識しないことを理解することが重要です。バックエンドの物理的な場所やネットワーク パスを考慮せずに、ハッシュの数学的な結果のみに基づいてトラフィックを分散します。
- ロケーションに関係なく均等に分散: Maglev は、プール内のすべてのバックエンドを同等のターゲットとして扱います。バックエンドが異なるゾーンに分散している場合、トラフィックはすべてのバックエンドに均等に分散されます。アルゴリズムは、「ローカル」ゾーンのバックエンドを優先したり、ゾーン間のネットワーク レイテンシを考慮したりしません。
- MultiZone Interconnect の容量を確保する:バックエンドは複数のゾーンにまたがることがあるため、ネットワーク管理者は、MultiZone Interconnect にロードバランサ ノードとバックエンド間のクロスゾーン トラフィックを処理するのに十分なネットワーク容量があることを確認する必要があります。
制限事項
BackendServiceリソースは、Pod ワークロードのHealthCheckリソースで構成しないでください。BackendService仕様のHealthCheckNameは省略可能であり、Pod を使用してロードバランサを構成する場合は省略する必要があります。ロードバランサ構成は、Pod と VM を含む混合ワークロードをターゲットにできません。したがって、1 つの
BackendServiceリソースに Pod と VM を含む混合バックエンドは許可されません。ForwardingRuleExternal、ForwardingRuleInternal、BackendService、HealthCheckなどのグローバル ロードバランサ カスタム リソースの名前は、これらのゾーン ロードバランサ カスタム リソースと同じ名前にすることはできません。組織は、その組織が存在するゾーンごとに最大 500 個の転送ルールを定義できます。グローバル転送ルールは、すべてのゾーンでこの上限にカウントされます。
標準クラスタの制限事項
Standard クラスタのロード バランシングには、次の制限が適用されます。
単一クラスタ スコープ
単一クラスタ スコープ:
Service type=LoadBalancerリソースを使用して標準クラスタ用にプロビジョニングされたロードバランサ（ILB または ELB）は、その単一の標準クラスタ内にのみ存在する Pod であるバックエンド エンドポイントをターゲットにする必要があります。複数の異なる標準クラスタ、または標準クラスタと共有クラスタの混在にわたって実行されている Pod にトラフィックを分散しようとする単一のロードバランサ定義はサポートされていません。標準クラスタでは、gdcloud CLI と Networking Kubernetes Resource Model API はサポートされていません。標準の Kubernetes
Serviceリソースとtype=LoadBalancerおよび関連するアノテーションを使用して、標準クラスタのロード バランシングを管理します。プロジェクト スコープのロードバランサは標準クラスタを無視します。 gdcloud CLI コマンドまたは Networking Kubernetes Resource Model API を使用してプロジェクト スコープのロードバランサ構成を作成すると、プロジェクト内の標準クラスタは無視されます。
グローバル ロード バランシングは対象外です。Standard クラスタ用にプロビジョニングされた ILB リソースと ELB リソースは、単一のゾーンにスコープ設定されたゾーンリソースです。標準クラスタ ロードバランサでは、グローバル ロード バランシングはサポートされていません。
クロスゾーン ILB 接続はサポートされていません。標準クラスタ Pod から別のゾーンのグローバル ILB またはゾーン ILB への接続はサポートされていません。