Ingress の機能

このページでは、Google Cloud で Kubernetes Ingress を通じてサポートされ、構成可能な機能について包括的な概要を示します。Google Kubernetes Engine(GKE)と Anthos の Ingress では、Google Cloud VPC ネットワークとの緊密な統合によりエンタープライズクラス向けの負荷分散を行うことができます。

機能の比較

Google Cloud でサポートされている Ingress の機能の一覧については、次の表をご覧ください。

Ingress クラス 外部 Ingress 内部 Ingress 複数クラスタ Ingress
Ingress コントローラ GKE Ingress
(GKE マスターでホスト)
Anthos Ingress
(Google がホスト)
Google Cloud ロードバランサのタイプ 外部 HTTP(S) 負荷分散 内部 HTTP(S) 負荷分散 外部 HTTP(S) 負荷分散
クラスタのスコープ 単一クラスタ 単一クラスタ 複数クラスタ
ロードバランサのスコープ グローバル リージョン グローバル
バージョン サポート すべて GKE 1.16.5 以降 GKE 1.14 以降
環境サポート GKE GKE GKE
共有 VPC のサポート対応 サポート対象 非対応 サポート対象
Service アノテーション
コンテナ ネイティブの負荷分散(NEG)
ロードバランサからバックエンドへの HTTPS
HTTP/2
Ingress アノテーション
静的 IP アドレス
Kubernetes Secret ベースの証明書
Google セルフマネージド SSL 証明書
Google マネージド SSL 証明書
FrontendConfig(ベータ版
SSL ポリシー
1.17.6-gke.11B
BackendConfig
バックエンド サービスのタイムアウト
Cloud CDN
コネクション ドレインのタイムアウト
カスタムのロードバランサのヘルスチェック構成
1.17.6-gke.11B

1.17.6-gke.11B
Google Cloud Armor セキュリティ ポリシー
HTTP アクセス ロギングの構成
1.16.10-gke.6G

1.16.10-gke.6B
Identity-Aware Proxy(IAP)
セッション アフィニティ
ユーザー定義のリクエスト ヘッダー
1.15.3-gke.1G

G この機能は、指定したバージョン以降の一般提供リリースとしてサポートされます。

B この機能は、指定したバージョン以降のベータ版で利用できます。バージョンが表示されていない機能は、利用可能なすべての GKE と Anthos のバージョンでサポートされています。

Ingress 機能の構成

デフォルトのコントローラを使用して Ingress を作成する場合、Ingress オブジェクトのアノテーションを使用して、ロードバランサのタイプ(外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサ)を選択できます。GKE でゾーン NEG を作成するか、各 Service オブジェクトでアノテーションを使用してインスタンス グループを使用するかを選択できます。

FrontendConfig と BackendConfig のカスタム リソース定義(CRD)を使用することで、ロードバランサをさらにカスタマイズできます。これらの CRD を使用すると、アノテーションよりも構造化された方法で、追加のロードバランサ機能を階層的に定義できます。FrontendConfig 構成は Ingress オブジェクトで参照され、BackendConfig 構成は Service オブジェクトによって参照されます。構成の整合性を保つために、複数の Service オブジェクトまたは Ingress オブジェクトで同じ CRD を参照できます。FrontendConfig と BackendConfig CRD は、対応する Ingress リソースと Service リソースと同じライフサイクルを共有し、多くの場合一緒にデプロイされます。

次の図は、その方法を示しています。

  • Ingress または MultiClusterIngress オブジェクトのアノテーションは、FrontendConfig CRD を参照します。FrontendConfig CRD は Google Cloud SSL ポリシーを参照します。

  • Service または MultiClusterService オブジェクトのアノテーションは、BackendConfig CRD を参照します。BackendConfig CRD は、対応するバックエンド サービスのヘルスチェックのカスタム設定を指定します。

BackendConfig と FrontendConfig の概要
図: BackendConfig と FrontendConfig の概要

FrontendConfig の Ingress への関連付け

FrontendConfig CRD は、Ingress または MultiClusterIngress リソースのアノテーションによって参照されます。FrontendConfig は、次の例に示すように、Ingress / MultiClusterIngress リソース全体に対応します。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "frontendconfig"
...

BackendConfig の Ingress への関連付け

BackendConfig CRD は、Service または MultiClusterService リソースのアノテーションによって参照されます。Service または MultiClusterService は、cloud.google.com/backend-config アノテーションを使用して BackendConfig の名前を指定します。Service または MultiClusterService と関連付けられている場合、BackendConfig は Google Cloud バックエンド サービスの設定を特定できます。次の例は、BackendConfig を Service または MultiClusterService に追加する方法を示しています。default キーは、Service 内のすべてのポートが Ingress によって参照される場合に my-backendconfig BackendConfig に関連付けられることを意味します。

1.16-gke.3 以降

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

サポートされているすべてのバージョン

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

同じ Service 内の異なるポートに一意の BackendConfig 設定が必要な場合は、特定の BackendConfig リソースをそれらのポートに明示的に関連付けることができます。次の例の ports キーを使用すると、ポートの明示的リンクが可能になります。

1.16-gke.3 以降

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: service-port-2
...

サポートされているすべてのバージョン

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: >service-port-2
...

port-1 は、番号(service-port-1)または名前(service-name-1)で Service 内のポートを参照できます(GKE でのみサポートされます)。各ポートは Google Cloud ロードバランサのバックエンド サービスにマッピングされ、Service 内のポートにさまざまな構成を割り当てることができます。

FrontendConfig パラメータによる Ingress 機能の構成

次のセクションでは、特定の Ingress 機能を有効にするように FrontendConfig を設定する方法について説明します。

SSL ポリシー

SSL ポリシーを使用すると、ロードバランサがクライアントからの HTTPS トラフィックを終了するために使用する一連の TLS バージョンと暗号を指定できます。まず、GKE の外部で SSL ポリシーを作成する必要があります。作成すると、FrontendConfig CRD で参照できます。

FrontendConfig の sslPolicy フィールドは、GKE クラスタと同じ Google Cloud プロジェクト内の SSL ポリシーの名前を参照します。Ingress によって外部 HTTP(S) ロードバランサ用に作成されたターゲット HTTPS プロキシに SSL ポリシーが追加されます。複数の Ingress リソースで同じ FrontendConfig リソースと SSL ポリシーを参照できます。参照された SSL ポリシーが変更されると、Ingress によって作成された外部 HTTP(S) ロードバランサを実装する Google Front End(GFE)に変更が反映されます。

次の FrontendConfig マニフェストは、gke-ingress-ssl-policy という名前の SSL ポリシーを有効にします。

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

BackendConfig パラメータによる Ingress 機能の構成

次のセクションでは、特定の Ingress 機能を有効にするように BackendConfig を設定する方法について説明します。BackendConfig リソースへの変更は常に調整されるため、Ingress を削除して再作成しなくても BackendConfig の変更が反映されていることを確認できます。

BackendConfig の制限事項については、制限事項のセクションをご覧ください。

バックエンド サービスのタイムアウト

BackendConfig を使用して、バックエンド サービスのタイムアウト期間を秒単位で設定できます。値を指定しない場合、デフォルト値は 30 秒です。

次の BackendConfig マニフェストは、40 秒のタイムアウトを指定します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

BackendConfig を使用して、Cloud CDN を有効にできます。

次の BackendConfig マニフェストには、Cloud CDN を有効にするときに使用できるすべてのフィールドが表示されます。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

以下を置き換えます。

  • cdnEnabled: true に設定すると、この Ingress バックエンドの Cloud CDN が有効になります。
  • includeHost: true に設定すると、異なるホストへのリクエストは個別にキャッシュされます。
  • includeProtocol: true に設定すると、HTTP リクエストと HTTPS リクエストは個別にキャッシュされます。
  • includeQueryString: true に設定すると、queryStringBlacklist または queryStringWhitelist に従ってクエリ文字列パラメータがキャッシュキーに含まれます。どちらも設定されていない場合は、クエリ文字列全体が含まれます。false に設定すると、クエリ文字列全体がキャッシュキーから除外されます。
  • queryStringBlacklist: キャッシュキーから除外するクエリ文字列パラメータの名前を含む文字列配列を指定します。これ以外のパラメータはすべて含まれます。queryStringBlacklist または queryStringWhitelist を指定できますが、両方は指定できません。
  • queryStringWhitelist: キャッシュキーに含めるクエリ文字列パラメータの名前を含む文字列配列を指定します。これ以外のパラメータはすべて除外されます。queryStringBlacklist または queryStringWhitelist を使用できますが、両方は使用できません。

Ingress によって Cloud CDN をデプロイし、アプリケーション コンテンツがキャッシュに保存されていることを確認する例を見るには、次のセクションを展開してください。

コネクション ドレインのタイムアウト

コネクション ドレインのタイムアウトは、BackendConfig を使用して構成できます。コネクション ドレインのタイムアウトは、接続がドレインするまで待機する時間(秒)です。指定されたタイムアウト期間の間、除外されたバックエンドに対する既存のリクエストに、完了するまでの時間が与えられます。ロードバランサは、削除されたバックエンドに新しいリクエストを送信しません。タイムアウト時間に達すると、バックエンドに対する残りの接続がすべて閉じます。タイムアウト時間は 0~3,600 秒に設定できます。デフォルト値は 0 で、この場合コネクション ドレインも無効になります。

次の BackendConfig マニフェストは、コネクション ドレインのタイムアウトを 60 秒に指定します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

カスタム ヘルスチェックの構成

Ingress によってデプロイされるときに、GKE で Google Cloud ロードバランサのヘルスチェックを構成する方法は多岐におよびます。GKE Ingress によるヘルスチェックのデプロイ方法の詳細については、Ingress ヘルスチェックをご覧ください。

これを行うための 1 つの方法は、BackendConfig を使用してヘルスチェックを明示的に構成することです。設定すると、これらのパラメータは Kubernetes Readiness Probe の設定とヘルスチェックのデフォルト値よりも優先されます。

再利用可能なテンプレートとして同じ BackendConfig を参照するように複数の GKE Service を構成できます。healthCheck パラメータについては、各 GKE Service に対応するバックエンド サービスごとに一意の Google Cloud ヘルスチェックが作成されます。

次の BackendConfig マニフェストは、BackendConfig ヘルスチェックの構成時に使用可能なすべてのフィールドを示します。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: interval
    timeoutSec: timeout
    healthyThreshold: health-threshold
    unhealthyThreshold: unhealthy-threshold
    type: protocol
    requestPath: path
    port: port

以下を置き換えます。

  • interval: 各ヘルスチェック プローバーの check-interval を秒単位で指定します。これは、プローバーのチェックを開始してから次のチェックを開始するまでの時間です。このパラメータを省略すると、Google Cloud のデフォルトの 5 秒が使用されます。実装の詳細については、複数のプローブと頻度をご覧ください。
  • timeout: Google Cloud でプローブへのレスポンスを待機する時間を指定します。timeout の値は、interval 以下にする必要があります。単位は秒です。各プローブでは、タイムアウトの前に HTTP 200 (OK) レスポンス コードが配信される必要があります。
  • health-thresholdunhealthy-threshold: 正常から異常、または異常から正常に健全性を変更するために、少なくとも 1 つのプローバーについて、プローブの成功または失敗の連続回数を示します。これらのパラメータのいずれかを省略した場合、Google Cloud ではデフォルト値の 2 が使用されます。
  • protocol: ヘルスチェックのためにプローブ システムで使用されるプロトコルを指定します。BackendConfig は、HTTP、HTTPS、または HTTP2 プロトコルを使用したヘルスチェックの作成のみをサポートします。詳細については、HTTP、HTTPS、HTTP/2 での成功基準をご覧ください。このパラメータは省略できません。
  • path: HTTP、HTTPS、または HTTP2 のヘルスチェックの場合は、プローブ システムが接続する request-path を指定します。このパラメータを省略した場合、Google Cloud ではデフォルトの / が使用されます。
  • port: ポート番号を使用してポートを指定します。このパラメータを省略した場合、Google Cloud ではデフォルトの 80 が使用されます。コンテナ ネイティブの負荷分散を使用している場合、プローブ システムはサービスを提供している Pod の IP アドレスに接続します。それ以外の場合、ヘルスチェックのプローブはサービスを提供している Pod が実行されているノードの IP アドレスに接続します。

Google Cloud Armor セキュリティ ポリシー

Google Cloud Armor セキュリティ ポリシーは、負荷分散されたアプリケーションをウェブベースの攻撃から保護するのに役立ちます。Google Cloud Armor セキュリティ ポリシーを構成すると、BackendConfig を使用して参照できます。

セキュリティ ポリシーの名前を BackendConfig に追加します。次の BackendConfig マニフェストでは、example-security-policy という名前のセキュリティ ポリシーを指定しています。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

HTTP アクセス ロギング

Ingress は、クライアントからのすべての HTTP リクエストを Cloud Logging に記録できます。アクセス ロギングを有効または無効にするには、BackendConfig とアクセス ロギングのサンプリング レートの設定を使用します。

アクセス ロギングを構成するには、BackendConfig の logging フィールドを使用します。logging を省略すると、アクセス ロギングはデフォルトの動作を実行します。これは GKE のバージョンによって異なります。アクセス ロギングは、GKE 1.18 より前のすべてのバージョンではデフォルトで「オン」に設定されていますが、1.16.8-gke.10 以降では構成可能なフィールドとして公開されています。

次のフィールドを構成できます。

  • enable: true に設定した場合、この Ingress のアクセス ロギングが有効になり、ログが Cloud Logging で使用できるようになります。それ以外の場合、この Ingress のアクセス ロギングは無効になります。
  • sampleRate: 0.0 から 1.0 までの値を指定します。0.0 の場合、パケットをまったくログに記録されません。1.0 の場合、すべてのパケットがログに記録されます。このフィールドは、enabletrue に設定されている場合にのみ機能します。sampleRate はオプションのフィールドですが、構成されている場合は enable: true も設定する必要があります。設定しなければ、enable: false と解釈されます。

次の BackendConfig マニフェストは、アクセス ロギングを有効にし、特定の Ingress リソースに対する HTTP リクエストのサンプルレートを 50% に設定します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Identity-Aware Proxy IAP の BackendConfig を構成するには、BackendConfig の iap ブロックに enabledsecretName の値を指定する必要があります。これらの値を指定するには、compute.backendServices.update 権限が必要です。

次の BackendConfig マニフェストは、Identity-Aware Proxy を有効にします。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

詳細な手順については、IAP のドキュメントの GKE での IAP の有効化をご覧ください。

セッション アフィニティ

BackendConfig を使用して、セッション アフィニティをクライアント IP または生成された Cookie に設定できます。

クライアント IP アフィニティ

BackendConfig を使用してクライアント IP アフィニティを設定するには、次の例のように affinityType"CLIENT_IP" に設定します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

BackendConfig を使用して生成された Cookie アフィニティを設定するには、BackendConfig マニフェストで affinityTypeGENERATED_COOKIE に設定します。また、affinityCookieTtlSec を使用して、Cookie を有効のままにしておく期間を設定することもできます。

次のマニフェストでは、アフィニティ タイプを生成された Cookie に設定し、Cookie の TTL を 50 秒に設定します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

ユーザー定義のリクエスト ヘッダー

BackendConfig を使用して、ユーザー定義のリクエスト ヘッダーを構成できます。ロードバランサは、指定したヘッダーをバックエンドに転送するリクエストに追加します。

ユーザー定義のリクエスト ヘッダーを有効にするには、BackendConfig リソースの customRequestHeaders プロパティにヘッダーのリストを指定します。各ヘッダーを header-name:header-value 文字列として指定します。

次の BackendConfig マニフェストは、3 つのリクエスト ヘッダーを追加します。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

演習: バックエンド サービスを使用した Ingress タイムアウトの設定

次の演習では、BackendConfig リソースを使用して Ingress でタイムアウトとコネクション ドレインを構成するために必要な手順を示します。

Ingress のバックエンド プロパティを構成するには、次の操作を行います。

  1. Deployment を作成します
  2. BackendConfig を作成します
  3. Service を作成し、そのポートの 1 つを BackendConfig に関連付けます
  4. Ingress を作成して、その Ingress を(Service、ポート)ペアに関連付けます
  5. バックエンド サービスのプロパティを検証します
  6. クリーンアップします。

Deployment を作成する

BackendConfig と Service を作成する前に、Deployment を作成する必要があります。

次のマニフェストの例では、my-deployment.yaml という Deployment になります。

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0

次のコマンドを実行して Deployment を作成します。

kubectl apply -f my-deployment.yaml

BackendConfig を作成する

BackendConfig を使用して、使用する Ingress 機能を指定します。

この my-backendconfig.yaml という名前の BackendConfig マニフェストでは、以下を指定しています。

  • タイムアウトを 40 秒に設定しています。
  • コネクション ドレインのタイムアウトを 60 秒に設定しています。
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

BackendConfig を使用して設定できる機能の一覧については、機能表の BackendConfig のセクションを参照してください。

次のコマンドを実行して BackendConfig を作成します。

kubectl apply -f my-backendconfig.yaml

Service の作成

BackendConfig は、Service に複数のポートがある場合でも、単一の Service と Port の組み合わせに対応します。各ポートは、1 つの BackendConfig CRD に関連付けることができます。Ingress が Service ポートを参照し、その Service ポートが BackendConfig に関連付けられている場合、HTTP(S) 負荷分散バックエンド サービスは BackendConfig による構成に影響を与えます。

my-service.yaml という名前の Service マニフェストの例を次に示します。

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

cloud.google.com/backend-config アノテーションでは、ポートと BackendConfig オブジェクトの間のマッピングが指定されます。my-service.yaml で:

  • purpose: bsc-config-demo というラベルを持つすべての Pod は Service のメンバーです。
  • Service の TCP ポート 80 が my-backendconfig という名前の BackendConfig に関連付けられています。これは、cloud.google.com/backend-config アノテーションで指定されています。
  • Service のポート 80 に送信されたリクエストは、いずれかのメンバー Pod(ポート 8080)に転送されます。

Service を作成するには、次のコマンドを実行します。

kubectl apply -f my-service.yaml

Ingress を作成する

次の my-ingress.yaml. という名前の Ingress マニフェストの例では、my-service という名前の Service のポート 80 に受信リクエストがルーティングされています。

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

Ingress を作成するには、次のコマンドを実行します。

kubectl apply -f my-ingress.yaml

Ingress コントローラが HTTP(S) 負荷分散と関連するバックエンド サービスを構成するまで数分待ちます。上記の手順が完了すると、Ingress が 40 秒のタイムアウトと 60 秒のコネクション ドレインのタイムアウトを使用するように構成されます。

バックエンド サービスのプロパティを確認する

BackendConfig を使用して、正しいロードバランサの設定が適用されていることを確認できます。これを行うには、Ingress がデプロイしたバックエンド サービスを特定し、その設定を調べて Deployment マニフェストと一致していることを確認します。

まず、my-ingress リソースを記述し、Ingress に関連付けられたバックエンド サービスを一覧表示するアノテーションをフィルタリングします。例:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

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

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

出力には、バックエンド サービスに関する情報が表示されます。たとえば、このアノテーションには 2 つのバックエンド サービスが含まれています。

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" は、my-service Kubernetes Service に関連したバックエンド サービスに関する情報を示しています。
    • k8s1-27fde173 は、クラスタの説明に使用されるハッシュです。
    • default は Kubernetes 名前空間です。
    • HEALTHY は、バックエンドが正常であることを示します。
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" は、デフォルトのバックエンド(404 サーバー)に関連したバックエンド サービスに関する情報を示しています。
    • k8s1-27fde173 は、クラスタの説明に使用されるハッシュです。
    • kube-system は名前空間です。
    • default-http-backend Kubernetes Service の名前です。
    • 80 はホストのポートです。
    • HEALTHY は、バックエンドが正常であることを示します。

次に、gcloud を使用して、my-service に関連付けられているバックエンド サービスを検査します。"drainingTimeoutSec""timeoutSec" をフィルタリングして、Google Cloud ロードバランサのコントロール プレーンで設定されていることを確認します。例:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

出力:

  drainingTimeoutSec: 60
  timeoutSec: 40

出力に drainingTimeoutSectimeoutSec が表示されていることで、BackendConfig で値が正しく設定されていることを確認できます。

クリーンアップ

アカウントで不要な料金が発生しないように、この演習用に作成した Kubernetes オブジェクトを削除します。

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

BackendConfig の制限事項

BackendConfig には次の制限があります。

  • 複数の Ingress オブジェクトが(Service、ポート)を参照する場合でも、1 つの(Service、ポート)ペアが使用できるのは 1 つの BackendConfig だけです。つまり、同じ(Service、ポート)を参照するすべての Ingress オブジェクトで、Google Cloud Armor、IAP、Cloud CDN に対する構成を同一にする必要があります。

  • IAP と Cloud CDN を同じ HTTP(S) 負荷分散バックエンド サービスで有効にすることはできません。つまり、同じ BackendConfig に IAP と Cloud CDN の両方を構成することはできません。

  • BackendConfig を使用して操作する場合、kubectl 1.7 以降を使用する必要があります。

FrontendConfig または BackendConfig で指定された構成の削除

Ingress 機能を取り消すには、FrontendConfig または BackendConfig CRD で機能構成を明示的に無効にする必要があります。Ingress コントローラは、これらの CRD で指定された構成のみを調整します。

以前に有効にした構成を消去または無効にするには、フィールド タイプに応じてフィールドの値を空の文字列("")または false のブール値に設定します。

次の BackendConfig マニフェストは、Google Cloud Armor セキュリティ ポリシーと Cloud CDN を無効にします。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

FrontendConfig または BackendConfig の削除

FrontendConfig

FrontendConfig を削除するには、次の手順に従います。

  1. Ingress マニフェストの networking.gke.io/v1beta1.FrontendConfig アノテーションから FrontendConfig の名前を削除します。

  2. 変更した Ingress マニフェストをクラスタに適用します。たとえば、kubectl apply を使用します。

  3. FrontendConfig を削除します。たとえば、kubectl delete frontendconfig config my-frontendconfig を使用します。

BackendConfig

BackedConfig を削除するには、次の手順に従います。

  1. Service マニフェストの cloud.google.com/backend-config アノテーションから BackendConfig の名前を削除します。

  2. 変更された Service マニフェストをクラスタに適用します。たとえば、kubectl apply を使用します。

  3. BackendConfig を削除します。たとえば、kubectl delete backendconfig my-backendconfig を使用します。

トラブルシューティング

BackendConfig が見つかりません

このエラーは、Service のアノテーションで Service ポートの BackendConfig が指定されているにもかかわらず BackendConfig リソースが見つからなかった場合に発生します。これが発生するのは、BackendConfig リソースが作成されていなかった場合、誤った名前空間に作成された場合、または Service アノテーションの参照にスペルミスがあった場合です。

Kubernetes イベントを評価するには、次のコマンドを実行します。

kubectl get event

次のタイプの出力は、BackendConfig が見つからなかったことを示します。

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

セキュリティ ポリシーが見つかりません

Ingress オブジェクトが作成された後で、セキュリティ ポリシーがロードバランサ サービスと適切に関連付けられていない場合は、Kubernetes イベントを検査して構成ミスがないか調べてください。BackendConfig が存在しないポリシーを指定している場合は、警告イベントが定期的に発生します。この問題を修正するには、BackendConfig で正しいセキュリティ ポリシーを、名前で指定してください。

Kubernetes イベントを評価するには、次のコマンドを実行します。

kubectl get event

次のタイプの出力は、セキュリティ ポリシーが見つからなかったことを示します。

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

次のステップ