mcpField
K
k8s-hpa-cost-tuning

k8s-hpa-cost-tuning

github.com/microlinkhqクラウド・DevOps449 回インストール今日更新
リポジトリ

k8s-hpa-cost-tuning について

Kubernetes HPA と Cluster Autoscaler を使うチーム向けに、リソースの浪費を監査し、スケーリング事象を分析するスキルです。Datadog のメトリクススクリプトと三層モデルで、レプリカ、スケジューリング、ノード削減のコスト上の障害を調べます。

主な機能

  1. 01クラスターやデプロイ単位の利用率監査
  2. 02インシデント期間のスケーリング分析
  3. 03レプリカ、ノード、リクエスト量の評価
  4. 04段階的な調整案の提示

活用シーン

  1. 01定期監査でリソースの過剰予約を発見
  2. 02本番インシデント後にスケーリングを調査
  3. 03負荷低下時にノードを削除できるか検証

インストール

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

$npx skills add https://github.com/microlinkhq/skills --skill k8s-hpa-cost-tuning

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

同梱ファイルscripts/audit-metrics.mjsscripts/incident-metrics.mjs

詳細

Kubernetes HPA のコストとスケールダウンの調整

モードの選択（必須）

このスキルを実行する前に、モードを宣言してください。すべての推論、しきい値、推奨事項はこの選択に依存します。

mode = audit | incident

モードが指定されていない場合は、実行を拒否し、確認を求めてください。

使用するタイミング

mode = audit — 定期的なコスト削減監査

以下を目的として、定期的（週次または隔週）に実行します。

  • 過剰なリソース予約を早期に検出する
  • スケールダウンとノードの統合が引き続き機能することを確認する
  • クラスターコストを安全に削減できる機会を特定する

このモードでは進行中のインシデントがないことを前提とし、安定性を維持する推奨事項を優先します。

mode = incident — インシデント後のスケーリング分析

本番環境でのインシデントまたは異常の発生後に、以下を添付して実行します。

  • 本番環境のログ
  • HPA イベント
  • スケーリングのタイムライン

このモードでは、以下に重点を置きます。

  • スケーリングがそのように動作した理由を説明する
  • トラフィック起因のインシデントと設定起因のインシデントを区別する
  • 過剰な修正を避けながら再発を防止する

このスキルでは、オブザーバビリティに Datadog を使用し、標準の Kubernetes HPA と Cluster Autoscaler を利用することを前提とします。

基本的な考え方

Kubernetes のスケーリングは、3 層のシステムです。

  1. HPA はポッドの数を決定します（使用量／リクエストに基づく）
  2. Scheduler はポッドの配置先を決定します（リクエストと制約に基づく）
  3. Cluster Autoscaler はノードの数を決定します（ノードを空にできる場合に限る）

コスト最適化が機能するのは、3 つの層すべてが縮小できる場合に限られます。

要点：HPA は数を決定し、scheduler は配置を決定し、autoscaler はコストを決定します。スケールアップは積極的に行えますが、スケールダウンは可能でなければなりません。レプリカ数が減ってもノード数が減らない場合、ボトルネックは scheduler にあります。

Datadog の主要なメトリクス

ユーティリティスクリプトは、次の 3 つのメトリクス群をクエリします。

  • CPU 使用率 % — 実際の使用率（kubernetes.cpu.usage.total / node.cpu_allocatable）
  • CPU リクエスト率 % — 設定上の予約量（kubernetes.cpu.requests / node.cpu_allocatable）
  • 使用メモリとリクエストの比較 — HPA に関係する比率

コスト削減を実現するには、スケールダウン後に CPU リクエスト率 % が低下する必要があります。 メモリ使用量が目標値を上回り続けると、CPU がアイドル状態でもメモリがスケールアップを引き起こします。

主要なコスト管理としてのスケールダウン

スケールダウンが遅い、または阻まれている場合：

  • レプリカ数が頭打ちになります
  • ポッドが均等に分散したままになります
  • ノードが空になりません
  • Cluster Autoscaler がノードを削除できません

結果：恒常的な過剰予約。

推奨する HPA のスケールダウンポリシー
scaleDown:
  stabilizationWindowSeconds: 60
  selectPolicy: Max
  policies:
    - type: Percent
      value: 50
      periodSeconds: 30

効果：負荷低下後の迅速な反応、予測可能なレプリカの集約、フラッピングのリスク低減。

トポロジー分散：重要なコスト調整手段

スケールダウン時のポッドの集約を、トポロジー分散によって妨げてはなりません。

厳格な制約は scheduler の柔軟性を阻み、クラスターサイズを固定してしまいます。

アンチパターン（コスト最適化を妨げる）
maxSkew: 1
whenUnsatisfiable: DoNotSchedule

ポッドをより少ないノードに集約できません。ノードがドレインされません。予約済みの CPU／メモリが減りません。

推奨されるデフォルト（コスト面で安全）
topologySpreadConstraints:
- topologyKey: kubernetes.io/hostname
  maxSkew: 2
  whenUnsatisfiable: ScheduleAnyway

分散を強く優先しつつ、スケールダウン時のビンパッキングを可能にし、ノードの削除を有効にします。

厳格な分離（AZ レベルのみ）

強い保証が必要な場合：

topologySpreadConstraints:
- topologyKey: topology.kubernetes.io/zone
  maxSkew: 1
  whenUnsatisfiable: DoNotSchedule

これをホスト名レベルの厳格な分散と組み合わせないでください。

ソフトな代替策としてのアンチアフィニティ

スケールダウンを妨げずにノードの過負荷を避けるには：

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      topologyKey: kubernetes.io/hostname
      labelSelector:
        matchLabels:
          app: your-app

アンチアフィニティは参考情報として適用され、コスト面でも安全です。

リソースリクエストの調整

  • CPU の過剰なリクエスト = スケールダウンの遅延
  • メモリの過剰なリクエスト = 想定外のスケールアップ

実用的なデフォルト値：

  • targetCPUUtilizationPercentage: 70
  • targetMemoryUtilizationPercentage: 75–80

一度に 1 つの設定項目だけ調整してください。

検証サイクル

週次（または変更後）に実行します。

  1. HPA の current/target 値を確認する
  2. CPU 使用率 % と CPU リクエスト率 % を比較する
  3. 負荷低下後のレプリカの集約を観察する
  4. ノードがドレインされ、削除されることを確認する
  5. レイテンシ、エラー、OOM を再確認する
検証用クイックコマンド
kubectl -n <namespace> get hpa <deployment>
kubectl -n <namespace> describe hpa <deployment>
kubectl -n <namespace> top pod --containers
kubectl top node
kubectl -n <namespace> get pods -o wide | sort -k7

ユーティリティスクリプト

どちらのスクリプトにも Datadog の認証情報が必要です。

export DD_API_KEY=...
export DD_APP_KEY=...
export DD_SITE=datadoghq.com   # optional, defaults to datadoghq.com
audit-metrics.mjs — コスト削減の機会を発見

広い時間枠（デフォルトは24 h）でクラスターをスキャンし、過剰な予約や無駄を見つけます。

# Cluster-wide audit
node scripts/audit-metrics.mjs --cluster <cluster>

# With deployment deep-dive
node scripts/audit-metrics.mjs \
  --cluster <cluster> \
  --namespace <namespace> \
  --deployment <deployment>

レポート内容：

  • クラスター：CPU／メモリの使用率、要求率、無駄率（要求量から使用量を差し引いた割合）
  • デプロイメント（指定した場合）：CPU／メモリの使用量と要求量の比較、HPA のレプリカ数の範囲
  • 削減の機会：しきい値に基づく実行可能な推奨事項
incident-metrics.mjs — インシデント後の分析

インシデント発生時の狭い時間枠でメトリクスを収集し、チューニングの推奨事項を取得します。

node scripts/incident-metrics.mjs \
  --cluster <cluster> \
  --namespace <namespace> \
  --deployment <deployment> \
  --from <ISO8601> \
  --to <ISO8601>

レポート内容：

  • クラスター：割り当て可能なリソースに対するCPU使用率と要求率
  • デプロイメント：CPU／メモリの使用量と要求量の比較、利用不可率
  • HPA：現在／目標／最大のレプリカ数
  • キャパシティプランニング：予約率の上限を80％および70％とした場合に必要な割り当て可能コア数
  • チューニングの順序：手順を追った推奨事項（一度に1つの設定項目を調整）
解釈に関する注意事項
  • OOMKills またはメモリ使用量が上限に近いことが確認されない限り、limits.memory は変更しないでください
  • --out <path> を使うと、詳細な分析や実行間の差分比較に使える完全な JSON を保存できます
  • 両方のスクリプトで --help を実行すると、すべてのオプション（相対時間枠、カスタム HPA 名、整形済み JSON）を確認できます

コメント

Markdown 対応