Kubernetes HorizontalPodAutoscaler (HPA v2) ジェネレーター

Kubernetes HorizontalPodAutoscaler (HPA v2) ジェネレーター

K8s 1.23+ GA

CPU・メモリ使用率ターゲット、カスタムメトリクス、スケールアップ/ダウンの安定化ポリシーを含む Kubernetes HPA v2 (autoscaling/v2) マニフェストを生成します。

Presets:
HPA 設定
レプリカ境界Scale: 2 → 10 ポッド
minReplicas
maxReplicas
Kubernetes スケジューリング注意点: トラフィック低下時でも HPA は minReplicas (2), 以下にはスケールダウンせず、最大 maxReplicas (10).
Replicas: 2-10Metrics: 2
Target: api-service
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service-hpa
  namespace: production
  labels:
    app.kubernetes.io/name: api-service
    app.kubernetes.io/managed-by: toolsaa-k8s-hpa-generator
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
        - type: Pods
          value: 4
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Min
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
Lines: 46Size: 1035 B
autoscaling/v2 syntax ready
APIバージョン
autoscaling/v2 (K8s 1.23+)
ターゲットメトリクス
2 件の規則設定済み
動作安定化ポリシー
300s 秒クールダウン

クライアントサイド安全処理

外部サーバーへの通信は一切行わず、ブラウザ内メモリで安全かつ高速にマニフェストを生成します。

完全ローカル・プライバシー保護

すべてのクラスター設定とメトリクス値は端末内に保持され、外部サーバーへ送信されることはありません。

本番環境対応の出力仕様

Kubernetes autoscaling/v2 仕様に完全準拠し、kubectl apply で即座にデプロイ可能な最適化 YAML を出力します。

技術リファレンス＆アーキテクチャガイド

Kubernetes HorizontalPodAutoscaler (HPA v2) 生成ツール — リファレンスガイド

CPU・メモリ使用率ターゲット、カスタムメトリクス、スケールアップ/ダウンの安定化ポリシーを含む Kubernetes HPA v2 (autoscaling/v2) マニフェストを生成します。

主要パラメータ＆設定項目

scaleTargetRefオブジェクト (apiVersion, kind, name)

自動スケーリング対象となるワークロードリソース（通常は apps/v1 の Deployment、StatefulSet、または ReplicaSet）を指定します。

初期値: { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicas整数 (正数)

ポッドレプリカ数の絶対的な下限値と上限値を定義します。コントローラーは負荷状況に関わらず、この範囲外にスケーリングすることはありません。

初期値: minReplicas: 2, maxReplicas: 10
metrics配列 (Resource | ContainerResource | Pods | Object | External)

評価対象となるメトリクスルールのリスト。CPU/メモリの標準リソース（averageUtilization または averageValue）、特定コンテナ向けメトリクス、カスタム/外部メトリクスに対応します。

初期値: [{ type: "Resource", resource: { name: "cpu", target: { type: "Utilization", averageUtilization: 70 } } }]
behavior.scaleDownオブジェクト (stabilizationWindowSeconds, policies, selectPolicy)

スケールダウン時に適用される安定化時間ウィンドウとレート制限ポリシー。フラッピング（急激な増減の反復）を防止し、ポッドの安全な停止を担保します。

初期値: { stabilizationWindowSeconds: 300, selectPolicy: "Min", policies: [{ type: "Percent", value: 10, periodSeconds: 60 }] }
behavior.scaleUpオブジェクト (stabilizationWindowSeconds, policies, selectPolicy)

急激なトラフィックスパイクへ即応するためのスケールアップ拡張レート、安定化ディレイ、バースト拡張ポリシーを定義します。

初期値: { stabilizationWindowSeconds: 0, selectPolicy: "Max", policies: [{ type: "Percent", value: 100, periodSeconds: 15 }, { type: "Pods", value: 4, periodSeconds: 15 }] }

プロの活用テクニック＆推奨設定

HPA コントローラーはコンテナの 'res

HPA コントローラーはコンテナの 'resources.requests' を基準に使用率（パーセンテージ）を計算します。Deployment 内で requests を省略すると、HPA は '<unknown>/target%' エラーとなり自動スケーリングが完全に停止します。

非対称な安定化ウィンドウを設定してフラッピングを防止する

急なトラフィック増加に即応するため 'behavior.scaleUp.stabilizationWindowSeconds: 0' を維持しつつ、スケールダウン側は 'behavior.scaleDown.stabilizationWindowSeconds: 300'（5分間）に設定してください。これにより境界値付近での急激な振動（スラッシング）を確実に防げます。

厳しい PDBの最適化

厳しい PDB（例: minAvailable: 80%）が設定されている環境では、過度に急激なスケールダウン（15秒ごとに50%削減など）を避けてください。'type: Percent, value: 10' や 'type: Pods, value: 1' を使用し、安全な縮小ステップを確保します。

同一リソースに対して HPA と VPA を重複稼働させない

CPU やメモリメトリクスに対して HPA（水平）と VPA（垂直）を同時に自動更新モードで実行すると、制御ループの競合が発生します。併用する場合は、HPA を HTTP リクエスト数やキュー長などのカスタムメトリクスで制御し、VPA をリソースサイジングに専念させてください。

よくあるトラブルと解決策

HPA のステータスが 'TARGETS: <unknown>/70%' となりスケーリングが実行されない。

対象 Deployment のすべてのコンテナに 'resources.requests.cpu'（メモリ基準の場合は memory）が定義されているか確認してください。また、'kubectl top pods' や 'kubectl get apiservice v1beta1.metrics.k8s.io' を実行して Metrics Server が正常に稼働しているか検証します。

ワークロードが短時間でスケールアップとスケールダウンを激しく繰り返す（フラッピング）。

'behavior.scaleDown.stabilizationWindowSeconds' を 300〜600 秒に引き上げてください。さらに 'selectPolicy: Min' を指定した穏やかな scaleDown ポリシー（例: 60秒間に最大10%または1〜2ポッド削減）を導入します。

カスタムメトリクスまたは外部メトリクスで 'unable to fetch metrics: metric not found' が発生する。

カスタムメトリクスアダプター（Prometheus Adapter、KEDA、Datadog Cluster Agent 等）がデプロイされ、'kubectl get apiservices' に登録されていることを確認してください。また、メトリクス名やラベルセレクターがアダプターの公開カタログと完全一致しているか照合します。

よくある質問 (FAQ)

autoscaling/v1 と autoscaling/v2 の決定的な違いは何ですか？▼

旧来の 'autoscaling/v1' は Deployment に対する CPU 使用率（パーセント）のみをサポートしていました。'autoscaling/v2'（Kubernetes 1.23 以降で正式推奨）では、CPU/メモリの複数同時評価、カスタム/外部メトリクス、コンテナ単位メトリクス、および scaleUp/scaleDown の挙動を細かく制御できる 'behavior' 設定が導入されています。

HPA はどのような計算式で目標レプリカ数を算出しますか？▼

HPA は次の計算式を採用しています: 目標レプリカ数 = ceil[現在のレプリカ数 * (現在のメトリクス値 / 目標メトリクス値)]。例えば、4レプリカ稼働中で現在のCPU使用率が80%、目標が50%の場合、ceil[4 * (80 / 50)] = ceil[6.4] = 7レプリカとなります。なお、比率が許容誤差（デフォルト10%、0.9〜1.1）以内の場合はスケーリングは実行されません。

なぜメモリ使用率による自動スケーリングは危険視されるのですか？▼

CPU はアイドル時に即座に負荷が下がりますが、Java (JVM) や Go、Node.js などのアプリケーションランタイムは確保したメモリ領域を保持し続けたり、ガベージコレクションを遅延実行したりします。そのため負荷低下後もメモリ使用率が高止まりし、HPA がスケールダウンできなくなるリスクがあるためです。

HPA behavior における selectPolicy: Min と Max はどう機能しますか？▼

scaleUp または scaleDown に複数のポリシーが設定されている場合、'selectPolicy' で採用ルールを決定します。'Min' はレプリカ数の変動幅が最も小さい（最も保守的な）ポリシーを選択し、'Max' は変動幅が最も大きい（最もアグレッシブな）ポリシーを選択します。スケールアップは即応性のためデフォルトで 'Max' が使用されます。

HPA でレプリカ数を 0 までスケールダウンすることは可能ですか？▼

Kubernetes 1.23 以降（1.28 以降で正式有効化）、カスタムメトリクスや外部メトリクスを使用する場合に限り 'minReplicas: 0' を設定可能です（0ポッド時はCPU/メモリの計測が不可能なため）。完全なゼロスケールによるイベント駆動アーキテクチャを実現する場合は、KEDA や Knative の導入が推奨されます。

関連するおすすめ開発ツール

すべてのツール →
Redis (redis.conf) 本番運用設定ビルダー＆チューニングガイド開発ツール

maxmemory退避ポリシー、RDB/AOF永続化、ネットワークバインド、セキュリティACL認証を最適化したredis.conf設定ファイルを即座に生成・調整します。

ツールを開く→
PostgreSQL (postgresql.conf) ハードウェアチューニング＆構成ビルダー開発ツール

ハードウェアスペック（RAM、CPU、ストレージ種別）に基づき、shared_buffers、work_mem、effective_cache_size、max_connections などの最適化された postgresql.conf 設定を自動計算・生成します。

ツールを開く→
Linux Systemd (.timer & .service) ユニット生成ツール開発ツール

OnCalendar スケジューリング、OnBootSec インターバル、Persistent 実行、ランダム遅延（ジッター）を備えた実用的な systemd タイマーおよびコンパニオンサービスユニットを設計・生成します。

ツールを開く→
TypeScript (tsconfig.json) 設定ジェネレーター開発ツール

Next.js、Node.js、Vite、ライブラリ開発に最適な現代的で堅牢な tsconfig.json 設定を生成。厳格モード、パスエイリアス、モジュール解決を完全サポート。

ツールを開く→
JSONからClickHouse CREATE TABLE DDL生成ツール開発ツール

サンプルJSONドキュメントを解析し、MergeTreeエンジン、UInt/Int/Float/String/DateTime型、Array/Nestedカラムマッピングを備えた最適なClickHouse SQL DDLに変換します。

ツールを開く→
JSONからGoogle BigQueryテーブルスキーマ生成ツール開発ツール

JSONオブジェクトを解析し、RECORDモード、STRING、INTEGER、NUMERIC、TIMESTAMPフィールドを含むGoogle Cloud BigQueryテーブルスキーマJSONを自動推論・変換します。

ツールを開く→