このページでは、Google Kubernetes Engine（GKE）で Cloud Load Balancing を作成および管理する方法の概要について説明します。このページでは、次の内容を理解していることを前提としています。
- Trusted Cloud by S3NS ロードバランサの種類
- レイヤ 4（ネットワーク ロードバランサ）とレイヤ 7（アプリケーション ロードバランサ）のロードバランサの違い
このページは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。 Trusted Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
GKE がロードバランサを作成する仕組み
クラスタの外部（外部ユーザー）またはプライベート ネットワーク内（内部ユーザー）からアプリケーションにアクセスできるようにするには、Gateway、Ingress、Service API を使用してロードバランサをプロビジョニングし、アプリケーションを公開します。また、ロードバランサのコンポーネントを自分で作成することもできます。この場合、GKE はロードバランサをクラスタ内の Pod に接続するネットワーク エンドポイント グループ（NEG）を管理します。
ゲートウェイ
GKE Gateway コントローラは、Google が Cloud Load Balancing に実装した Kubernetes Gateway API です。Gateway API は、サービス メッシュと上り（内向き）コントローラが Kubernetes でアプリケーションを公開する方法の標準化を目的としたオープンソース プロジェクトです。Ingress リソースの後継として、より表現力、柔軟性、拡張性を高めるように設計されています。
GKE Gateway Controller は、クラスタで実行されているアプリケーションに HTTP(S) トラフィックを公開するようにレイヤ 7 アプリケーション ロードバランサを構成するために使用されます。
Gateway API を使用してロードバランサを実装します。
Ingress
GKE Ingress コントローラは、Google が実装した Ingress API です。Ingress API を使用すると、クラスタで実行されている Service への外部アクセスを管理できます。GKE で Ingress リソースを作成すると、コントローラはレイヤ 7 アプリケーション ロードバランサを自動的に構成して、HTTP または HTTP(S) トラフィックがクラスタで実行されているアプリケーションに到達できるようにします。
GKE Gateway は、高度なトラフィック管理、マルチプロトコル サポート、または優れたマルチテナンシーを必要とする新しいデプロイとアプリケーションに推奨される選択肢です。ただし、GKE Ingress は、よりシンプルな HTTP / HTTPS ルーティング シナリオ、特に Gateway API への移行のメリットがまだ労力を上回っていない既存の構成に適しています。
LoadBalancer Service
Service API を使用すると、クラスタ内の Pod として実行されるアプリケーションを外部または内部トラフィックに公開できます。タイプ LoadBalancer の Service を作成すると、GKE は Service マニフェストのパラメータに基づいてレイヤ 4（TCP / UDP）パススルー ネットワーク ロードバランサを自動的に作成します。
パススルー ネットワーク ロードバランサでは、トラフィックがバックエンド VM に到達しても、元の送信元 IP アドレスと宛先 IP アドレス、通信プロトコル（TCP や UDP など）、ポート番号（プロトコルが使用する場合）は同じままになります。つまり、トラフィックはバックエンド VM または Pod に直接渡され、ロードバランサは接続を終了しません。バックエンド サービスは接続の終了を処理し、クライアントからサービスへのトラフィックがシームレスに流れるようにします。
重み付きロード バランシング
VPC ネットワークの外部にあるクライアントと Trusted Cloud VM がアクセスできる外部 LoadBalancer Service を構成した場合は、重み付けされたロード バランシングを有効にできます。重み付けロード バランシングは、各 GKE ノードのサービング Pod の数に基づいてトラフィックを分散します。これにより、Pod の数が少ないノードと比較して、サービング Pod の数が多いノードがトラフィックの大部分を受け取るようにします。
スタンドアロン NEG
GKE でのロードバランサの管理には、ロードバランサ コンポーネントを自分で作成し、GKE に NEG の管理を任せる方法もあります。このタイプのロードバランサは、プロキシ ネットワーク ロードバランサと呼ばれます。NEG は、ロード バランシング用のバックエンド エンドポイント（Pod など）のグループ化して表現する方法です。
このタイプのロードバランサは、TCP トラフィックのみを対象としています。プロキシ ネットワーク ロードバランサは、VPC ネットワークまたは他のクラウド環境のバックエンドに TCP トラフィックを分散します。トラフィックはロード バランシング レイヤで終端し、ロードバランサは最も近い利用可能なバックエンドに新しい TCP 接続を確立してそのトラフィックを転送します。
コンテナ ネイティブのロード バランシングとは
コンテナ ネイティブのロード バランシングとは、GCE_VM_IP_PORT NEG を使用して、トラフィックを個々の Pod（ノードではなく）の IP アドレスに直接均等に分散する手法のことです。GCE_VM_IP_PORT NEG を使用すると、Compute Engine 仮想マシン（VM）のプライマリ内部 IP アドレスか、VM の構成済みエイリアス IP 範囲の IP アドレスのいずれかを使用して、バックエンド エンドポイントを指定できます。
コンテナ ネイティブのロード バランシングは、Gateway、Ingress、スタンドアロン NEG など、GKE で管理されるすべてのレイヤ 7 ロードバランサで使用されます。LoadBalancer Service は、コンテナ ネイティブのロード バランシングを使用しません。ただし、重み付けロード バランシングを有効にすることで、同様の機能を実現できます。
コンテナ ネイティブのロード バランシングには、ネットワーク パフォーマンスの向上やヘルスチェックの改善など、いくつかのメリットがあります。これは、Pod を直接ターゲットにするためです。詳細については、コンテナ ネイティブのロード バランシングをご覧ください。
一覧表
次の表を使用してロード バランシング構成を計画できます。
ロードバランサのタイプを選択する
次の表に示すのは、特定のリソース（Gateway、Ingress、LoadBalancer Service）に対して作成されるロードバランサのタイプです。
| Kubernetes リソース | 作成されたロードバランサのタイプ | |
|---|---|---|
| アプリケーション ロードバランサ | パススルー ネットワーク ロードバランサ | |
| ゲートウェイ | ||
| Ingress | ||
| LoadBalancer Service | ||
ロードバランサの作成方法を選択する
次の表に示すのは、選択したロードバランサを作成するための GKE のオプションです。
| ロードバランサの種類 | 選択したロードバランサを作成する方法 | |||
|---|---|---|---|---|
| ゲートウェイ | Ingress | LoadBalancer Service | スタンドアロン NEG | |
| グローバル外部アプリケーション ロードバランサ | ||||
| 従来の外部アプリケーション ロードバランサ | ||||
| リージョン外部アプリケーション ロードバランサ | ||||
| リージョン内部アプリケーション ロードバランサ | ||||
| クロスリージョン内部アプリケーション ロードバランサ | ||||
|
プロキシ ネットワーク ロードバランサ
（すべてのタイプ） |
||||
|
パススルー ネットワーク ロードバランサ
（内部と外部） |
||||
次のステップ
- GKE の Gateway API について確認する。
- GKE Ingress について確認する。
- LoadBalancer Service について確認する。