mcpField
G
gke-workload-scaling

gke-workload-scaling

github.com/googleクラウド・DevOps21.6k5.3k 回インストール今日更新
リポジトリ

gke-workload-scaling について

Google Kubernetes Engine のワークロードをスケーリングするスキルです。クラスター運用者向けに、手動のレプリカ変更、HPA、VPA の手順と、メトリクスやリソース調整、可用性の指針を説明します。

主な機能

  1. 01Deployment レプリカの手動スケーリング
  2. 02利用率・メトリクスに基づく HPA 設定
  3. 03VPA のモードと設定
  4. 04リソースリクエストと調整の指針
  5. 05スケーリング時の可用性に関する指針

活用シーン

  1. 01テストや手動対応でのレプリカ数調整
  2. 02CPU・メモリ使用量に基づく Pod の自動スケーリング
  3. 03VPA の推奨値による Pod リソースの適正化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/google/skills --skill gke-workload-scaling

インストール後、Claude Code で/gke-workload-scalingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
hpa-example.yaml
vpa-example.yaml
references/
attribution.md

詳細

GKE ワークロードのスケーリング

このスキルでは、Google Kubernetes Engine（GKE）上のアプリケーションをスケーリングするためのワークフローとベストプラクティスを紹介します。手動スケーリング、Horizontal Pod Autoscaling（HPA）、Vertical Pod Autoscaling（VPA）について説明します。

クレジット表記

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、必ず使用状況のクレジット表記をお読みください。ターミナルでコマンドを直接実行する場合（生成されたスクリプト、Terraform、ユーザーコード内での実行は不可）、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-workload-scaling)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:gke-workload-scaling) を追加してください。

ワークフロー

1. 手動スケーリング

デプロイメントを固定数のレプリカにスケーリングします。すぐに手動で対処したい場合や、テストに役立ちます。

コマンド：

kubectl scale deployment {deployment_name} --replicas={number} -n {namespace}

# Verify the scale event
kubectl get deployment {deployment_name} -n {namespace}
2. Horizontal Pod Autoscaling（HPA）

観測された CPU 使用率、メモリ使用率、またはカスタムメトリクスに基づいて、Pod の数を自動的にスケーリングします。

前提条件：

  • Metrics Server が実行されている必要があります（GKE ではデフォルトで有効です）。
  • コンテナでリソースのリクエストと上限が明確に定義されている必要があります。

クイックコマンド：

kubectl autoscale deployment {deployment_name} --cpu-percent=50 --min=1 --max=10

マニフェストを使用する方法（推奨）： バージョン管理された設定には YAML マニフェストを使用します。テンプレートについては、assets/hpa-example.yaml を参照してください。

kubectl apply -f assets/hpa-example.yaml

# Verify HPA is created and fetching metrics
kubectl get hpa

カスタムメトリクスと外部メトリクス： GKE では、Cloud Monitoring のメトリクス（Pub/Sub キューの長さなど）に基づくスケーリングに、GKE コントロールプレーンでネイティブにサポートされ、Custom Metrics Adapter を必要としない External メトリクスタイプを使用する方法が、最新かつ推奨されるアプローチです。Prometheus を介して公開されるアプリケーション固有のメトリクスには、Google Cloud Managed Service for Prometheus または Prometheus Adapter を使用できます。

3. Vertical Pod Autoscaling（VPA）

実際の使用状況に合わせて、Pod の CPU とメモリの予約量を自動的に調整します。ワークロードの適正なリソース割り当てに不可欠です。

前提条件：

  • クラスターで VPA が有効になっている必要があります。
    • Autopilot： デフォルトで有効です。
    • Standard： 手動で有効にする必要があります。

Standard クラスターで VPA を有効にする：

gcloud container clusters update {cluster_name} --enable-vertical-pod-autoscaling --zone {zone}

更新モード：

  • Off：推奨値を計算しますが、適用はしません。「ドライラン」分析に適しています。
  • Initial：Pod の作成時にのみリソースを割り当てます。
  • Auto：推奨値とリクエストの差が大きい場合、実行中の Pod を再起動して更新します。
  • InPlaceOrRecreate：Pod を再作成せずに Pod リソースを更新しようとします。インプレース更新ができない場合は、Auto モードに戻ります（GKE 1.34 以降が必要です）。

例： 設定テンプレートについては、assets/vpa-example.yaml を参照してください。

ベストプラクティス

  1. リソースリクエストを定義する： HPA と VPA は正確なリソースリクエストを前提とします。コンテナの仕様には必ずリソースリクエストを定義してください。
  2. メトリクスの競合を避ける： HPA と VPA が同じメトリクス（例：CPU）の使用を設定しないでください。挙動が不安定になります。
    • 一般的なパターン： CPU には HPA、メモリには VPA を使用します。
  3. Pod Disruption Budget（PDB）： スケーリング時やノードのアップグレード時にアプリケーションの可用性を確保できるよう、PDB を定義します。
  4. HPA の遅延： HPA には、急激な変動を防ぐための安定化ウィンドウがあります（デフォルトは 5 分です）。
  5. VPA の「Auto」モードのリスク： 「Auto」モードでは、VPA はリソースを変更するために Pod を再起動します。アプリケーションが再起動に適切に対応できること（例：SIGTERM を処理できること）を確認してください。
    • 注： デフォルトでは、実行中の唯一のレプリカが退避されてダウンタイムが発生するのを防ぐため、VPA が退避を実行するには少なくとも 2 つのレプリカが必要です。GKE 1.22 以降では、PodUpdatePolicy に minReplicas を設定して、この制限を上書きできます。

リソース適正化のワークフロー

  1. VPA を Off モードで 24 時間以上デプロイします
  2. 推奨値を確認します：kubectl describe vpa {deployment_name}-vpa -n {namespace}
  3. target の値を現在の requests と比較します
  4. 20% のバッファーを適用します：new_request = target * 1.2
  5. パッチ形式を使用するか、デプロイメントマニフェストを更新して新しいリソース リクエストを適用します
条件推奨事項リスク
CPU リクエストが実際の P95 の 5 倍を超えるP95 * 1.2 に削減中
メモリーリクエストが実際の P95 の 3 倍を超えるP95 * 1.2 に削減中
CPU リクエストが実際の P95 の 2 倍を超える20% のバッファーを確保してリソースを適正化低
リソース制限が設定されていないノイジーネイバーを防ぐため制限を追加低

コメント

Markdown 対応