このページでは、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
を実行して最新のバージョンを取得する。
- 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 のみです。
- パススルーまたはプロキシ ネットワーク ロードバランサはサポートされていません。
- 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 クラスタが以下の要件を満たしていることを確認してください。
アプリケーションをデプロイする: Deployment リソースを使用して Kubernetes アプリケーションをデプロイします。詳細については、アプリケーションを GKE クラスタにデプロイするをご覧ください。
たとえば、一般的なデプロイメント マニフェストには、次のような 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
Service を使用してアプリケーションを公開する: Kubernetes Service を使用してアプリケーションを公開する必要があります。Service の仕組みとその構成方法の詳細については、Kubernetes Service についてをご覧ください。
Gateway API ベースのアプリケーション ロードバランサを使用する: Gateway API を介して構成された GKE マネージド アプリケーション ロードバランサを使用して Service を公開します。詳細については、Gateway のデプロイをご覧ください。
CPU ベースのロード バランシング用の GCPBackendPolicy
を作成する
GKE はこの構成を使用して、各バックエンド Pod のリアルタイムの CPU 使用率に基づいてトラフィックを動的に分散します。
GKE Service の使用率ベースのロード バランシングを有効にするには、Kubernetes Gateway API の GCPBackendPolicy
カスタム リソースを使用します。
GCPBackendPolicy
カスタム リソースでは、Kubernetes クラスタ内のロード バランシングの動作を宣言的に定義できます。CPU 使用率指標を指定することで、現在のリソース使用状況に基づいてバックエンド間でトラフィックをどのように分散するかを制御できます。このアプローチにより、個々の Pod の過負荷を防ぎながらアプリケーションのパフォーマンスを維持することができ、アプリケーションの信頼性とユーザー エクスペリエンスが向上します。
次のサンプル マニフェストを
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% を超えると、トラフィックが再バランシングされます。マニフェストをクラスタに適用します。
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
に切り替える前に新しいカスタム指標をテストする場合に便利です。
- ロード バランシングがカスタム指標以外の条件(1 秒あたりのリクエスト数の
Monitoring カスタム指標
GCPBackendPolicy
を構成してアプリケーションへのトラフィックの送信を開始した後、gke.cpu
などのカスタム指標が Metrics Explorer に表示されるまでには、少し時間がかかります。- カスタム指標が Metrics Explorer に表示されてアクティブになるには、ポリシーのモニタリング対象であるバックエンドがトラフィックを実際に処理している必要があります。そのようなトラフィックがない場合、指標は Metrics Explorer の [無効なリソース] にのみ表示されることがあります。
CPU 使用率のカスタムしきい値を設定する
デフォルトでは、バックエンドの CPU 使用率が 80% を超えると、そのバックエンドへのトラフィックの分配が抑制されます。ただし、ワークロードによっては、トラフィックの再分配が必要となる CPU 使用率がもっと高い、または低い場合があります。このしきい値は、GCPBackendPolicy
リソースの maxUtilizationPercent
フィールドを使用してカスタマイズできます。
バックエンドの 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
に設定する必要があります。
マニフェストをクラスタに適用します。
kubectl apply -f my-backend-policy.yaml
CPU 使用率のカスタムしきい値を有効にすると、バックエンドの CPU 使用率に基づいてトラフィック分配を制御できます。
(省略可)ドライラン モードを有効にする
ドライラン モードでは、トラフィック分配を変更せずに Pod のリソース使用率をモニタリングします。ドライラン モードが有効になっている場合、指標は Cloud Monitoring にエクスポートされますが、Cloud Load Balancing はこれらの指標を無視し、デフォルトのロード バランシング動作を使用します。
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
マニフェストをクラスタに適用します。
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 レベルで使用率ベースのロード バランシングを有効にする必要があります。
既存の 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
。
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 の使用率ベースのロード バランシングを無効にするには、次の操作を行います。
- ポリシーの他の設定を保持する場合は、
GCPBackendPolicy
からbalancingMode
フィールドとcustomMetrics
フィールドを削除します。 GCPBackendPolicy
が不要になった場合は、ポリシー自体を削除できます。- Compute Engine API を使用する場合は、バックエンド サービスの
--balancing-mode
フラグと--custom-metrics
フラグを元に戻します。