GKE Service の使用率ベースのロード バランシングを構成する

Autopilot Standard

プレビュー版

この機能は サービス固有の規約の対象となります。 一般提供前の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

このページでは、GKE Service の使用率ベースのロード バランシングを構成する方法について説明します。このページは、GKE Service のトラフィック分散の構成や管理を担当しているインフラストラクチャ チーム、アプリケーション チーム、GKE 管理者を対象としています。

使用率ベースのロードバランサを使用すると、GKE Pod のリアルタイムのリソース使用状況に基づいてトラフィックをインテリジェントに分散することができ、アプリケーションのパフォーマンスと可用性が最適化されます。

このページを読む前に、GKE Service の使用率ベースのロード バランシングと、使用率ベースのロード バランシングの仕組みを理解しておいてください。

料金

使用率ベースのロード バランシングは、追加料金なしで使用できる GKE Gateway の機能です。Cloud Load Balancing と GKE の料金は引き続き適用されます。

割り当て

使用率ベースのロード バランシングによって新しい割り当ては導入されませんが、Cloud Load Balancing とその他の依存サービスの割り当ては引き続きすべて適用されます。

始める前に

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

• 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 など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

• Gateway コントローラの要件を確認します。
• 制限事項を確認します。

GKE Gateway コントローラの要件

GKE Service の使用率ベースのロード バランシングを使用するには、以下が必要です。

• Google Cloud CLI バージョン 516.0.0 以降。
• RAPID チャンネルから提供される GKE バージョン 1.33.1-gke.1918000 以降。
• クラスタで Gateway API が有効になっている必要があります。
• クラスタでパフォーマンス HPA プロファイルが有効になっている必要があります。
• Google Cloud プロジェクトで Autoscaling API を有効にする必要があります。
• ノード サービス アカウントに Autoscaling API への書き込み許可が与えられている必要があります。

GKE Service の使用率ベースのロード バランシングでは、以下がサポートされています。

• Google Cloudマネージド ロードバランサのバックエンドとして機能する単一クラスタおよびマルチクラスタの GKE Service。
• すべての GKE エディション（Standard、Autopilot、Enterprise）。
• 従来のアプリケーション ロードバランサを除くすべての Google Cloud アプリケーション ロードバランサ。

制限事項

GKE Service の使用率ベースのロード バランシングには、以下の制限事項があります。

• サポートされているリソース使用率の指標は次のとおりです。
  • CPU リソース使用率の指標。
  • GKE アプリケーションによって出力されたカスタム指標。詳細については、ロードバランサのカスタム指標を公開するをご覧ください。
• パススルーまたはプロキシ ネットワーク ロードバランサはサポートされていません。
• Gateway API のみがサポートされています。Service API と Ingress API はサポートされていません。
• トラフィックが急増する環境では、使用率ベースのロード バランシングはうまく機能しません。Pod が最大使用率に達すると、トラフィックの再バランシングに最大 30 秒かかります。使用率シグナルは受信トラフィックとともに上昇すると予想されますが、この遅延が原因で、使用率ベースのロード バランシングには調整時間が必要になります。パフォーマンスの最適化という点では、使用率ベースのロード バランシングは、トラフィック フローがスムーズで予測可能である環境において最もうまく機能します。
• デュアルスタック クラスタ（1 つの IPv4 アドレスと 1 つの IPv6 アドレスを持つクラスタ）はサポートされていません。
• GCPBackendPolicy の dryRun フィールドの変更や削除などの構成変更を行った後、トラフィック分配の更新と調整に最大 30 秒かかることがあります。この遅延は、システム全体にわたる既知の挙動です。そのため、この機能は、この更新レイテンシを許容できる比較的安定したトラフィック パターンを持つアプリケーションに最も適しています。

デフォルトでは、GKE Service の使用率ベースのロード バランシングは無効になっています。これは明示的に有効にする必要があります。最大使用率のしきい値を設定しない場合は、デフォルトでエンドポイントあたり 80% の使用率が使用されます。

使用率ベースのロード バランシングを構成する目的は、トラフィック分配を最適化して、バックエンド Pod のワークロードを効率的に管理できるようにすることです。これにより、アプリケーションのパフォーマンスとリソース使用率が向上します。

使用率ベースのロード バランシングとパフォーマンス HPA プロファイルを有効にする

使用率ベースのロード バランシングを構成する前に、GKE クラスタが必要な機能をサポートしていることを確認してください。使用率ベースのロード バランシングは、CPU などのカスタム指標を使用してルーティングをよりスマートに決定します。これらの決定は以下を基盤とします。

• Gateway API。GCPBackendPolicy を通じてサービスレベルのポリシーを許可します。
• パフォーマンス HPA プロファイル。これにより、CPU シグナルを使用してワークロードをより迅速かつ積極的にスケーリングできます。

Gateway API とパフォーマンス HPA プロファイルを有効にする

Autopilot

Autopilot クラスタでは、Gateway API とパフォーマンス HPA プロファイルはデフォルトで使用可能になっています。

Standard

パフォーマンス HPA プロファイルと Gateway API が有効な新しい Standard クラスタを作成するには、次のコマンドを実行します。

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

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

• CLUSTER_NAME: 新しいクラスタの名前。
• LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。
• PROJECT_ID: プロジェクト ID。
• CLUSTER_VERSION: GKE バージョン。1.33.1-gke.1918000 以降にする必要があります。

既存の GKE Standard クラスタでパフォーマンス HPA プロファイルと Gateway API を有効にするには、次のコマンドを使用します。

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

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

• CLUSTER_NAME: 新しいクラスタの名前。
• LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。
• PROJECT_ID: プロジェクト ID。

パフォーマンス HPA プロファイルの詳細については、パフォーマンス HPA プロファイルを構成するをご覧ください。

使用率ベースのロード バランシングを構成する

クラスタの準備ができたら、バックエンドの使用率に基づいてトラフィックをどのようにルーティングするかを指示するポリシーを定義します。これを構成するには、GCPBackendPolicy を通じて Kubernetes Gateway API を使用する必要があります。

前提条件

Gateway API を使用した使用率ベースのロード バランシングを構成する前に、GKE クラスタが以下の要件を満たしていることを確認してください。

1. アプリケーションをデプロイする: Deployment リソースを使用して Kubernetes アプリケーションをデプロイします。詳細については、アプリケーションを GKE クラスタにデプロイするをご覧ください。

   注: 使用率ベースのロード バランシングが正しく機能するには、Deployment のコンテナ仕様において、特に CPU のリソース requests を定義する必要があります。これにより、ベースラインのリソース使用率が正確に決定され、トラフィックの再バランシングが効果的に行われます。requests が定義されていないと、ロード バランシング メカニズムが想定どおりに動作しない可能性があります。

   たとえば、一般的なデプロイメント マニフェストには、次のような resources セクションが含まれます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     # ... other deployment configurations ...
     template:
       # ... other template configurations ...
       spec:
         containers:
           - name: your-container-name
             image: your-image
             ports:
               - containerPort: 8080
             resources:
               limits:
                 cpu: 100m
                 memory: 45Mi
               requests:
                 cpu: 100m
                 memory: 45Mi
   

2. Service を使用してアプリケーションを公開する: Kubernetes Service を使用してアプリケーションを公開する必要があります。Service の仕組みとその構成方法の詳細については、Kubernetes Service についてをご覧ください。

3. Gateway API ベースのアプリケーション ロードバランサを使用する: Gateway API を介して構成された GKE マネージド アプリケーション ロードバランサを使用して Service を公開します。詳細については、Gateway のデプロイをご覧ください。

CPU ベースのロード バランシング用の GCPBackendPolicy を作成する

GKE はこの構成を使用して、各バックエンド Pod のリアルタイムの CPU 使用率に基づいてトラフィックを動的に分散します。

GKE Service の使用率ベースのロード バランシングを有効にするには、Kubernetes Gateway API の GCPBackendPolicy カスタム リソースを使用します。

GCPBackendPolicy カスタム リソースでは、Kubernetes クラスタ内のロード バランシングの動作を宣言的に定義できます。CPU 使用率指標を指定することで、現在のリソース使用状況に基づいてバックエンド間でトラフィックをどのように分散するかを制御できます。このアプローチにより、個々の Pod の過負荷を防ぎながらアプリケーションのパフォーマンスを維持することができ、アプリケーションの信頼性とユーザー エクスペリエンスが向上します。

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

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     targetRef:
       group: ""
       kind: Service
       name: super-service
     default:
       balancingMode: CUSTOM_METRICS
       customMetrics:
       - name: gke.cpu
         dryRun: false
   

   次の点にご注意ください。

   • spec.targetRef.kind: Service: 同じクラスタ内の標準の Kubernetes Service をターゲットにします。
   • spec.targetRef.kind: ServiceImport: マルチクラスタ環境において別のクラスタの Service をターゲットにします。
   • balancingMode: CUSTOM_METRICS: カスタム指標ベースのロード バランシングを有効にします。
   • name: gke.cpu: トラフィック分配の指標として CPU 使用率を指定します。

   maxUtilizationPercent フィールドが指定されていない場合、デフォルトの使用率しきい値は 80% です。バックエンドの CPU 使用率が 80% を超えると、トラフィックが再バランシングされます。

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

   kubectl apply -f my-backend-policy.yaml
   

トラフィック分配をリアルタイムの CPU 使用率に基づいて行うことで、パフォーマンスを自動的に最適化できます。このアクションは、個々の Pod の過負荷の防止に役立ちます。

dryRun と balancingMode に関する重要な考慮事項

カスタム指標を使用して GCPBackendPolicy を構成する場合は、balancingMode と customMetrics 定義の dryRun フィールドとの相互作用を考慮してください。この相互作用により、ロードバランサがカスタム指標をどのように使用するかが決まります。カスタム指標とその制限（バランシング モードに関連するものを含む）の詳細については、Cloud Load Balancing のカスタム指標をご覧ください。

• balancingMode: CUSTOM_METRICS

  • カスタム指標に基づいてトラフィックを分散するには、customMetrics リスト内の少なくとも 1 つのカスタム指標で dryRun が false に設定されている必要があります。これにより、その指標が実際に再バランシングの決定に使用されます。
  • ドライランが false の指標とともに、dryRun: true のカスタム指標を含めることができます。これにより、dryRun: false に設定された別の指標（CPU 使用率など）でバランシングを制御しながら、トラフィックに影響を与えることなく GPU 使用率などの新しい指標をテストまたはモニタリングできます。
  • balancingMode が CUSTOM_METRICS で、すべてのカスタム指標の dryRun が true に設定されている場合は、エラーが発生します。たとえば、gceSync: generic::invalid_argument: Update: Invalid value for field 'resource.backends[0]': '...'. CUSTOM_METRICS BalancingMode requires at least one non-dry-run custom metric. のようなエラーが発生します。ロードバランサには、ルーティングを決定するためのアクティブな指標が必要です。

• balancingMode が RATE、つまりカスタム指標以外のモードである

  • ロード バランシングがカスタム指標以外の条件（1 秒あたりのリクエスト数の RATE など）に基づいている場合は、すべてのカスタム指標に dryRun: true を設定できます。これにより、メインのバランシング メカニズムに影響を与えることなく、カスタム指標をモニタリングできます。これは、balancingMode を CUSTOM_METRICS に切り替える前に新しいカスタム指標をテストする場合に便利です。

• Monitoring カスタム指標

  • GCPBackendPolicy を構成してアプリケーションへのトラフィックの送信を開始した後、gke.cpu などのカスタム指標が Metrics Explorer に表示されるまでには、少し時間がかかります。
  • カスタム指標が Metrics Explorer に表示されてアクティブになるには、ポリシーのモニタリング対象であるバックエンドがトラフィックを実際に処理している必要があります。そのようなトラフィックがない場合、指標は Metrics Explorer の [無効なリソース] にのみ表示されることがあります。

CPU 使用率のカスタムしきい値を設定する

デフォルトでは、バックエンドの CPU 使用率が 80% を超えると、そのバックエンドへのトラフィックの分配が抑制されます。ただし、ワークロードによっては、トラフィックの再分配が必要となる CPU 使用率がもっと高い、または低い場合があります。このしきい値は、GCPBackendPolicy リソースの maxUtilizationPercent フィールドを使用してカスタマイズできます。

1. バックエンドの CPU 使用率が 70% に達すると再バランシングがトリガーされるように GKE Service を構成するには、次のサンプル マニフェストを my-backend-policy.yaml として保存します。

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     targetRef:
       group: ""
       kind: Service
       name: super-service
     default:
       balancingMode: CUSTOM_METRICS
       customMetrics:
       - name: gke.cpu
         maxUtilizationPercent: 70
   

   次の点にご注意ください。

   • maxUtilizationPercent フィールドに設定可能な値は 0～100 です。値が 100 の場合は、バックエンドの CPU 処理能力を使い切るまでトラフィックは再バランシングされないことを意味します。
   • レイテンシの影響を受けやすく、早期のオフロードが必要なワークロードの場合は、しきい値を小さくします。
   • CPU 処理能力いっぱい近くまで実行できるよう設計されたワークロードの場合は、しきい値を大きくします。
   • マルチクラスタ サービスの場合は、spec.targetRef.kind を ServiceImport に、group を net.gke.io に設定する必要があります。

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

   kubectl apply -f my-backend-policy.yaml
   

CPU 使用率のカスタムしきい値を有効にすると、バックエンドの CPU 使用率に基づいてトラフィック分配を制御できます。

（省略可）ドライラン モードを有効にする

ドライラン モードでは、トラフィック分配を変更せずに Pod のリソース使用率をモニタリングします。ドライラン モードが有効になっている場合、指標は Cloud Monitoring にエクスポートされますが、Cloud Load Balancing はこれらの指標を無視し、デフォルトのロード バランシング動作を使用します。

1. GKE Service のドライラン モードを有効にするには、次のサンプル マニフェストを my-backend-policy.yaml として保存します。

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
   spec:
     targetRef:
       group: ""
       kind: Service
       name: store-v1
     default:
       balancingMode: RATE
       maxRatePerEndpoint: 10
       customMetrics:
       - name: gke.cpu
         dryRun: true
   

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

   kubectl apply -f my-backend-policy.yaml
   

ドライラン モードを有効にすると、次のようになります。

• CPU 使用率指標は無視され、代わりにデフォルトのロード バランシング動作が使用されます。

• Cloud Monitoring への指標のエクスポートは、network.googleapis.com/loadbalancer/backend/lb_custom_metrics の下で続行されます。

指標を評価した後、GCPBackendPolicy から dryRun フィールドを削除して構成を再適用します。ドライランを無効にした後に問題が発生した場合は、ポリシーに dryRun: true を再び追加することで、ドライランを再度有効にします。

ポリシーを確認する

GCPBackendPolicy が GKE Service に適用されていること、および GKE コントローラがポリシーを認識していることを確認するには、次のコマンドを実行します。

kubectl describe gcpbackendpolicy POLICY_NAME -n NAMESPACE

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

Name:         <your policy name>
Namespace:    <your namespace>
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  ...
  Generation:          1
  Resource Version:    …
  UID:                 …
Spec:
  Default:
    Balancing Mode:  CUSTOM_METRICS
    Custom Metrics:
      Dry Run:  false
      Name:     gke.cpu
  Target Ref:
    Group:
    Kind:   Service
    Name:   super-service
Status:
  Conditions:
    Last Transition Time:  …
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
…

Compute Engine API を使用して使用率ベースのロード バランシングを構成する

GKE Service の使用率ベースのロード バランシングは、Kubernetes Gateway API を使用して構成することをおすすめします。

ただし、Compute Engine API または Terraform を使用してロードバランサを直接管理することもできます。このアプローチを選択する場合は、BackendService レベルで使用率ベースのロード バランシングを有効にする必要があります。

1. 既存の BackendService の場合は、次のコマンドを実行することで、使用率ベースのロード バランシングを有効にし、ネットワーク エンドポイント グループ（NEG）my-lb-neg を関連付けます。

   gcloud compute backend-services add-backend MY_BACKEND_SERVICE \
     --network-endpoint-group my-lb-neg \
     --network-endpoint-group-zone=asia-southeast1-a \
     --global \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
   

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

   • MY_BACKEND_SERVICE: BackendService の名前。
   • CUSTOM_METRICS: CUSTOM_METRICS。

2. NEG がすでに接続されている BackendService の既存のバックエンド エントリについて、使用率ベースのロード バランシング設定を更新するには、次のコマンドを実行します。

   gcloud compute backend-services update-backend MY_BACKEND_SERVICE \
     --network-endpoint-group my-lb-neg \
     --network-endpoint-group-zone=asia-southeast1-a \
     --global \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
   

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

   • MY_BACKEND_SERVICE: BackendService の名前。
   • CUSTOM_METRICS: CUSTOM_METRICS。

注: カスタム指標を使用する場合は、構成するディメンションの数をサービスの上限以下にしてください。上限を超えると、ディメンションを追加できなくなります。

GKE Service の使用率ベースのロード バランシングを無効にする

GKE Service の使用率ベースのロード バランシングを無効にするには、次の操作を行います。

1. ポリシーの他の設定を保持する場合は、GCPBackendPolicy から balancingMode フィールドと customMetrics フィールドを削除します。
2. GCPBackendPolicy が不要になった場合は、ポリシー自体を削除できます。
3. Compute Engine API を使用する場合は、バックエンド サービスの --balancing-mode フラグと --custom-metrics フラグを元に戻します。

次のステップ

• ロード バランシングにカスタム指標を使用するには、ロードバランサのカスタム指標を公開するをご覧ください。
• ゾーン ネットワーク エンドポイント グループの概要をご覧ください。