コンテナ ネイティブのロード バランシング

このページでは、Google Kubernetes Engine（GKE）におけるコンテナネイティブのロード バランシングについて説明します。コンテナネイティブのロード バランシングにより、数種類のロードバランサは Pod を直接ターゲットにすることができ、またトラフィックを Pod に均等に分配できます。

コンテナネイティブのロード バランシングのアーキテクチャ

コンテナ ネイティブのロード バランシングでは、GCE_VM_IP_PORT ネットワーク エンドポイント グループ（NEG）を使用します。NEG のエンドポイントは Pod の IP アドレスです。

コンテナ ネイティブのロード バランシングは常に内部 GKE Ingress で使用され、外部 Ingress はオプションです。Ingress コントローラによって、仮想 IP アドレス、転送ルール、ヘルスチェック、ファイアウォール ルールなどを含むロードバランサが作成されます。

Ingress でコンテナ ネイティブのロード バランシングを使用する方法については、Ingress によるコンテナ ネイティブの負荷分散をご覧ください。

柔軟性を高めるために、スタンドアロンの NEG を作成することもできます。この場合、ロードバランサを作成して全面的に管理する必要があります。

コンテナ ネイティブ ロード バランシングのメリット

コンテナネイティブのロード バランシングには以下の利点があります。

Pod は負荷分散のコア オブジェクトです。
kube-proxy によってノードの iptables ルールが構成され、トラフィックが Pod に配信されます。コンテナネイティブのロードバランサを使用しない場合、ロードバランサのトラフィックはノード インスタンス グループに送られ、iptables ルールを使用して Pod にルーティングされます。しかし、この Pod は同じノードにあるとは限りません。コンテナネイティブのロードバランサを使用すると、ロードバランサのトラフィックは受信に適した Pod に直接配信され、余分なネットワーク ホップがなくなります。また、コンテナネイティブの負荷分散では Pod を直接ターゲットとするため、ヘルスチェックも容易になります。

デフォルトの動作（左）とコンテナネイティブのロードバランサの動作の比較
ネットワーク パフォーマンスの改善
コンテナ ネイティブのロードバランサはポッドと直接通信を行います。これにより接続でのネットワーク ホップが減少するため、レイテンシとスループットの両方が改善されます。
可視性の向上
コンテナネイティブのロード バランシングを使用すると、アプリケーション ロードバランサから Pod までのレイテンシを確認できます。アプリケーション ロードバランサから各 Pod へのレイテンシが表示され、ノード IP ベースのコンテナネイティブ ロードバランサと集約されています。これにより、NEG レベルでの Service のトラブルシューティングが容易になります。
高度なロード バランシング機能のサポート
GKE のコンテナネイティブのロード バランシングは、Google Cloud Armor、Cloud CDN、Identity-Aware Proxy のような Google Cloud サービスとの統合など、外部アプリケーション ロードバランサのいくつかの機能をサポートしています。また、トラフィックを正確に分配するためのロード バランシング アルゴリズムも備えています。
Traffic Director のサポート
サービス メッシュ用に Google Cloud が提供するフルマネージド トラフィック コントロール プレーンの Traffic Director を使用するには、NEG データモデルが必要です。

Pod の readiness（準備完了）

関連する Pod について、対応する Ingress コントローラは、cloud.google.com/load-balancer-neg-ready タイプの readiness ゲートを管理します。Ingress コントローラは、NEG 内のすべてのエンドポイントの健全性を含む、ロードバランサのヘルスチェック ステータスをポーリングします。ロードバランサのヘルスチェック ステータスが、特定の Pod に対応するエンドポイントが正常であることを示す場合、Ingress コントローラは Pod の readiness ゲート値を True に設定します。各ノードで実行されている kubelet は、この readiness ゲート値と、定義されている場合は Pod の readiness プローブの両方を考慮して、Pod の有効な準備完了状況を計算します。

Ingress でコンテナネイティブのロード バランシングを使用すると、Pod の readiness ゲートが自動的に有効になります。

readiness ゲートは、ローリング アップデートのレートを制御します。ローリング アップデートを開始すると、GKE で新しい Pod が作成され、新しい Pod ごとのエンドポイントが NEG に追加されます。ロードバランサから見てエンドポイントが正常な場合、Ingress コントローラは readiness ゲートを True に設定します。GKE が古い Pod を削除する前に、新しく作成された Pod は少なくとも readiness ゲートを通過する必要があります。これにより、Pod に対応するエンドポイントにロードバランサのヘルスチェックを通過させ、バックエンド容量が維持されるようにします。

コンテナ イメージが不適切であるか、ロードバランサのヘルスチェックが正しく構成されていないため、Pod の readiness ゲートが準備完了であることを示さない場合、ロードバランサは新しい Pod にトラフィックを転送しません。更新した Deployment をロールアウトする際にこのようなエラーが発生した場合、新しいポッドを作成しようとすると、そのポッドの readiness ゲートが True にならないことによりロールアウトが停滞します。この状況を検出して修正する方法については、トラブルシューティングをご覧ください。

コンテナネイティブのロード バランシングと readiness ゲートを使用しなければ、GKE は、Pod を準備完了としてマークする前に、ロードバランサのエンドポイントが正常かどうかを検出できません。以前の Kubernetes バージョンでは、遅延の期間（Deployment の仕様の minReadySeconds）を指定することで、Pod を削除して置換するレートを指定していました。

次のいずれかの条件が満たされた場合、GKE は Pod の cloud.google.com/load-balancer-neg-ready の値を True に設定します。

  • いずれの Pod の IP アドレスも、GKE コントロール プレーンによって管理される GCE_VM_IP_PORT NEG のエンドポイントではない。
  • Pod の 1 つ以上の IP アドレスが、GKE コントロール プレーンで管理されている GCE_VM_IP_PORT NEG のエンドポイントである。NEG がバックエンド サービスに接続されている。バックエンド サービスで、ロードバランサのヘルスチェックに成功している。
  • Pod の 1 つ以上の IP アドレスが、GKE コントロール プレーンで管理されている GCE_VM_IP_PORT NEG のエンドポイントである。NEG がバックエンド サービスに接続されている。バックエンド サービスに関するロードバランサのヘルスチェックがタイムアウトしている。
  • 1 つ以上の Pod の IP アドレスが 1 つ以上の GCE_VM_IP_PORT NEG のエンドポイントである。いずれの NEG もバックエンド サービスに接続されていない。ロードバランサのヘルスチェック データを利用できない。

セッション アフィニティ

コンテナ ネイティブのロード バランシングでは、Pod ベースのセッション アフィニティがサポートされています。

コンテナ ネイティブのロード バランシングを使用するための要件

GKE での Ingress によるコンテナネイティブのロードバランサには、次の要件があります。

  • クラスタは VPC ネイティブである必要があります。
  • クラスタで HttpLoadBalancing アドオンが有効になっている必要があります。GKE クラスタでは、HttpLoadBalancing アドオンがデフォルトで有効になっています。無効にしないでください。

コンテナネイティブのロードバランサの制限

GKE での Ingress によるコンテナネイティブのロードバランサには、次の制限があります。

  • 外部パススルー ネットワーク ロードバランサはサポートされていません。
  • GKE が作成するアプリケーション ロードバランサの構成を手動で変更または更新しないでください。変更を加えたとしても GKE によって上書きされます。

コンテナネイティブ ロードバランサの料金

このガイドで作成する Ingress によってプロビジョニングされたアプリケーション ロードバランサに対して課金されます。ロードバランサの料金情報については、VPC の料金ページでロード バランシングと転送ルールをご覧ください。

次のステップ