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

コンテナ ネイティブのロードバランサにより、数種類のロードバランサは Pod を直接ターゲットにすることができ、またトラフィックを Pod に均等に分配できます。

コンテナ ネイティブのロードバランサでは、ネットワーク エンドポイント グループ（NEG）というデータモデルが利用されます。これは、IP とポートのペアで示されるネットワーク エンドポイントのコレクションです。

NEG を GKE Ingress と一緒に使用すると、Ingress コントローラで L7 ロードバランサの作成が容易になります。たとえば、仮想 IP アドレス、転送ルール、ヘルスチェック、ファイアウォール ルールなどを簡単に作成できます。

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

利点

コンテナ ネイティブの負荷分散には以下の利点があります。

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

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

ポッドの readiness（準備完了）

関連するポッドについて、対応する 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）を指定することで、ポッドを削除して置換するレートを指定していました。

要件

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

Google Kubernetes Engine v1.13.8 または v1.14.4

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

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

コンテナ ネイティブの負荷分散を使用するには、クラスタが VPC ネイティブである必要があります。詳細については、エイリアス IP を使用した VPC ネイティブ クラスタの作成をご覧ください。

HTTP 負荷分散

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

制限事項

コンテナ ネイティブのロードバランサは、レガシー ネットワークでは動作しません。

制限事項

コンテナ ネイティブのロードバランサは、内部 TCP/UDP ロードバランサまたはネットワーク ロードバランサをサポートしていません。

料金

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

次のステップ