この概要ページでは、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 クラスタは無視されます。
グローバル ロード バランシングはサポートされていません。Standard クラスタ用にプロビジョニングされた ILB リソースと ELB リソースは、単一のゾーンにスコープ設定されたゾーンリソースです。標準クラスタ ロードバランサでは、グローバル ロード バランシングはサポートされていません。
クロスゾーン ILB 接続はサポートされていません。標準クラスタ Pod から別のゾーンのグローバル ILB またはゾーン ILB への接続はサポートされていません。