gke-workload-scaling

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

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

ワークフロー

1. 手動スケーリング

デプロイメントのレプリカ数を指定した数にすばやくスケーリングします。手動での即時対応やテストに役立ちます。

コマンド：

kubectl scale deployment <deployment-name> --replicas=<number> -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

カスタムメトリクスと外部メトリクス： GKE では、Cloud Monitoring のメトリクス（例：Pub/Sub キューの長さ）に基づくスケーリングには、Custom Metrics Adapter を必要とせず、GKE コントロールプレーンでネイティブにサポートされる 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 を参照してください。

4. Cluster Autoscaler

ワークロードレベルのスケーラーではありませんが、Cluster Autoscaler は、スケーリングされた Pod の実行に必要な数のノードをクラスターに確保するために不可欠です。

ノードプールで有効にする：

gcloud container clusters update <cluster-name> \
    --enable-autoscaling \
    --node-pool <node-pool-name> \
    --min-nodes <min> \
    --max-nodes <max> \
    --zone <zone>

ベストプラクティス

1. リソースリクエストを定義する： HPA と VPA は、正確なリソースリクエストに依存します。コンテナの仕様には必ず定義してください。
2. メトリクスの競合を避ける： HPA と VPA に同じメトリクス（例：どちらも CPU）を使用するよう設定しないでください。挙動が不安定になります。
   • 一般的なパターン： HPA は CPU、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 を設定してこの条件を変更できます。