gke-cost-optimization

GKE のコスト最適化

このリファレンスでは、安全で信頼性の高い状態を維持しながら Google Kubernetes Engine（GKE）のコストを削減するための戦略とワークフローについて説明します。

帰属情報

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

ワークフローと最適化戦略

1. 前提条件：コスト配分とモニタリング

ネームスペースやラベルごとの課金追跡のために GKE のコスト配分（--enable-cost-allocation）を有効にする場合、稼働中のクラスター使用率を調査する場合（kubectl top）、または BigQuery（bq）で過去のコスト内訳クエリを実行する場合は、gke-cost-analysis スキルを使用してください。追跡を有効にして無駄を特定したら、以下の最適化ワークフローを適用します。

2. リソースクォータの設定

リソースクォータは、マルチテナントクラスター内のテナント全体のリソース消費量を制限し、コストの際限ない増加を防ぎます。テンプレート： assets/resource-quota-example.yaml （ネームスペースと hard の上限を設定してから、kubectl apply -f を実行します）。

3. Pod の適正サイズ化（VPA と MPA）

実際の使用率に合わせて Pod のリソースリクエストを調整します。過剰にプロビジョニングされたリクエストは、無駄が発生する最大の要因のひとつです。

• 推奨モードで VPA を使用する（updateMode: "Off" — Pod を退避させずに推奨値を提示します）：

# 1. Deploy VPA in recommendation mode (template: assets/vpa-recommendation-mode.yaml)
kubectl apply -f assets/vpa-recommendation-mode.yaml
# 2. Wait 24+ hours for data collection, then read recommendations
kubectl get vpa {deployment_name}-vpa -o jsonpath='{.status.recommendation}'

• 最適化ルール：

条件	対応	削減効果
CPU リクエストが実測 P95 の 5 倍超	P95 * 1.2 に削減	高
メモリリクエストが実測 P95 の 3 倍超	P95 * 1.2 に削減	高
CPU リクエストが実測 P95 の 2 倍超	P95 * 1.2 に削減	中
リソースリクエストが未設定	リクエストを追加（ビンパッキングが可能になります）	中

• MPA を使用する：水平方向と垂直方向の両方にスケーリングする際は、HPA と VPA の推奨値を調整し、競合するスケーリングイベントを避けます。
• コストに関する推奨事項を確認する：Google Cloud コンソールの（Cost Management > GKE Cost Optimization）で、組み込みの適正サイズ化の提案を確認します。

4. ComputeClasses と NodeSelector による Spot VM

耐障害性のあるワークロードに Spot VM を使用すると、コストを 60～90% 削減できます。

4.1 ComputeClass の設定

On-Demand へのフォールバックを備えた Spot 優先の ComputeClass（優先順位の設定、 activeMigration、マシンファミリーの選択）には、gke-compute-classes スキルを使用してください。ComputeClass の YAML 生成と優先順位の設定はそのスキルの担当範囲であり、このスキルの担当範囲ではありません。

4.2 ワークロードで Spot を直接選択する（nodeSelector）

GKE Autopilot のステートレスまたはバッチワークロードでは、nodeSelector を使って Spot 容量を直接指定します。

警告

プリエンプションに関する警告：Spot VM は中断可能で、30 秒前の通知をもっていつでも プリエンプトされる可能性があります。ワークロードには耐障害性が必要で、高可用性を確保するために少なくとも 2 つのレプリカで実行する必要があります。Spot VM を推奨する際は、このプリエンプションのリスクについて必ずユーザーに明示的に警告してください。

Pod レベルで指定するセレクターは次のとおりです。

nodeSelector:
  cloud.google.com/gke-spot: "true"

完全な Deployment の例（レプリカ数 >= 2、terminationGracePeriodSeconds: 25、 preStop フック）：assets/spot-deployment-example.yaml。

Spot に適したワークロード：

ワークロード	Spot に適していますか？
バッチ処理／データ処理	はい
開発／テスト環境	はい
ステートレスな Web／API（レプリカ数 >= 2）	はい（PDB が必要）
チェックポイント機能を備えたジョブ	はい
ステートフルなワークロード（データベース）	いいえ
単一レプリカの重要なサービス	いいえ

5. マシンタイプの選択

ノードの形状を選択するときや、ComputeClasses を設定するときは、次の表を参考にしてください。

ファミリー	用途	相対コスト
e2	汎用、バースト可能	最低
t2a / t2d	スケールアウト（Arm/AMD）、価格性能を最適化	低
n4a	Axion ベースの Arm、汎用、価格性能を最適化	低
n4 / n4d	汎用（Intel/AMD）、柔軟な形状	低～中
c4a	Axion ベースの Arm、汎用、高効率	中
c3 / c4	コンピューティング最適化（Intel）	中～高
c3d / c4d	コンピューティング最適化（AMD）、高スループット	中～高
ek-standard	Autopilot の拡張	中
m3 / x4	メモリ最適化、SAP HANA、大規模データベース	高
g2 (L4 GPU)	AI 推論	高
a3 (H100 GPU)	AI トレーニング	最高
a4 / a4x	超大規模 AI（Blackwell GPU）	最高

6. コミット利用割引（CUD）

使用量のベースラインが予測可能で、安定して稼働するワークロードには、1 年または 3 年の CUD を購入します。

• リソースベースの CUD（マシンファミリー／リージョンに対するコミットメント）：1 年で約 30% 台後半、3 年で約 55% の割引（マシンファミリーによって異なります）。
• 柔軟な CUD（支出ベースで、ファミリー／リージョンをまたいで利用可能）：柔軟性と引き換えに、 割引率は低くなります（1 年で約 28%、3 年で約 46%）。
• Autopilot： Autopilot 固有の CUD は 2026 年 1 月に廃止されました。Autopilot の使用量を対象とする新しい コミットメントは、支出ベースの Compute Flexible CUD です （既存の Autopilot CUD コミットメントは契約期間の満了まで継続します）。
• リージョン内の一致する使用量に自動的に適用されます。
• Google Cloud Console > Billing > Committed use discounts から購入します。

コミットメントの規模は、安定稼働時のベースラインだけに合わせてください。 コミットメントは、 使用の有無にかかわらず契約期間全体にわたって課金されるため、ピーク時の使用量に合わせて過剰にコミットすると、 割引が無駄に変わります。代表的な期間における実際の使用量の下限を測定し、その分をコミットして、 それを超える分は、このスキルですでに紹介した伸縮自在なオプションでまかないます。

• ベースライン（常時稼働）→ リソースベースの CUD。
• 変動／バースト性のある使用量 → オンデマンド容量での自動スケーリング。
• 中断に耐えられるワークロード（バッチ、CI、ステートレスワーカー）→ 自動スケーリングと併用でき、コミットメントが不要な Spot VM。

CUD を推奨する場合は、フットプリント全体をコミットすべきだと示唆するのではなく、内訳を明示してください。

7. クラスター管理とマルチテナンシー

• アイドル状態の開発用クラスター：GKE には停止／起動の操作がなく、クラスターが存在する限り管理料金が発生します。アイドル時のコストを削減するには、ノードプールをゼロにスケールする（gcloud container clusters resize {cluster_name} --node-pool {pool_name} --num-nodes 0）か、IaC（Terraform/Config Connector）でクラスターを削除して再作成します。
• ノードプールを適正なサイズにする（Standard）：適切な最小値／最大値を設定して、Cluster Autoscaler を使用します。
• ノードの過剰プロビジョニングではなく、低コストの待機用余力を確保する：スタンバイ容量バッファ（プレビュー、GKE 1.36.0-gke.2253000 以降）では、初期化済みノードが一時停止状態で保持されます。ノード料金全額の代わりにディスクと IP の料金のみが発生し、約 30 秒で再開します。gke-cluster-autoscaler スキルを参照してください。
• マルチテナントの集約：チームごとにクラスターを維持する代わりに、単一のクラスターを複数のエンジニアリングチームで共有し、Namespace と ResourceQuota を使用してワークロードを分離します。

コストと使用率のモニタリング

ノード／Pod のリアルタイムの使用率（kubectl top nodes/pods）の確認、クラスタのコスト予算（gcloud billing budgets list）の表示、または BigQuery での詳細な請求レポートのクエリ（bq query）については、gke-cost-analysis スキルを参照してください。