HTTP(S) 負荷分散用 GKE Ingress

このページでは、HTTP(S) 負荷分散で Ingress がどのように機能するかについて概要を説明します。Google Kubernetes Engine（GKE）では、GKE Ingress と呼ばれる、組み込みのマネージド Ingress コントローラを使用できます。このコントローラは、GKE で HTTP(S) ワークロードを処理する Google Cloud ロードバランサとして Ingress リソースを実装します。

概要

GKE では、Ingress オブジェクトが、クラスタ内で実行されるアプリケーションに HTTP(S) トラフィックをルーティングするルールを定義します。1 つの Ingress オブジェクトは 1 つ以上の Service オブジェクトに関連付けられており、それぞれの Service オブジェクトはポッドのセットに関連付けられています。Ingress がサービスを使用してアプリケーションを公開する仕組みについては、サービスネットワーキングの概要をご覧ください。

Ingress オブジェクトを作成すると、GKE Ingress コントローラによって Cloud HTTP(S) ロードバランサが作成され、Ingress および関連する Service の情報に従ってそれが構成されます。

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

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

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

外部 HTTP(S) ロードバランサ用 Ingress では、Google Cloud 外部 HTTP(S) ロードバランサをデプロイします。インターネットに接続するこのロードバランサは、管理されたスケーラブルな負荷分散リソースのプールとして Google のエッジネットワークにグローバルにデプロイされます。外部 HTTP(S) ロードバランサ用に Ingress を設定して使用する方法を学習します。
内部 HTTP(S) 負荷分散用 Ingress は、Google Cloud 内部 HTTP(S) ロードバランサをデプロイします。これらの内部 HTTP(S) ロードバランサは、GKE クラスタ外部、ただし VPC ネットワーク内部の Envoy プロキシシステムを利用しています。内部 HTTP(S) 負荷分散で使用する Ingress を設定して使用する方法を学習します。

HTTP(S) 負荷分散の特長

Ingress により構成された HTTP(S) 負荷分散には、次のような特長があります。

柔軟な Service の構成。Ingress では、トラフィックがどのように Service に到達し、そのトラフィックがどのようにアプリケーションにルーティングされるかを定義します。また、クラスタ内の複数の Service に対して単一の IP アドレスを割り当てることができます。
Google Cloud ネットワークサービスとの統合
複数の TLS 証明書のサポート。Ingress では、リクエストの終了に際して複数の TLS 証明書を使用するよう指定できます。

一覧については、Ingress の機能をご覧ください。

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

コンテナネイティブの負荷分散とは、ネットワークエンドポイントグループ（NEG）を使用して GKE 内の Pod エンドポイントに直接負荷を分散する手法のことです。

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

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

NEG を使用すると、トラフィックは、VM IP または kube-proxy ネットワーキングを移動するのではなく、Ingress プロキシから直接 Pod IP に負荷分散されます。また、Kubernetes のクラスタ内正常性 Probe だけでなく、負荷分散の観点からも Pod の健全性を判断するため、Pod の readiness ゲートが実装されます。これにより、ロードバランサインフラストラクチャで、Pod の起動、Pod の損失、VM の損失などのライフサイクルイベントを認識することで、トラフィック全体の安定性が向上します。これらの機能では、上記の制限を解決し、パフォーマンスの向上と安定したネットワークを実現します。

コンテナネイティブの負荷分散は、次のすべての条件が満たされている場合、デフォルトで Services に対して有効になります。

GKE クラスタ 1.17.6-gke.7 以降で作成された Service の場合
VPC ネイティブクラスタの使用
共有 VPC を使用しない
GKE ネットワークポリシーを使用しない

これらの条件では、Service 内に Pod IP をミラーリングするために NEG が作成する必要があることを示す cloud.google.com/neg: '{"ingress": true}' が Service に自動的に付けられます。NEG とは、Compute Engine のロードバランサが Pod と直接通信できるようにするものです。GKE 1.17.6-gke.7+ より前のバージョンで作成された既存の Service には、サービスコントローラによって自動的にアノテーションが付けられないことに注意してください。

NEG アノテーションが自動的に付けられる GKE 1.17.6-gke.7 以降のクラスタでは、NEG を無効にして、必要に応じて Compute Engine のロードバランサでインスタンスグループをバックエンドとして使用することもできます。このためには、Service に cloud.google.com/neg: '{"ingress": false}' を明示的に付けます。

NEG がデフォルトではないクラスタの場合でも、コンテナネイティブの負荷分散を使用することを強くおすすめしますが、Service ごとに明示的に有効にする必要があります。アノテーションは、次の方法で Service に適用する必要があります。

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

共有 VPC

共有 VPC トポロジでは Ingress リソースと MultiClusterIngress リソースがサポートされていますが、いくつかの準備が必要です。GKE Ingress コントローラは、Google Cloud サービスアカウントを使用して、Google Cloud リソースのデプロイや管理をします。GKE クラスタが共有 VPC のサービスプロジェクトにある場合、このサービスアカウントには、ホストプロジェクトが所有するネットワークリソースを管理する権限がありません。Ingress コントローラは、ロードバランサとポッド間および一元化されたヘルスチェックとポッド間のアクセスを提供するため、ファイアウォールルールをアクティブに管理します。

ただし、共有 VPC では、GKE Ingress コントローラにファイアウォールルールを管理する権限はありません。ホストプロジェクトからファイアウォールルールを手動でプロビジョニングするか、GKE Ingress コントローラにホストプロジェクトのファイアウォールルールを管理する権限を与えることによって、権限を追加できます。

ホストプロジェクトからファイアウォールルールを手動でプロビジョニングする

セキュリティポリシーによって、ホストプロジェクトからのファイアウォール管理のみが許可される場合は、これらのファイアウォールルールを手動でプロビジョニングできます。共有 VPC に Ingress をデプロイすると、Ingress リソースイベントにより、アクセスを追加するために必要な特定のファイアウォールルールが提供されます。

ルールを手動でプロビジョニングするには:

Ingress リソースイベントを表示する:

kubectl describe ingress INGRESS_NAME

INGRESS_NAME を実際の Ingress 名で置き換えます。

出力は次の例のようになります。

Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by network admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

推奨されるファイアウォールルールが Message 列に表示されます。

ホストプロジェクトから提案されたファイアウォールルールをコピーして適用します。ルールを適用すると、ロードバランサと Google Cloud ヘルスチェックからポッドにアクセスできます。

注: Ingress の種類によって、必要なルールは異なります。

ホストコントローラのファイアウォールルールを管理する権限を Ingress コントローラに与える

自動化されたアプローチでは、GKE Ingress コントローラサービス・アカウントに、ファイアウォールルールを更新するための権限を付与します。カスタム IAM 役割を作成して、ファイアウォールルールを直接管理し、この役割を GKE Ingress サービスアカウントに付与します。

ホストプロジェクトで、サービスプロジェクトの GKE サービスアカウントに compute.firewalls.* 権限と compute.networks.updatePolicy 権限を持つカスタムロールを付与します。
```
gcloud iam roles create ROLE_NAME \
   --project PROJECT_ID \
   --title ROLE_TITLE \
   --description ROLE_DESCRIPTION \
   --permissions=compute.networks.updatePolicy, compute.firewalls.*\
   --stage GA
```
以下を置き換えます。
- ROLE_NAME: ロールの名前を追加します。
- PROJECT_ID: ホストプロジェクトのプロジェクト ID を追加します。
- ROLE_TITLE: 作成するロールのタイトルを追加します。
- ROLE_DESCRIPTION: 作成するロールの説明を追加します。
このカスタムロールを GKE Ingress サービスアカウントに適用します。
```
gcloud projects add-iam-policy-binding my-project \
    --member=user:SERVICE_ACCOUNT  \
    --role=roles/gke-ingress-fw-management
```
SERVICE_ACCOUNT の値は、GKE Ingress と複数クラスタ Ingress で異なります。
- GKE Ingress を使用している場合、SERVICE_ACCOUNT は PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com になります。
- 複数クラスタ Ingress を使用している場合、SERVICE_ACCOUNT は PROJECT_NUMBER@gcp-sa-multiclusteringress.iam.gserviceaccount.com になります。
PROJECT_NUMBER は、ホストプロジェクトのプロジェクト番号に置き換えます。

複数のバックエンドサービス

各外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサは、1 つ以上のバックエンドサービスを参照する単一の URL マップを使用します。1 つのバックエンドサービスが、Ingress によって参照される各 Service に対応します。

たとえば、URL パスに応じてリクエストを異なるバックエンドサービスにルーティングするようにロードバランサを構成できます。つまり、your-store.example に送信されたリクエストは、正価の商品を表示するバックエンドサービスにルーティングされ、your-store-example/discounted に送信されたリクエストは、値引き対象商品を表示するバックエンドサービスにルーティングされるようにできます。

ホスト名に応じてリクエストをルーティングするように、ロードバランサを構成することもできます。つまり、your-store.example に送信されたリクエストはあるバックエンドサービスに送信され、your-experimental-store.example に送信されたリクエストは別のバックエンドサービスに送信されるようにできます。

GKE クラスタでは、Kubernetes Ingress オブジェクトを作成して HTTP(S) ロードバランサの作成と構成を行います。1 つの Ingress オブジェクトは 1 つ以上の Service オブジェクトに関連付けられている必要があります。それぞれの Service オブジェクトは、Pod のセットに関連付けられます。

my-ingress という名前の Ingress のマニフェストを次に示します。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Ingress を作成すると、GKE Ingress コントローラで、Ingress とそれに関連する Service の情報に従って、外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサの作成と構成が行われます。また、ロードバランサには、ドメイン名に関連付けることのできる固定 IP アドレスが与えられます。

上記の例で、ロードバランサの IP アドレスをドメイン名 your-store.example に関連付けたと仮定します。クライアントが your-store.example にリクエストを送信すると、そのリクエストはポート 60000 の my-products という名前の Kubernetes Service にルーティングされます。クライアントが your-store.example/discounted にリクエストを送信すると、そのリクエストはポート 80 の my-discounted-products という名前の Kubernetes Service にルーティングされます。

Ingress の path フィールドでサポートされているワイルドカード文字は「*」のみです。「*」はスラッシュ（「/」）の直後に置かれる必要があり、パターンの最後の文字でなければなりません。たとえば、/*、/foo/*、/foo/bar/* は有効なパターンですが、*、/foo/bar*、/foo/*/bar は有効ではありません。

より具体的なパターンのほうが、そうでないものよりも優先されます。/foo/* と /foo/bar/* の両方を使用すると、/foo/bar/bat が /foo/bar/* と比較されます。

パスの制限とパターンマッチングの詳細については、URL マップのドキュメントをご覧ください。

my-products Service のマニフェストは次のようになります。

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

コンテナネイティブの負荷分散を使用しない場合、Service マニフェストでは type: NodePort を使用する必要があります。コンテナネイティブの負荷分散を使用する場合は、type: ClusterIP を使用します。

Service マニフェストの selector フィールドでは、app: products ラベルと department: sales ラベルの両方を持つ Pod がこの Service のメンバーであることを示しています。

リクエストがポート 60000 で Service に到達すると、そのリクエストは TCP ポート 50000 の 1 つのメンバーポッドにルーティングされます。

メンバーポッドごとに、TCP ポート 50000 でリッスンするコンテナが必要です。

my-discounted-products Service のマニフェストは次のようになります。

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Service マニフェストの selector フィールドでは、app: discounted-products ラベルと department: sales ラベルの両方を持つポッドがこの Service のメンバーであることを示しています。

リクエストがポート 80 で Service に到達すると、そのリクエストは TCP ポート 8080 の 1 つのメンバーポッドにルーティングされます。

メンバーポッドごとに、TCP ポート 8080 でリッスンするコンテナが必要です。

デフォルトのバックエンド

Ingress マニフェストに backend フィールドを指定することで、デフォルトのバックエンドを指定できます。rules フィールドのパスと一致しないリクエストはすべて、backend フィールドで指定された Service とポートに送信されます。たとえば、次の Ingress では、/ または /discounted と一致しないリクエストが my-products という名前の Service ポート 60001 に送信されます。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-products
    servicePort: 60001
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

デフォルトのバックエンドを指定しない場合、GKE は 404 を返すバックエンドをデフォルトにします。

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

GKE Ingress コントローラは、クラスタにデプロイされている Ingress リソースに基づいて、Compute Engine ロードバランサリソースをデプロイして管理します。Compute Engine リソースのマッピングは、Ingress リソースの構造によって異なります。これらのリソースのマッピングを把握しておくと、計画、設計、トラブルシューティングに役立ちます。

複数のバックエンドサービスのセクションに記載されている my-ingress マニフェストでは、2 つの異なる Kubernetes Services を参照する 2 つの URL パスと一致する外部 Ingress リソースを指定しています。my-ingress の代わりとして作成される Compute Engine リソースには次のものがあります。

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

Ingress と Compute Engine リソースのマッピングを示す図

SSL 証明書を提供するためのオプション

HTTP(S) ロードバランサに SSL 証明書を提供する方法は 3 つあります。

Google マネージド証明書: Google マネージド SSL 証明書は、ドメインに対してプロビジョニング、デプロイ、更新、管理されます。マネージド証明書はワイルドカードドメインをサポートしません。
Google Cloud と共有されるセルフマネージド証明書: 独自の SSL 証明書をプロビジョニングして、Google Cloud プロジェクトで証明書リソースを作成できます。その後、証明書リソースを Ingress のアノテーションでリストして、証明書を使用する HTTP(S) ロードバランサを作成できます。詳しくは、事前共有証明書に関する説明をご覧ください。
Secret リソースとしてのセルフマネージド証明書: 自身の SSL 証明書をプロビジョニングして、それを保持するための Secret を作成できます。そして、Ingress 仕様の Secret を参照して、証明書を使用する HTTP(S) ロードバランサを作成できます。詳細については、Secret で証明書を使用する際の手順をご覧ください。

ヘルスチェック

デフォルトの Ingress コントローラを使用して Ingress によって 1 つ以上の Service を公開すると、GKE によって Google Cloud 外部 HTTP(S) ロードバランサまたは Google Cloud 内部 HTTP(S) ロードバランサが作成されます。こうしたロードバランサでは、いずれも 1 つの URL マップで複数のバックエンドサービスがサポートされます。各バックエンドサービスは Kubernetes Service に対応し、各バックエンドサービスは Google Cloud ヘルスチェックを参照する必要があります。このヘルスチェックはクラスタの外部で実装されるため、Kubernetes の liveness Probe または readiness Probe とは異なります。

GKE は、次の手順を使用して、Kubernetes Service に対応する各バックエンドサービスのヘルスチェックを作成します。

Service が healthCheck 情報を使用して BackendConfig CRD を参照する場合、GKE はそれを使用してヘルスチェックを作成します。Anthos Ingress コントローラと GKE Ingress コントローラの両方で、この方法によってヘルスチェックを作成できます。
Service が BackendConfig CRD を参照していない場合:
- サービスを提供する Pod で readiness Probe にヘルスチェックパラメータとして解釈できる属性があるコンテナで Pod テンプレートを使用する場合、GKE でヘルスチェックのパラメータの一部またはすべてを推定できます。実装の詳細については、readiness Probe からのパラメータ、ヘルスチェックパラメータの作成に使用できる属性のリストについては、デフォルトパラメータと推定パラメータをご覧ください。readiness Probe からのパラメータの推定は、GKE Ingress コントローラでのみサポートされています。
- Service のサービスを提供する Pod 用の Pod テンプレートに、ヘルスチェックパラメータとして解釈できる属性がある readiness Probe があるコンテナがない場合、ヘルスチェックの作成にデフォルト値が使用されます。Anthos Ingress コントローラと GKE Ingress コントローラの両方で、デフォルト値のみを使用してヘルスチェックを作成できます。

デフォルトパラメータと推定パラメータ

以下のパラメータは、BackendConfig CRD を使用して対応する Service のヘルスチェックパラメータを指定しない場合に使用されます。

ヘルスチェックパラメータ	デフォルト値	readiness Probe からの推論可能な値
プロトコル	HTTP	サービスを提供する Pod の `spec` に存在している場合: `containers[].readinessProbe.httpGet.scheme`
リクエストパス	`/`	サービスを提供する Pod の `spec` に存在している場合: `containers[].readinessProbe.httpGet.path`
リクエストホストヘッダー	`Host: backend-ip-address`	サービスを提供する Pod の `spec` に存在している場合: `containers[].readinessProbe.httpGet.httpHeaders`
想定されるレスポンス	HTTP 200 (OK)	HTTP 200 (OK) 変更できません
チェック間隔	ゾーン NEG の場合: 15 秒インスタンスグループの場合: 60 秒	サービスを提供する Pod の `spec` に存在している場合: ゾーン NEG の場合: `containers[].readinessProbe.periodSeconds` インスタンスグループの場合: `containers[].readinessProbe.periodSeconds + 60 seconds`
チェックのタイムアウト	5 秒	サービスを提供する Pod の `spec` に存在している場合: `containers[].readinessProbe.timeoutSeconds`
正常しきい値	1	1 変更できません。
異常しきい値	ゾーン NEG の場合: 2 インスタンスグループの場合: 10	デフォルトと同じ: ゾーン NEG の場合: 2 インスタンスグループの場合: 10
ポート番号で指定	ゾーン NEG の場合: Service の `port` インスタンスグループの場合: Service の `nodePort`	Ingress オブジェクトの `backend.servicePort` が Service の `port` を参照しており、以下も定義されている場合は、そのポートが使用されます。サービスを提供する Pod の readiness Prob では、以下のとおりポートを指定する必要があります。 `spec.containers[].readinessProbe.httpGet.port` Service の `targetPort` は、サービスを提供する Pod の `containers[].spec.ports.containerPort` を参照します。
宛先 IP アドレス	ゾーン NEG の場合: Pod の IP アドレスインスタンスグループの場合: ノードの IP アドレス	デフォルトと同じ: ゾーン NEG の場合: Pod の IP アドレスインスタンスグループの場合: ノードの IP アドレス

readiness Probe からのパラメータ

GKE で Service のバックエンドサービスのヘルスチェックが作成されると、その Service のサービスを提供する Pod で使用されている 1 つのコンテナの readiness Probe から特定のパラメータをコピーできます。このオプションは、GKE Ingress コントローラのみでサポートされています。

ヘルスチェックパラメータとして解釈できるサポートされている readiness Probe 属性は、デフォルトパラメータと推定パラメータでデフォルト値とともに一覧表示されています。readiness Probe に指定されていない属性、または readiness Probe がまったく指定されていない場合は、デフォルト値が使用されます。

Service のサービスを提供する Pod に複数のコンテナが含まれている場合や、Anthos Ingress コントローラを使用している場合は、BackendConfig CRD を使用してヘルスチェックパラメータを定義する必要があります。詳しくは、代わりに BackendConfig CRD を使用する場合をご覧ください。

警告: バックエンドサービスのヘルスチェックパラメータがサービスを提供する Pod の readiness Probe から推定される場合、GKE では readiness Probe とヘルスチェックが同期されません。

GKE によって Ingress の外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサが作成された後に、Ingress によって参照される Service のサービスを提供する Pod の readiness Probe を変更した場合、readiness Probe への変更は、ロードバランサ上の対応するバックエンドサービスのヘルスチェックにコピーされません。
逆に、Ingress の代わりに作成されたロードバランサのバックエンドサービスで使用されるヘルスチェックに変更を加えた場合、GKE では readiness Probe が更新されず、ヘルスチェックに加えた変更を元に戻されることもありません。

代わりに `BackendConfig` CRD を使用する場合

次の場合は、Pod の readiness Probe のパラメータに依存せずに、Service の BackendConfig CRD を作成して、バックエンドサービスのヘルスチェックパラメータを明示的に定義する必要があります。

Anthos を使用している場合: Anthos Ingress コントローラでは、サービスを提供する Pod の readiness Probe からのヘルスチェックパラメータの取得がサポートされません。ヘルスチェックの作成には、暗黙的パラメータを使用するか、BackendConfig CRD での定義に従います。
サービスを提供する Pod に一意の readiness Probe がある複数のコンテナがある場合: Service のサービスを提供する Pod に複数のコンテナがあり、各コンテナで readiness Probe 設定が異なる場合は、対応する Service で BackendConfig CRD を参照して、対応するバックエンドサービスのヘルスチェックを定義する必要があります。GKE では、サービスを提供する Pod に複数の readiness Probe が存在する場合、ヘルスチェックパラメータを推定する特定の readiness Probe を選択することはできません。
ロードバランサのヘルスチェックに使用するポートを制御する必要がある場合: GKE では、そのポートが Ingress spec.rules[].http.paths[].backend.servicePort で参照される Service のサービスポートと一致している場合、バックエンドサービスのヘルスチェックに対して、readiness Probe の containers[].readinessProbe.httpGet.port のみを使用します。

`BackendConfig` CRD からのパラメータ

対応する Service により参照される BackendConfig CRD の healthCheck パラメータを使用して、バックエンドサービスのヘルスチェックパラメータを指定できます。これにより、Ingress によって作成された Google Cloud 外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサのヘルスチェックをより柔軟に管理できるようになります。GKE のバージョンの互換性については、Ingress の機能をご覧ください。

この BackendConfig CRD の例では、spec.healthCheck 属性でヘルスチェックプロトコル（タイプ）、リクエストパス、ポート、チェック間隔を定義します。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

複数の TLS 証明書の使用

HTTP(S) ロードバランサで、your-store.example および your-experimental-store.example という名前の 2 つのホストからコンテンツを提供するとします。ここで、ロードバランサは、your-store.example 用と experimental-store.example 用で異なる証明書を使用するものとします。

これを行うには、Ingress マニフェストで複数の証明書を指定します。ロードバランサは、指定された証明書のうち、リクエストで使用されているホスト名と一致する共通名（CN）が含まれている証明書を選択します。複数の証明書を構成する方法について詳しくは、Ingress での HTTPS 負荷分散のための複数の SSL 証明書の使用をご覧ください。

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

Kubernetes Service と Google Cloud バックエンドサービスは別物です。両者の間には強い関係がありますが、その関係は必ずしも 1 対 1 ではありません。GKE Ingress コントローラは、Ingress マニフェスト内の各（serviceName、servicePort）ペア用に 1 つの Google Cloud バックエンドサービスを作成します。したがって、1 つの Kubernetes Service オブジェクトが複数の Google Cloud バックエンドサービスに関係する可能性があります。

制限事項

1.16 より前のバージョンを使用するクラスタでは、Ingress の名前空間と名前の長さの合計は 40 文字以内にする必要があります。このガイドラインに従わないと、GKE Ingress コントローラが異常動作する恐れがあります。詳細については、GitHub でこの問題をご覧ください。
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 にスケールされている場合は、デフォルトのヘルスチェックが適用されます。詳細については、こちらの問題のコメントをご覧ください。
Ingress の作成後にポッドの readinessProbe を変更しても、Ingress には影響を与えません。
外部 HTTP(S) ロードバランサは、クライアントとロードバランサの間のレイテンシを最小限に抑えるために、グローバルに分散されたロケーションで TLS を終了します。TLS の終端を指定する必要がある場合は、タイプ LoadBalancer の GKE Service で公開されている独自の Ingress コントローラを使用して、適切なリージョンにあるバックエンドで TLS を終端する必要があります。
複数の Ingress リソースを単一の Google Cloud ロードバランサに統合する操作はサポートされていません。

実装の詳細

Ingress コントローラは、Google Cloud プロジェクトからテストリソースを取得して、サービスアカウントの権限を定期的にチェックします。この名前は、k8s-ingress-svc-acct-permission-check-probe という名の（存在しない）グローバル BackendService の GET として表示されます。このリソースは通常は存在していないため、GET リクエストは「not found」というメッセージが返されます。これは想定された動作です。コントローラは、承認の問題により API 呼び出しが拒否されていないのかを確認しています。同じ名前の BackendService を作成すると、「not found」を返す代わりに GET が成功します。