アプリケーション ロードバランサ用の GKE Ingress

このページでは、アプリケーション ロードバランサ用の Google Kubernetes Engine（GKE）Ingress の概要について説明します。また、Ingress コントローラがアプリケーション ロードバランサをプロビジョニングして、VPC ネットワークの内外からの HTTP(S) トラフィックにアプリケーションを公開する方法についても説明します。

このページは、GKE Ingress の仕組みを理解するための最初のステップとなります。基盤となるネットワーク アーキテクチャ、トラフィック ルーティング パターン、セキュリティ実装の詳細については、GKE Ingress のルーティングと セキュリティについてをご覧ください。

このページでは、次の内容を理解していることを前提としています。

このページは、組織のネットワークを設計し、ネットワーク機器の設置、構成、サポートを行うネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

概要

GKE には、GKE Ingress と呼ばれる、組み込みのマネージド Ingress controller が用意されています。GKE で Ingress リソースを作成すると、コントローラは HTTPS ロードバランサを自動的に構成して、HTTP または HTTPS トラフィックが Service に到達できるようにします。Ingress コントローラは、Ingress マニフェストと関連する Service オブジェクトで指定されたルールに基づいて、ロードバランサを構成し、クラスタで実行されるアプリケーションにトラフィックをルーティングします。

1 つの Ingress オブジェクトは 1 つ以上の Service オブジェクトに関連付けられており、それぞれの Service オブジェクトは Pod のセットに関連付けられています。Ingress が Service を使用して アプリケーションを公開する仕組みについては、 Service ネットワーキングの概要をご覧ください。

Ingress を使用するには、HTTP ロード バランシング アドオンを有効にする必要があります。 GKE クラスタでは、このアドオンがデフォルトで有効になっています。無効にしないでください。

Kubernetes Service と Google Cloud バックエンド サービスの違い

Kubernetes Service オブジェクトと Google Cloud バックエンド サービス オブジェクトは、似ていますが異なる 目的で使用されます。両者は密接に関連していますが、その関係は必ずしも 1 対 1 ではありません。

GKE Ingress コントローラは、これら 2 つの概念間のトランスレータとして機能します。Ingress リソースを作成すると、コントローラは Google Cloud ロードバランサをプロビジョニングします。次に、コントローラは、Ingress マニフェストで参照されている一意の（service.name、 service.port）の組み合わせごとに専用の Google Cloud バックエンド サービスを作成します。

たとえば、Ingress マニフェストで Kubernetes Service 名が同じでも、2 つの別々の host ルールまたは path ルールで異なる service.port を指定できます。この場合、GKE Ingress コントローラは 2 つの別々のバックエンド サービスを作成します。したがって、1 つの Kubernetes Service オブジェクトが 複数の Google Cloud バックエンド サービスに関係する可能性があります。

外部および内部トラフィック用 Ingress

GKE Ingress リソースには次の 2 種類があります。

外部アプリケーション ロードバランサに必要なネットワーク環境

外部アプリケーション ロードバランサは、Google のエッジ ネットワーク全体にデプロイされた Google Front End（GFE）プロキシを使用する、マネージドでグローバルに分散されたシステムです。これらのプロキシは VPC ネットワーク内に配置されていません。クライアントがロードバランサの外部 IP アドレスにリクエストを送信すると、Google のエニーキャスト ネットワークを使用して、リクエストが最も近い GFE にルーティングされます。GFE は、ユーザー トラフィック（TLS が構成されている場合は TLS を含む）を終端し、トラフィックを GKE クラスタのバックエンド Pod に転送します。

このフローが機能するように、GKE Ingress コントローラは、GFE と Google Cloud's のヘルスチェック システムからのトラフィックが Pod に到達できるように、ファイアウォール ルールを自動的に 作成します。これらのルールは、Google の既知の IP アドレス範囲（130.211.0.0/22 と 35.191.0.0/16）からのトラフィックを許可します。

外部アプリケーション ロードバランサの仕組みは次のとおりです。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートにリクエストを送信します。
  2. リクエストは、Google のグローバル ネットワーク上の Google Front End（GFE）プロキシにルーティングされます。このプロキシは、クライアントのネットワーク接続を終端します。
  3. GFE プロキシは、ロードバランサの URL マップとバックエンド サービスによって決定された、GKE クラスタ内の適切なバックエンド Pod エンドポイントにリクエストを転送します。

内部アプリケーション ロードバランサとは異なり、外部アプリケーション ロードバランサ用に VPC ネットワークにプロキシ専用サブネットを構成する必要はありません。

内部アプリケーション ロードバランサに必要なネットワーク環境

内部アプリケーション ロードバランサは、ネットワークにプロキシのプールを提供します。プロキシは、URL マップ、BackendService のセッション アフィニティ、各バックエンド NEG の分散モードなどの要素に基づいて各 HTTP(S) リクエストを実行する場所を評価します。

リージョンの内部アプリケーション ロードバランサは、VPC ネットワーク内のそのリージョンのプロキシ専用サブネットを使用して、 Google Cloudによって作成された各プロキシに内部 IP アドレスを割り当てます。

デフォルトでは、ロードバランサの転送ルールに割り当てられる IP アドレスは、プロキシ専用サブネットではなく、GKE によって割り当てられたノードのサブネット範囲から取得されます。ルールを作成するときに、サブネットからの転送ルールに IP アドレスを手動で指定することもできます。

次の図は、前の段落で説明した内部アプリケーション ロードバランサのトラフィック フローの概要を示しています。

画像

内部アプリケーション ロードバランサの仕組みは次のとおりです。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
  2. プロキシは、クライアントのネットワーク接続を受信して終了します。
  3. プロキシは、NEG 内の適切なエンドポイント（Pod）への接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決定されます。

各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。プロキシからエンドポイントに送信される各パケットの送信元 IP アドレスは、プロキシ専用サブネットからプロキシに割り当てられた内部 IP アドレスです。

GKE Ingress コントローラの動作

GKE Ingress コントローラで Ingress が処理されるかどうかは、kubernetes.io/ingress.class アノテーションの値によって決まります。

kubernetes.io/ingress.class 値 ingressClassName 値 GKE Ingress コントローラの動作
未設定 未設定 Ingress マニフェストを処理し、外部アプリケーション ロードバランサを作成します。
未設定 任意の値 アクションは実行されません。サードパーティ製の Ingress コントローラがデプロイされている場合、Ingress マニフェストはそのコントローラで処理できます。
gce 任意の値。このフィールドは無視されます。 Ingress マニフェストを処理し、外部アプリケーション ロードバランサを作成します。
gce-internal 任意の値。このフィールドは無視されます。 Ingress マニフェストを処理し、内部アプリケーション ロードバランサを作成します。
gce、gce-internal 以外の値に設定する 任意の値 アクションは実行されません。サードパーティ製の Ingress コントローラがデプロイされている場合、Ingress マニフェストはそのコントローラで処理できます。

kubernetes.io/ingress.class アノテーションの非推奨

kubernetes.io/ingress.class アノテーションは Kubernetes で非推奨になりましたが、GKE では引き続きこの アノテーションが使用されます。このアノテーションを使用して、Ingress クラスを識別する必要があります。

構成を適用すると、非推奨の警告が表示されることがあります。この警告は、アノテーションが非推奨になったことを示し、代わりに ingressClassName フィールドを使用するように指示します。GKE Ingress は引き続き kubernetes.io/ingress.class アノテーションのみに依存するため、この警告は無視してかまいません。

Ingress と Compute Engine リソースのマッピング

GKE Ingress コントローラは、クラスタにデプロイされている Ingress リソースに基づいて、Compute Engine ロードバランサ リソースをデプロイして管理します。Compute Engine リソースのマッピングは、Ingress リソースの構造によって異なります。

次のマニフェストは Ingress を記述しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

この Ingress マニフェストは、次の Compute Engine リソースを作成するように GKE に指示します。

  • 転送ルールと IP アドレス。
  • ロードバランサ ヘルスチェックのトラフィックと、Google Front End または Envoy プロキシからのアプリケーションのトラフィックを許可する Compute Engine ファイアウォール ルール。
  • TLS を構成した場合、ターゲット HTTP プロキシとターゲット HTTPS プロキシ。
  • 1 つのパスマッチャーを参照する単一のホストルールがある URL マップ。パスマッチャーには、/* 用と /discounted 用の 2 つのパスルールがあります。各パスルールは一意のバックエンド サービスにマッピングされます。
  • エンドポイントとして各 Service の Pod IP アドレスのリストを保持する NEG。これは my-discounted-products および my-products Service の結果として作成されます。

ロード バランシングの方法

GKE は、コンテナ ネイティブのロード バランシングとインスタンス グループをサポートしています。

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

コンテナ ネイティブのロード バランシングとは、GKE 内の Pod エンドポイントに直接ロード バランシングを行う手法のことです。コンテナ ネイティブのロード バランシング では、ネットワーク エンドポイント グループ（NEG）を使用します。タイプ GCE_VM_IP_PORTのエンドポイントは Pod の IP アドレスです。

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

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

GKE は、次のすべての条件が満たされると、コンテナ ネイティブのロード バランシングを自動的に有効にします。

  • クラスタは VPC ネイティブである。
  • クラスタで共有 VPC ネットワークを使用していない。
  • クラスタで GKE ネットワーク ポリシーを使用していない。
  • クラスタで HttpLoadBalancing アドオンが有効になっている。 GKE クラスタでは、HttpLoadBalancing アドオンがデフォルトで有効になっています。無効にしないでください。

GKE がコンテナ ネイティブのロード バランシングを有効にすると、Service に アノテーションが自動的に追加されますcloud.google.com/neg: '{"ingress": true}'。このアノテーションにより、Pod の IP をミラーリングする NEG が作成され、Compute Engine ロードバランサが Pod と直接通信できるようになります。

NEG がデフォルトではないクラスタの場合でも、コンテナ ネイティブのロード バランシングを使用することを強くおすすめ しますが、Service ごとに明示的に有効にする必要があります。

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

特典

NEG を使用することで、コンテナ ネイティブのロード バランシングは、より高性能で安定したネットワーキングを実現します。

ネットワーク パフォーマンスの向上: コンテナ ネイティブのロード バランシングを使用しない場合、 トラフィックはノード インスタンス グループに送られ、iptables ルール に基づいて kube-proxy ターゲット Pod にルーティングされます。コンテナ ネイティブのロード バランシングを使用すると、トラフィックは Pod に直接ロード バランシングされるため、ノード上の VM IP と kube-proxy ネットワーキングを介してルーティングする必要がなくなります。このフローにより、余分なネットワーク ホップが排除され、レイテンシとスループットが向上します。

ヘルスチェックの強化: Pod readiness ゲート は、クラスタ内ヘルスチェック プローブのみに依存するのではなく、ロードバランサの観点から Pod の健全性を判断するために実装されます。この重要な機能により、ロードバランサは Pod のライフサイクル イベント（起動、損失など）を認識し、トラフィックの安定性を向上させることができます。Pod の readiness ゲートを使用して Pod の健全性を判断する方法については、Pod の readiness をご覧ください。

可視性の向上: コンテナ ネイティブのロード バランシングを使用すると、 アプリケーション ロードバランサから各 Pod までのレイテンシを確認できます。レイテンシはノード IP レベルで集約されなくなるため、NEG レベルでの Service のトラブルシューティングが容易になります。

Cloud Service Mesh のサポート: サービス メッシュ用に Google Cloudが提供するフルマネージド トラフィック コントロール プレーンである Cloud Service Mesh を使用するには、NEG データモデルが必要です。

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

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

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

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

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

インスタンス グループ

インスタンス グループを使用する場合、Compute Engine ロードバランサはバックエンドとして VM IP アドレスにトラフィックを送信します。コンテナが同じホスト インターフェースを共有しているコンテナで VM を実行する場合、次のような制限があります。

  • ロードバランサから VM NodePort へのホップと、Pod IP アドレス（別の VM に存在している可能性がある）へのホップの 2 つのホップが発生します。
  • ホップ数が増えるとレイテンシが増大し、トラフィック パスがより複雑になります。
  • Compute Engine ロードバランサには Pod が直接見えないため、トラフィックの負荷分散は最適なものにはなりません。
  • VM や Pod の損失などの環境イベントが発生すると、トラフィック ホップが重複して断続的なトラフィック損失が発生する可能性が高くなります。

外部 Ingress とルートベース クラスタ

外部 Ingress でルートベースのクラスタを使用する場合、GKE Ingress コントローラは GCE_VM_IP_PORT ネットワーク エンドポイント グループ（NEG）を使用してコンテナ ネイティブのロード バランシングを使用できません。代わりに、Ingress コントローラは、すべてのノードプール内のすべてのノードを含む非マネージド インスタンス グループ バックエンドを使用します。これらの非マネージド インスタンス グループが LoadBalancer Service でも使用されている場合、単一ロード バランシング インスタンス グループの制限に関連する問題が発生する可能性があります。

VPC ネイティブ クラスタで作成された古い外部 Ingress オブジェクトの中には、作成した各外部アプリケーション ロードバランサのバックエンド サービスでインスタンス グループ バックエンドを使用するものがあります。これは内部 Ingress には関係ありません。内部 Ingress リソースは常に GCE_VM_IP_PORT NEG を使用し、VPC ネイティブ クラスタを必要とするためです。

外部 Ingress での 502 エラーのトラブルシューティング方法については、 外部 Ingress で HTTP 502 エラーが発生するをご覧ください。

GKE Ingress コントローラの制限事項

  • GKE Ingress は、Certificate Manager で管理される証明書をサポートしていません。Certificate Manager で管理される証明書を使用するには、Gateway APIを使用します。

  • NEG を使用するクラスタでは、Ingress の調整時間が Ingress の数によって影響を受けることがあります。 たとえば、それぞれに 20 個の Ingress があり、そのすべてに 20 個の個別の NEG バックエンドが含まれている場合、Ingress の変更が調整されるまでに 30 分以上のレイテンシが発生する場合があります。これは特に、必要な NEG の数が増えるため、リージョン クラスタに影響します。

  • URL マップの割り当てが適用されます。

  • Compute Engine リソースの割り当て が適用されます。

  • GKE Ingress コントローラで NEG を使用しない場合、GKE クラスタのノード数は 1,000 に制限されます。NEG を使用して Service をデプロイする場合、GKE のノード数に課される制限はありません。Ingress で公開されている、NEG を使用しない Service は、1,000 個を超えるノードがあるクラスタでは正しく機能しません。

  • GKE Ingress コントローラで readinessProbes をヘルスチェックとして使用するには、Ingress の作成時に Ingress 用の Pod が存在している必要があります。レプリカが 0 にスケールされている場合は、デフォルトのヘルスチェックが適用されます。詳しくは、ヘルスチェックに関する GitHub の問題のコメントをご覧ください。

  • Ingress の作成後に Pod の readinessProbe を変更しても、Ingress には影響を与えません。

  • 外部アプリケーション ロードバランサは、クライアントとロードバランサの間のレイテンシを最小限に抑えるために、グローバルに分散されたロケーションで TLS を終端します。TLS の終端を指定する必要がある場合は、タイプ LoadBalancer の GKE Service で公開されている 独自の Ingress コントローラ を使用して、適切なリージョンにあるバックエンドで TLS を終端する必要があります。

  • 複数の Ingress リソースを単一の Google Cloud ロードバランサに統合する操作はサポートされていません。

  • 相互 TLS は外部アプリケーション ロードバランサでサポートされていないため、アプリケーションでは相互 TLS を無効にする必要があります。

  • Ingress は、フロントエンドの HTTP ポート 80 と 443 のみを公開できます。

次のステップ