コンテナ ネイティブの負荷分散

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このページでは、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 を直接ターゲットとするため、ヘルスチェックも容易になります。

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

Pod の readiness(準備完了)

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

Ingress によるコンテナ ネイティブのロード バランシングの場合、Pod の readiness ゲートは次の環境で自動的に有効になります。

  • v1.13.8 以降を実行している v1.13 GKE クラスタ
  • v1.14.4 以降を実行している v1.14 GKE クラスタ
  • v1.15 以降

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

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

コンテナ ネイティブの負荷分散と readiness ゲートを使用しなければ、GKE は、ポッドを準備完了としてマークする前に、ロードバランサのエンドポイントが正常かどうかを検出できません。以前の 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 によるコンテナネイティブのロードバランサには、次の要件があります。

GKE バージョン

コンテナネイティブのロードバランサは通常、次の環境で使用できます。

  • v1.13.8 以降を実行している v1.13 GKE クラスタ
  • v1.14.4 以降を実行している v1.14 GKE クラスタ
  • v1.15 以降
VPC ネイティブ

コンテナ ネイティブのロード バランシングを使用するには、クラスタが VPC ネイティブである必要があります。詳細については、VPC ネイティブ クラスタの作成をご覧ください。

HTTP ロード バランシング

コンテナ ネイティブの負荷分散を使用するには、クラスタで HTTP 負荷分散を有効にする必要があります。GKE クラスタの HTTP 負荷分散はデフォルトで有効になっています。無効にしないでください。

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

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

  • ネットワーク ロードバランサはサポートされていません。
  • GKE が作成する HTTP(S) ロードバランサの構成は、手動で変更または更新しないでください。変更を加えたとしても GKE によって上書きされます。

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

このガイドに沿って作成した Ingress によってプロビジョニングされた HTTP(S) ロードバランサには料金が発生します。ロードバランサの料金情報については、VPC の料金ページで負荷分散と転送ルールをご覧ください。

次のステップ