ポリシーを使用して Gateway リソースを構成する

Autopilot Standard

このページでは、GKE クラスタに Gateway をデプロイするときに Google Kubernetes Engine（GKE）が作成するロードバランサの構成方法について説明します。

Gateway をデプロイすると、GatewayClass の構成により、GKE が作成するロードバランサが決まります。このマネージドロードバランサには、ポリシーで変更可能なデフォルトの設定があらかじめ構成されています。

Gateway、Service、ServiceImport にポリシーを接続して、インフラストラクチャやアプリケーションの要件に合わせて Gateway リソースをカスタマイズできます。ポリシーを適用または変更した後、Gateway リソース、Route リソース、または Service リソースの削除や再作成を行う必要はありません。ポリシーは Gateway コントローラによって処理され、基盤となるロードバランサリソースが（新しい）ポリシーに従って（再）構成されます。

始める前に

始める前に、次の作業が完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防ぐことができます。

GKE Gateway Controller の要件

Standard の場合は GKE バージョン 1.24 以降。

Autopilot の場合は GKE バージョン 1.26 以降。
Google Cloud CLI バージョン 407.0.0 以降。
Gateway API は、VPC ネイティブクラスタでのみサポートされます。
内部 GatewayClass を使用している場合は、プロキシ専用サブネットを有効にする必要があります。
クラスタで HttpLoadBalancing アドオンが有効になっている必要があります。
Istio を使用している場合は、Istio を次のいずれかのバージョンにアップグレードする必要があります。
- 1.15.2 以降
- 1.14.5 以降
- 1.13.9 以降
共有 VPC を使用している場合は、ホストプロジェクトで、サービスプロジェクトの GKE サービスアカウントに Compute Network User ロールを割り当てる必要があります。

制限事項

GKE Gateway Controller の制限事項に加えて、Gateway リソースに適用されるポリシーには、次の制限事項が適用されます。

GCPGatewayPolicy リソースは、gateway.networking.k8s.io Gateway にのみ接続できます。
GCPGatewayPolicy リソースは、ターゲットの Gateway と同じ Namespace に存在している必要があります。
単一クラスタ Gateway を使用する場合、GCPBackendPolicy と HealthCheckPolicy リソースは Service リソースを参照する必要があります。

マルチクラスタ Gateway を使用する場合、GCPBackendPolicy リソースと HealthCheckPolicy リソースは ServiceImport リソースを参照する必要があります。

1 つの Service に接続できる GCPGatewayPolicy は常に 1 つのみです。2 つの GCPGatewayPolicy ポリシーが作成され、同じ Service または ServiceImport をターゲットにしている場合、最も古いポリシーが優先され、2 番目のポリシーは接続できません。
GKE Gateway では、階層型ポリシーはサポートされていません。
HealthCheckPolicy リソースと GCPBackendPolicy リソースは、ターゲットの Service リソースまたは ServiceImport リソースと同じ Namespace に存在する必要があります。
GCPBackendPolicy リソースと HealthCheckPolicy リソースは、1 つのバックエンドサービスのみを参照できる構造になっています。
GCPBackendPolicy は、セッションアフィニティの HEADER_FIELD オプションも HTTP_COOKIE オプションもサポートしていません。

リージョン内部 Gateway のグローバルアクセスを構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

内部 Gateway でグローバルアクセスを有効にするには、Gateway リソースにポリシーを接続します。

次の GCPGatewayPolicy マニフェストは、グローバルアクセス用にリージョン内部 Gateway を有効にします。

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

マルチクラスタ Gateway のリージョンを構成する

このセクションでは、バージョン 1.30.3-gke.1225000 以降を実行している GKE クラスタで使用可能な機能について説明します。

フリートのクラスタが複数のリージョンにまたがっている場合は、クロスリージョン冗長性、低レイテンシ、データ主権などのさまざまなユースケースに合わせて、異なるリージョンにリージョン Gateway をデプロイする必要があります。マルチクラスタ Gateway 構成クラスタでは、リージョン Gateway をデプロイするリージョンを指定できます。リージョンを指定しない場合は、構成クラスタのリージョンがデフォルトリージョンになります。

マルチクラスタ Gateway のリージョンを構成するには、GCPGatewayPolicy の region フィールドを使用します。次の例では、Gateway が us-central1 リージョンに構成されています。

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

SSL ポリシーを構成してクライアントとロードバランサ間のトラフィックを保護する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

クライアントからロードバランサへのトラフィックを保護するには、ポリシーの名前を GCPGatewayPolicy に追加して SSL ポリシーを構成します。デフォルトでは、Gateway に SSL ポリシーが定義も接続もされていません。

GCPGatewayPolicy でポリシーを参照する前に、SSL ポリシーを作成してください。

次の GCPGatewayPolicy マニフェストでは、gke-gateway-ssl-policy という名前のセキュリティポリシーを指定しています。

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

ヘルスチェックを構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

HealthCheckPolicy を使用して、ロードバランサのヘルスチェック設定を制御できます。ヘルスチェックの各タイプ（http、https、grpc、http2）には、定義可能なパラメータがあります。Google Cloud は、GKE Service のバックエンドサービスごとに一意のヘルスチェックを作成します。

ロードバランサが正常に機能するには、ヘルスチェックパスが標準の「/」でない場合、ロードバランサにカスタム HealthCheckPolicy を構成する必要があります。パスに特別なヘッダーが必要な場合や、ヘルスチェックパラメータを調整する必要がある場合も、この構成が必要です。たとえば、デフォルトのリクエストパス「/」でサービスにアクセスできず、代わりに「/health」を使用して健全性を報告する場合は、それに応じて HealthCheckPolicy で requestPath を構成する必要があります。

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

サービス

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

INTERVAL: 各ヘルスチェックプローバーのチェック間隔を秒単位で指定します。これは、プローバーのチェックを開始してから次のチェックを開始するまでの時間です。このパラメータを省略すると、Google Cloud のデフォルトは、HealthCheckPolicy が指定されていない場合は 15 秒、checkIntervalSec 値なしで HealthCheckPolicy が指定されている場合は 5 秒になります。詳細については、複数のプローブと頻度をご覧ください。
TIMEOUT は、Google Cloud が Probe に対するレスポンスを待つ時間を指定します。TIMEOUT の値は INTERVAL 以下にする必要があります。単位は秒です。各プローブでは、プローブタイムアウトの前に HTTP 200（OK）レスポンスコードを配信する必要があります。
HEALTHY_THRESHOLD と UNHEALTHY_THRESHOLD: 正常から異常、または異常から正常に健全性を変更するために、少なくとも 1 つのプローバーについて、プローブの成功または失敗の連続回数を示します。これらのパラメータのいずれかを省略した場合、Google Cloud ではデフォルト値の 2 が使用されます。
PROTOCOL: ヘルスチェックの Probe システムで使用されるプロトコルを指定します。詳細については、HTTP、HTTPS、HTTP/2 での成功基準と gRPC での成功基準をご覧ください。このパラメータは必須です。
ENABLED: ロギングを有効にするかどうかを指定します。
PORT_SPECIFICATION: ヘルスチェックで固定ポート（USE_FIXED_PORT）、名前付きポート（USE_NAMED_PORT）、サービスポート（USE_SERVING_PORT）のいずれを使用するかを指定します。指定しない場合、ヘルスチェックは port フィールドと portName フィールドで指定された動作に従います。port も portName も指定されていない場合、このフィールドはデフォルトの USE_SERVING_PORT になります。
PORT: HealthCheckPolicy では、ポート番号を使用したロードバランサのヘルスチェックポートの指定のみがサポートされています。このパラメータを省略した場合、Google Cloud ではデフォルトの 80 が使用されます。ロードバランサは、Pod の IP アドレスにプローブを直接送信するため、containerPort が Service の targetPort で参照される場合でも、サービスを提供する Pod の containerPort と一致するポートを選択する必要があります。Service の targetPort で参照される containerPorts に限定されません。
PORT_NAME: InstanceGroup.NamedPort.name で定義されているポート名を指定します。port と portName の両方が定義されている場合、Google Cloud はまず port 値を考慮します。
HOST: ヘルスチェックリクエストのホストヘッダーの値。この値はホスト名の RFC 1123 定義を使用します。ただし、数値の IP アドレスは使用できません。指定しないか空のままにした場合、この値はデフォルトでヘルスチェックの IP アドレスになります。
REQUEST_PATH: ヘルスチェックリクエストのリクエストパスを指定します。指定しないか空のままにした場合、/ がデフォルトになります。
RESPONSE: レスポンスデータの先頭と照合するバイトを指定します。指定しないか空のままにした場合、GKE はすべてのレスポンスを正常と解釈します。レスポンスデータには ASCII のみを使用できます。
PROXY_HEADER: プロキシヘッダーのタイプを指定します。NONE または PROXY_V1 を使用できます。デフォルトは NONE です。
GRPC_SERVICE_NAME: gRPC サービスの名前（省略可）。すべてのサービスを指定する場合は、このフィールドを省略します。

HealthCheckPolicy フィールドの詳細については、healthChecks リファレンスをご覧ください。

Google Cloud Armor バックエンドセキュリティポリシーを構成してバックエンドサービスを保護する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

バックエンドサービスを保護するため、セキュリティポリシーの名前を GCPBackendPolicy に追加し、Google Cloud Armor バックエンドセキュリティポリシーを構成します。デフォルトでは、Gateway に Google Cloud Armor バックエンドセキュリティポリシーは定義されません。また接続もされません。

GCPBackendPolicy でポリシーを参照する前に、Google Cloud Armor バックエンドセキュリティポリシーを作成してください。リージョン Gateway を有効にする場合は、リージョン Google Cloud Armor バックエンドセキュリティポリシーを作成する必要があります。

次の GCPBackendPolicy マニフェストでは、example-security-policy という名前のバックエンドセキュリティポリシーを指定しています。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

IAP を構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

Identity-Aware Proxy（IAP）は、HTTPRoute に関連付けられたバックエンドサービスにアクセス制御ポリシーを適用します。この適用により、適切な Identity and Access Management（IAM）ロールが割り当てられた認証済みユーザーまたはアプリケーションのみが、これらのバックエンドサービスにアクセスできます。

デフォルトでは、バックエンドサービスに適用される IAP がないため、GCPBackendPolicy で明示的に IAP を構成する必要があります。

Gateway で IAP を構成するには、次の操作を行います。

GKE の IAP を有効にする BackendConfig は Ingress デプロイの場合にのみ有効のため、バックエンドの構成（BackendConfig の構成）をしないでください。
IAP のシークレットを作成します。
1. Google Cloud コンソールで、[認証情報] ページに移動します。
  
  [認証情報] に移動
2. クライアントの名前をクリックして、OAuth クライアントファイルをダウンロードします。
3. OAuth クライアントファイルから、OAuth シークレットをクリップボードにコピーします。
4. iap-secret.txt というファイルを作成します。
5. 次のコマンドを使用して、OAuth シークレットを iap-secret.txt ファイルに貼り付けます。
```
echo -n CLIENT_SECRET > iap-secret.txt
kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
```

シークレットを参照する IAP ポリシーを指定するには:

次の GCPBackendPolicy マニフェストを作成し、SECRET_NAME と CLIENT_ID をそれぞれ置き換えます。マニフェストを backend-policy.yaml として保存します。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

backend-policy.yaml マニフェストを適用します。
```
kubectl apply -f backend-policy.yaml
```

構成を確認します

IAP で GCPBackendPolicy を作成したら、ポリシーが適用されたことを確認します。
```
kubectl get gcpbackendpolicy
```
出力は次のようになります。
```
NAME             AGE
backend-policy   45m
```

詳細を確認するには、describe コマンドを使用します。

kubectl describe gcpbackendpolicy

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

Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPGatewayPolicy "default/backend-policy" was a success

バックエンドサービスのタイムアウトを構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

次の GCPBackendPolicy マニフェストでは、バックエンドサービスのタイムアウト期間を 40 秒に設定しています。デフォルトの timeoutSec フィールドは 30 秒です。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

セッションアフィニティを構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

セッションアフィニティは、次の基準に基づいて構成できます。

クライアント IP アドレス
生成した Cookie

Service にセッションアフィニティを構成すると、Gateway の localityLbPolicy 設定が MAGLEV に設定されます。

GCPBackendPolicy からセッションアフィニティの構成を削除すると、Gateway は localityLbPolicy の設定をデフォルト値の ROUND_ROBIN に戻します。

次の GCPBackendPolicy マニフェストでは、クライアント IP アドレスに基づいてセッションアフィニティを指定しています。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

次の GCPBackendPolicy マニフェストは、生成された Cookie に基づいてセッションアフィニティを指定し、Cookie の TTL を 50 秒に構成しています。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

sessionAffinity.type フィールドには、次の値を使用できます。

CLIENT_IP
GENERATED_COOKIE
NONE

コネクションドレインのタイムアウトを構成する

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

コネクションドレインのタイムアウトは、GCPBackendPolicy を使用して構成できます。コネクションドレインのタイムアウトは、接続がドレインするまで待機する時間（秒）です。タイムアウト時間は 0～3,600 秒に設定できます。デフォルト値は 0 で、この場合、コネクションドレインも無効になります。

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

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

指定されたタイムアウト期間の間、GKE は削除されたバックエンドに対する既存のリクエストが完了するまで待機します。ロードバランサは、削除されたバックエンドに新しいリクエストを送信しません。タイムアウト時間に達すると、GKE はバックエンドへの残りの接続をすべて閉じます。

HTTP アクセスロギング

このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。

デフォルトでの設定:

Gateway コントローラは、クライアントからのすべての HTTP リクエストを Cloud Logging に記録します。
サンプリングレートは 1,000,000 であるため、すべてのリクエストがログに記録されます。

GCPBackendPolicy を使用して Gateway のアクセスロギングを無効にするには、次の 3 つの方法があります。

GCPBackendPolicy に logging セクションを追加しないでおく
logging.enabled を false に設定する
logging.enabled を true に、logging.sampleRate を 0 に設定する

アクセスロギングのサンプリングレートを構成することもできます。

次の GCPBackendPolicy マニフェストでは、アクセスロギングのデフォルトのサンプルレートが変更され、指定された Service リソースに対する HTTP リクエストの 50% に設定されます。

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

このマニフェストには次のフィールドがあります。

enable: true: アクセスロギングを明示的に有効にします。ログは Logging で参照できます。
sampleRate: 500000: パケットの 50% がログに記録されるように指定します。0～1,000,000 の値を使用できます。GKE はこの値を 1,000,000 で割って [0,1] の範囲の浮動小数点値に変換します。このフィールドは、enable が true に設定されている場合にのみ機能します。sampleRate は省略可能なフィールドですが、構成する場合は enable: true も設定する必要があります。enable が true に設定され、sampleRate が指定されていない場合、GKE は enable を false に設定します。

単一クラスタ Gateway にトラフィックベースの自動スケーリングを構成する

このセクションでは、バージョン 1.30.3-gke.1225000 以降を実行している GKE クラスタで使用可能な機能について説明します。

単一クラスタ Gateway でトラフィックベースの自動スケーリングと容量ベースのロードバランシングを有効にするには、Service の容量を構成します。Service の容量によって、Pod が自動スケーリングされるか、トラフィックが他の使用可能なクラスタにオーバーフローする前に、Service が受信できるトラフィック容量を指定できます。

Service の容量を構成するには、Service および関連付けられた GCPBackendPolicy を作成します。GCPBackendPolicy マニフェストでは、Service 内の Pod ごとに 1 秒あたりのリクエスト数（RPS）の最大値を定義する maxRatePerEndpoint フィールドを使用します。次の GCPBackendPolicy マニフェストでは、最大 RPS を 10 に定義しています。

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

トラフィックベースの自動スケーリングの詳細については、ロードバランサのトラフィックに基づく自動スケーリングをご覧ください。

トラブルシューティング

同じ `Service` に複数の `GCPBackendPolicy` が接続されている

症状:

GCPBackendPolicy を Service または ServiceImport に接続すると、次のステータスの状態が発生することがあります。

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

理由:

このステータス状態は、すでに GCPBackendPolicy が接続されている Service または ServiceImport に 2 つ目の GCPBackendPolicy を接続しようとしていることを示します。

GKE Gateway では、同じ Service や ServiceImport に複数の GCPBackendPolicy を接続できません。詳細については、制限事項をご覧ください。

回避策:

すべてのカスタム構成を含む GCPBackendPolicy を 1 つ構成し、Service または ServiceImport に接続します。

Google Cloud Armor セキュリティポリシーが見つからない

症状:

リージョン Gateway で Google Cloud Armor を有効にすると、次のエラーメッセージが表示されることがあります。

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

理由:

このエラーメッセージは、指定されたリージョン Google Cloud Armor セキュリティポリシーが Google Cloud プロジェクトに存在しないことを示します。

回避策:

プロジェクトにリージョン Google Cloud Armor セキュリティポリシーを作成し、GCPBackendPolicy でこのポリシーを参照します。

次のステップ

Gateway コントローラの詳細を確認する。
リソースから Gateway を参照する方法を学習する。
Policy Types API リファレンスを確認する。
API タイプの定義を確認する。

ポリシーを使用して Gateway リソースを構成する

始める前に

GKE Gateway Controller の要件

制限事項

リージョン内部 Gateway のグローバル アクセスを構成する

マルチクラスタ Gateway のリージョンを構成する

SSL ポリシーを構成してクライアントとロードバランサ間のトラフィックを保護する

ヘルスチェックを構成する

サービス

マルチクラスタ サービス

Google Cloud Armor バックエンド セキュリティ ポリシーを構成してバックエンド サービスを保護する

サービス

マルチクラスタ サービス

IAP を構成する

サービス

マルチクラスタ サービス

バックエンド サービスのタイムアウトを構成する

サービス

マルチクラスタ サービス

セッション アフィニティを構成する

サービス

マルチクラスタ サービス

サービス

マルチクラスタ サービス

コネクション ドレインのタイムアウトを構成する

サービス

マルチクラスタ サービス

HTTP アクセス ロギング

サービス

マルチクラスタ サービス

単一クラスタ Gateway にトラフィック ベースの自動スケーリングを構成する

トラブルシューティング

同じ Service に複数の GCPBackendPolicy が接続されている

Google Cloud Armor セキュリティ ポリシーが見つからない

次のステップ

リージョン内部 Gateway のグローバルアクセスを構成する

マルチクラスタサービス

Google Cloud Armor バックエンドセキュリティポリシーを構成してバックエンドサービスを保護する

マルチクラスタサービス

マルチクラスタサービス

バックエンドサービスのタイムアウトを構成する

マルチクラスタサービス

セッションアフィニティを構成する

マルチクラスタサービス

マルチクラスタサービス

コネクションドレインのタイムアウトを構成する

マルチクラスタサービス

HTTP アクセスロギング

マルチクラスタサービス

単一クラスタ Gateway にトラフィックベースの自動スケーリングを構成する

同じ `Service` に複数の `GCPBackendPolicy` が接続されている

Google Cloud Armor セキュリティポリシーが見つからない