この概要ページでは、Google Distributed Cloud（GDC）エアギャップで、ゾーン ネットワーク構成とグローバル ネットワーク構成の両方に対して内部ロードバランサと外部ロードバランサを構成する方法について説明します。
GDC のロード バランシングにより、バックエンド ワークロード間でトラフィックを効率的に分散し、アプリケーションの可用性とパフォーマンスを向上させます。
このページは、組織のネットワーク トラフィックの管理を担当するプラットフォーム管理者グループのネットワーク管理者、またはアプリケーション オペレーター グループの開発者を対象としています。詳細については、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）: 外部ワークロードからルーティング可能な範囲から 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 アドレスの数は少なくなります。
制限事項
BackendServiceリソースは、Pod ワークロードのHealthCheckリソースで構成しないでください。BackendService仕様のHealthCheckNameは省略可能であり、Pod を使用してロードバランサを構成する場合は省略する必要があります。ロードバランサ構成は、Pod と VM を含む混合ワークロードをターゲットにできません。したがって、1 つの
BackendServiceリソースに Pod と VM を含む混合バックエンドは許可されません。グローバル ロードバランサ カスタム リソース（
ForwardingRuleExternal、ForwardingRuleInternal、BackendService、HealthCheck）の名前は、これらのゾーン ロードバランサ カスタム リソースと同じにしないでください。次のステップ