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

このページでは、外部アプリケーション ロードバランサの Ingress の概要と仕組みについて説明します。Google Kubernetes Engine（GKE）では、GKE Ingress と呼ばれる、組み込みのマネージド Ingress コントローラを使用できます。GKE で Ingress リソースを作成すると、コントローラは HTTP または HTTP(S) トラフィックが Service に到達できるように HTTP(S) ロードバランサを自動的に構成します。

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

概要

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

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

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

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

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

• 外部アプリケーション ロードバランサ用の Ingress は、従来のアプリケーション ロードバランサをデプロイします。インターネットに接続するこのロードバランサは、管理されたスケーラブルなロード バランシング リソースのプールとして Google のエッジ ネットワークにグローバルにデプロイされます。外部アプリケーション ロードバランサ用に Ingress を設定して使用する方法を確認します。

• 内部アプリケーション ロードバランサ用の Ingress は、内部アプリケーション ロードバランサをデプロイします。これらの内部アプリケーション ロードバランサは、GKE クラスタ外部、ただし VPC ネットワーク内部の Envoy プロキシ システムを利用しています。内部ロードバランサに Ingress を設定して使用する方法を確認します。

GKE Ingress コントローラの動作

GKE バージョン 1.18 以降を実行しているクラスタの場合、GKE Ingress コントローラで Ingress が処理されるかどうかは、kubernetes.io/ingress.class アノテーションの値によって決まります。

古いバージョンの GKE を実行しているクラスタの場合、GKE コントローラは、kubernetes.io/ingress.class アノテーションがないか、値が gce または gce-internal のアノテーションがある Ingress を処理します。

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

kubernetes.io/ingress.class アノテーションは Kubernetes で非推奨になりましたが、GKE では引き続きこのアノテーションが使用されます。

ingressClassName フィールドを使用して GKE Ingress を指定することはできません。kubernetes.io/ingress.class アノテーションを使用する必要があります。

外部アプリケーション ロードバランサの機能

Ingress によって構成された外部アプリケーション ロードバランサには、次の機能があります。

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

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

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

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

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

コンテナ ネイティブのロード バランシングとは、GKE 内の Pod エンドポイントに直接ロード バランシングを行う手法のことです。コンテナ ネイティブのロード バランシングは、ネットワーク エンドポイント グループ（NEG）の一種です。

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}' を明示的に付けます。内部アプリケーション ロードバランサの Ingress を使用して NEG を無効にすることはできません。

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

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

インスタンス グループ

インスタンス グループを使用する場合、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 エラーが発生するをご覧ください。

共有 VPC

Ingress リソースと MultiClusterIngress リソースは共有 VPC でサポートされていますが、追加の準備が必要です。

Ingress コントローラは GKE コントロール プレーンで動作し、クラスタのプロジェクトの GKE サービス アカウントを使用して Google Cloud への API 呼び出しを行います。デフォルトでは、共有 VPC サービス プロジェクトにあるクラスタが共有 VPC ネットワークを使用している場合、Ingress コントローラはホスト プロジェクトでサービス プロジェクトの GKE サービス アカウントを使用して、上り（内向き）許可ファイアウォール ルールの作成と更新を実行できません。

ホスト プロジェクトで VPC ファイアウォール ルールを作成および管理する権限をサービス プロジェクトの GKE サービス アカウントに付与できます。これらの権限を付与することで、GKE は次のものに対して上り（内向き）許可ファイアウォール ルールを作成します。

• 外部 Ingress 用の外部アプリケーション ロードバランサで使用される Google Front End（GFE）のプロキシとヘルスチェック システム。詳細については、外部アプリケーション ロードバランサの概要をご覧ください。

• 内部 Ingress で使用される内部アプリケーション ロードバランサのヘルスチェック システム。

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

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

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

1. 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 security 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,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`
   

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

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

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

サービス プロジェクトの GKE クラスタで、ホスト プロジェクトのファイアウォール リソースを作成して管理するには、次のいずれかの方法で、サービス プロジェクトの GKE サービス アカウントに適切な IAM 権限を付与する必要があります。

• サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトに対する Compute セキュリティ管理者のロールを付与します。次の例は、この方法を示しています。

• より細かく設定する場合は、カスタム IAM ロールを作成し、compute.networks.updatePolicy、compute.firewalls.list、compute.firewalls.get、compute.firewalls.create、compute.firewalls.update、compute.firewalls.delete、compute.subnetworks.list 権限のみを含めます。サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトに対するこのカスタムロールを付与します。

複数のサービス プロジェクトにクラスタがある場合は、いずれかの方法を選択して、サービス プロジェクトの GKE サービス アカウントごとに繰り返す必要があります。

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

次のように置き換えます。

• HOST_PROJECT_ID: 共有 VPC ホスト プロジェクトのプロジェクト ID。
• SERVICE_PROJECT_NUMBER: クラスタを含むサービス プロジェクトのプロジェクト番号。

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

各外部アプリケーション ロードバランサまたは内部アプリケーション ロードバランサは、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 のセットに関連付けられます。

同じホストに複数のバックエンドを持つ GKE Ingress を構成する場合は、単一のホストと複数のパスを備えた単一のルールが必要です。それ以外の場合、GKE Ingress コントローラは 1 つのバックエンド サービスのみをプロビジョニングします。

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

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

Ingress を作成すると、GKE Ingress コントローラで、Ingress とそれに関連する Service の情報に沿って、外部アプリケーション ロードバランサまたは内部アプリケーション ロードバランサが作成されて構成されます。また、ロードバランサには、ドメイン名に関連付けることのできる固定 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 のデフォルトのバックエンドを指定するには、Ingress マニフェストで spec.defaultBackend フィールドを指定します。これにより、rules フィールドで定義されたパスと一致しないリクエストがすべて処理されます。たとえば、次の Ingress では、/discounted と一致しないリクエストが my-products という Service のポート 60001 に送信されます。

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

デフォルトのバックエンドを指定しない場合、GKE は 404 を返すバックエンドをデフォルトにします。これは、kube-system Namespace のクラスタ上に default-http-backend NodePort Service として作成されます。

404 HTTP レスポンスは次のようになります。

response 404 (backend NotFound), service rules for the path non-existent

ユーザーのデフォルト バックエンドを使用して GKE Ingress を設定するには、カスタム デフォルト バックエンドを使用した GKE Ingress をご覧ください。

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 の結果として作成されます。

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

SSL 証明書を HTTP(S) ロードバランサに指定するには、次の方法を使用します。

Google マネージド証明書

Google マネージド SSL 証明書は、ドメインに対してプロビジョニング、デプロイ、更新、管理されます。マネージド証明書はワイルドカード ドメインをサポートしません。

Google Cloud と共有されるセルフマネージド証明書

独自の SSL 証明書をプロビジョニングして、Google Cloud プロジェクトで証明書リソースを作成できます。その後、証明書リソースを Ingress のアノテーションでリストして、証明書を使用する HTTP(S) ロードバランサを作成できます。詳しくは、事前共有証明書に関する説明をご覧ください。

Secret リソースとしてのセルフマネージド証明書

自身の SSL 証明書をプロビジョニングして、それを保持するための Secret を作成できます。Ingress 仕様の Secret を参照して、証明書を使用する HTTP(S) ロードバランサを作成できます。詳細については、Secret で証明書を使用する際の手順をご覧ください。

ヘルスチェック

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

ロードバランサのヘルスチェックは、バックエンド サービスごとに指定されます。ロードバランサのすべてのバックエンド サービスに同じヘルスチェックを実施できますが、ロードバランサ全体に対してはヘルスチェック リファレンスが（Ingress オブジェクト自体では）指定されません。

GKE は、次のいずれかの方法に基づいてヘルスチェックを作成します。

• BackendConfig CRD: Service がロードバランサとやり取りする方法を正確に制御できるカスタム リソース定義（CRD）。BackendConfig CRD を使用すると、対応するバックエンド サービスに関連付けられたヘルスチェックのカスタム設定を指定できます。これらのカスタム設定により、従来のアプリケーション ロードバランサと Ingress によって作成された内部アプリケーション ロードバランサの両方のヘルスチェックをより柔軟に制御できます。
• Readiness プローブ: Pod 内のコンテナがトラフィックを処理する準備ができているかどうかを判断する診断チェック。GKE Ingress コントローラは、その Service のサービスを提供する Pod で使用されている readinessProbe に基づいて、Service のバックエンド サービスのヘルスチェックを作成します。パス、ポート、プロトコルなどのヘルスチェック パラメータは、readinessProbe の定義から導出できます。
• デフォルト値: BackendConfig CRD を構成しない場合や、readinessProbe の属性を定義しない場合、このパラメータが使用されます。

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

• Service が healthCheck 情報を使用して BackendConfig CRD を参照する場合、GKE はそれを使用してヘルスチェックを作成します。このヘルスチェックの作成方法は、GKE Enterprise Ingress コントローラと GKE Ingress コントローラの両方でサポートされます。

• Service が BackendConfig CRD を参照していない場合:

  • サービスを提供する Pod で readiness Probe にヘルスチェック パラメータとして解釈できる属性があるコンテナで Pod テンプレートを使用する場合、GKE でヘルスチェックのパラメータの一部またはすべてを推定できます。実装の詳細については、readiness Probe からのパラメータ、ヘルスチェック パラメータの作成に使用できる属性のリストについては、デフォルト パラメータと推定パラメータをご覧ください。readiness Probe からのパラメータの推定は、GKE Ingress コントローラでのみサポートされています。

  • Service のサービスを提供する Pod 用の Pod テンプレートに、ヘルスチェック パラメータとして解釈できる属性がある readinessProbe があるコンテナがない場合、ヘルスチェックの作成にデフォルト値が使用されます。GKE Enterprise Ingress コントローラと GKE Ingress コントローラの両方で、デフォルト値のみを使用してヘルスチェックを作成できます。

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

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

readiness Probe からのパラメータ

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

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

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

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

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

• GKE Enterprise を使用している場合: GKE Enterprise Ingress コントローラは、サービスを提供する Pod の readinessProbe からのヘルスチェック パラメータの取得をサポートしていません。ヘルスチェックの作成には、暗黙的パラメータを使用するか、BackendConfig CRD での定義に従います。

• サービスを提供する Pod に複数のコンテナがある場合:GKE には、ヘルスチェック パラメータを表示する特定のコンテナの readiness Probe を選択する方法がありません。各コンテナには独自の readiness Probe があり、readiness Probe はコンテナに必要なパラメータではないため、対応するサービスのBackendConfig CRD を参照して、対応するバックエンド サービスのヘルスチェックを定義する必要があります。

• ロードバランサのヘルスチェックに使用するポートを制御する必要がある場合: GKE では、そのポートが Ingress spec.rules[].http.paths[].backend.servicePort で参照される Service のサービスポートと一致している場合、バックエンド サービスのヘルスチェックに対して、readiness Probe の containers[].readinessProbe.httpGet.port のみを使用します。

BackendConfig CRD からのパラメータ

対応する Service により参照される BackendConfig CRD の healthCheck パラメータを使用して、バックエンド サービスのヘルスチェック パラメータを指定できます。これにより、従来のアプリケーション ロードバランサまたは Ingress によって作成された内部アプリケーション ロードバランサのヘルスチェックをより柔軟に制御できるようになります。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

BackendConfig ヘルスチェックを構成するときに使用可能なすべてのフィールドを構成するには、カスタム ヘルスチェックの構成の例を使用します。

カスタム HTTP ヘルスチェックを使用して GKE Ingress を設定する方法については、カスタム HTTP ヘルスチェックを使用した GKE Ingress をご覧ください。

複数の 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 マニフェスト内の各（service.name、service.port）ペア用に 1 つの Google Cloud バックエンド サービスを作成します。したがって、1 つの Kubernetes Service オブジェクトが複数の Google Cloud バックエンド サービスに関係する可能性があります。

制限事項

• 1.16 より前のバージョンを使用するクラスタでは、Ingress の Namespace と名前の長さの合計は 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 にスケールされている場合は、デフォルトのヘルスチェックが適用されます。詳しくは、ヘルスチェックに関する GitHub の問題のコメントをご覧ください。

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

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

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

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

実装の詳細

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

Ingress 構成のテンプレート

• GKE ネットワーキング レシピの Ingress セクションでは、Ingress の一般的な使用に関して GKE が提供しているテンプレートを確認できます。

次のステップ

• GKE ネットワーキング レシピについて学習する
• Google Cloud でのロード バランシングの詳細を確認する。
• GKE でのネットワーキングの概要を読む。
• 内部ロードバランサ用の Ingress の構成方法を学習する。
• 外部ロードバランサ用の Ingress の構成方法を学習する。