このページは Cloud Translation API によって翻訳されました。

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

このページでは、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 では、このドキュメントのコマンドを実行できない場合があります。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

すでに Autopilot クラスタまたは Standard クラスタが存在していることを確認する。新しいクラスタを作成するには、Autopilot クラスタの作成をご覧ください。

GKE Gateway コントローラの要件

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 に接続できる GCPBackendPolicy は常に 1 つのみです。2 つの GCPBackendPolicy ポリシーが作成され、同じ 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:
    # Enable global access for the regional internal Application Load Balancer.
    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 クラスタで使用可能な機能について説明します。

デフォルトでは、HTTP または kubernetes.io/h2c のアプリケーションプロトコルを使用するバックエンドサービスの場合、HealthCheck は HTTP タイプです。HTTPS プロトコルの場合、デフォルトの HealthCheck は HTTPS タイプです。HTTP2 プロトコルの場合、デフォルトの HealthCheck は HTTP2 タイプです。

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

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

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

サービス

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

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

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

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

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

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

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

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

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  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:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  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 OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  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 GCPBackendPolicy "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:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  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
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

`GCPBackendPolicy` を使用してバックエンドの選択を構成する

GCPBackendPolicy 内の CUSTOM_METRICS バランシングモードを使用すると、ロードバランサのバックエンドサービスがトラフィックを分散する方法に影響する特定のカスタム指標を構成できます。このバランシングモードでは、定義したカスタム指標に基づいてロードバランシングを行うことができます。この指標は、アプリケーションバックエンドによって報告されます。

詳細については、カスタム指標ベースのロードバランシングによるトラフィック管理をご覧ください。

backends[] フィールドの customMetrics[] 配列には、次のフィールドが含まれます。

name: カスタム指標のユーザー定義名を指定します。
maxUtilization: この指標の目標使用率または最大使用率を設定します。有効な範囲は [0, 100] です。
dryRun: ブール値フィールドです。true の場合、指標データは Cloud Monitoring に報告されますが、ロードバランシングの決定には影響しません。

例

次の例は、バックエンドの選択とエンドポイントレベルのルーティング用にカスタム指標を構成する GCPBackendPolicy マニフェストを示しています。

次のマニフェストを my-backend-policy.yaml として保存します。

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  # Attach to the super-service Service.
  targetRef:
    kind: Service
    name: super-service
  default:
    backends:
    # Configuration for all locations.
    - location: "*"
      # Use the rate balancing mode for the load balancer.
      balancingMode: RATE
      # Maximum number of requests per second for each endpoint.
      maxRatePerEndpoint: 9000
    # Configuration for us-central1-a
    - location: us-central1-a
      # maxRatePerEndpoint: 9000 inherited from the * configuration.
      # Use the custom metrics balancing mode for the load balancer.
      balancingMode: CUSTOM_METRICS
      # Configure the custom metrics for the load balancer to use.
      customMetrics:
      - name: gpu-load
        maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [0.0, 1.0]
        dryRun: false

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

ロードバランサは、RATE バランシングモードとカスタム gpu-load 指標に基づいてトラフィックを分散します。

GCPTrafficDistributionPolicy を使用してエンドポイントレベルのルーティングを構成する

GCPTrafficDistributionPolicy は、バックエンド内のエンドポイント選択のロードバランシングアルゴリズムを構成します。WEIGHTED_ROUND_ROBIN を選択すると、ロードバランサは報告された指標（カスタム指標を含む）から導出された重みを使用して、個々のインスタンスまたはエンドポイントにトラフィックを分散します。

GCPTrafficDistributionPolicy リソースの WEIGHTED_ROUND_ROBIN localityLbPolicy フィールドは、バックエンド内の個々のインスタンスまたはエンドポイントを選択するためのロードバランシングアルゴリズムを指定します。このアルゴリズムを使用すると、カスタム指標を使用して負荷割り当ての重みが計算されます。

GCPTrafficDistributionPolicy 構成内の customMetrics[] 配列には、次のフィールドが含まれます。

name: カスタム指標のユーザー定義名を指定します。
dryRun: ブール値フィールドです。true の場合、指標データは Cloud Monitoring に報告されますが、ロードバランシングには影響しません。

詳細については、カスタム指標ベースのロードバランシングによるトラフィック管理をご覧ください。

例

次の例は、WEIGHTED_ROUND_ROBIN ロードバランシングアルゴリズムとカスタム指標の両方を使用してエンドポイントレベルのルーティングを構成する GCPTrafficDistributionPolicy マニフェストを示しています。

次のサンプルマニフェストを GCPTrafficDistributionPolicy.yaml として保存します。

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: echoserver-v2
  namespace: team1
spec:
  targetRefs:
  # Attach to the echoserver-v2 Service in the cluster.
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    # Use custom metrics to distribute traffic across endpoints.
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    # Configure metrics from an ORCA load report to use for traffic
    # distribution.
    customMetrics:
    - name: orca.named_metrics.bescm11
      dryRun: false
    - name: orca.named_metrics.bescm12
      dryRun: true

マニフェストをクラスタに適用します。

kubectl apply -f GCPTrafficDistributionPolicy.yaml

ロードバランサは、WEIGHTED_ROUND_ROBIN アルゴリズムと指定されたカスタム指標を使用して、エンドポイントにトラフィックを分散します。

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

このセクションでは、バージョン 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:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    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:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    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:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  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:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  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 に設定する

アクセスロギングのサンプルレートとオプションフィールドのリスト（tls.cipher や orca_load_report など）を構成することもできます。

オプションフィールドのロギングを有効にするには:

logging.OptionalMode を CUSTOM に設定します。
logging.optionalFields に、ログに記録するオプションフィールドのリストを指定します。サポートされているフィールドの一覧については、ロギングとモニタリングをご覧ください。

オプションフィールドのロギングを無効にするには、次の 2 つの方法があります。

logging.optionalFields からすべてのエントリを削除する。
logging.OptionalMode を EXCLUDE_ALL_OPTIONAL に設定する。

次の GCPBackendPolicy マニフェストでは、アクセスロギングのデフォルトのサンプルレートが変更され、HTTP リクエストの 50% に設定されます。このマニフェストでは、特定の Service リソースの 2 つのオプションフィールドのロギングも有効にします。

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  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:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  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 に設定します。
optionalMode: CUSTOM: ログエントリに optionalFields のセットを含める必要があることを指定します。
optionalFields: tls.cipher, orca_load_report.cpu_utilization: ログエントリに、TLS handshake に使用された暗号の名前と CPU 使用率が使用可能であれば、その両方を含めるように指定します。

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

GKE クラスタがバージョン 1.31.1-gke.2008000 以降を実行していることを確認します。

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

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

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

症状:

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

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

理由:

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

回避策:

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

次のステップ

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

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

始める前に

GKE Gateway コントローラの要件

制限事項

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

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

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

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

サービス

マルチクラスタ サービス

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

サービス

マルチクラスタ サービス

IAP を構成する

サービス

マルチクラスタ サービス

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

サービス

マルチクラスタ サービス

GCPBackendPolicy を使用してバックエンドの選択を構成する

GCPTrafficDistributionPolicy を使用してエンドポイント レベルのルーティングを構成する

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

サービス

マルチクラスタ サービス

サービス

マルチクラスタ サービス

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

サービス

マルチクラスタ サービス

HTTP アクセス ロギング

Service

マルチクラスタ サービス

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

トラブルシューティング

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

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

次のステップ

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

マルチクラスタサービス

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

マルチクラスタサービス

マルチクラスタサービス

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

マルチクラスタサービス

`GCPBackendPolicy` を使用してバックエンドの選択を構成する

GCPTrafficDistributionPolicy を使用してエンドポイントレベルのルーティングを構成する

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

マルチクラスタサービス

マルチクラスタサービス

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

マルチクラスタサービス

HTTP アクセスロギング

マルチクラスタサービス

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

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

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