Google Distributed Cloud（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 Service を直接使用する場合は、前に説明したコンポーネントの代わりに Service オブジェクトを使用します。ターゲットにできるのは、Service オブジェクトが作成されたクラスタ内のワークロードのみです。
外部ロード バランシングと内部ロード バランシング
GDC アプリケーションは、次のネットワーキング サービス タイプにアクセスできます。
- 内部ロードバランサ（ILB）: 組織内の他のクラスタにサービスを公開できます。
- 外部ロードバランサ（ELB）: 外部ワークロードからルーティング可能な範囲から VIP アドレスを割り当て、GDC 組織外のサービス（GDC インスタンスの内外の他の組織など）を公開します。
サービス仮想 IP アドレス
ILB は、組織内でのみ使用される VIP アドレスを割り当てます。これらの VIP アドレスは組織外から到達できないため、組織内の他のアプリケーションにサービスを公開する場合にのみ使用できます。これらの IP アドレスは、同じインスタンス内の組織間で重複する可能性があります。
一方、ELB は組織外から外部にアクセス可能な VIP アドレスを割り当てます。そのため、ELB VIP アドレスはすべての組織間で一意である必要があります。通常、組織が使用できる ELB VIP アドレスの数は少なくなります。