HPA

はじめに Kubernetesを本番環境で運用する上で、適切なリソース管理とスケーリングは避けて通れない課題です。過剰なリソース割り当てはコストの無駄になり、不足していればパフォーマンス低下やサービス障害につながります。 本記事では、Kubernetesの自動スケーリング機能であるHorizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）について、基礎概念から本番環境での実践的な運用ノウハウまでを詳しく解説します。 HPAとVPAの違い Horizontal Pod Autoscaler（HPA） HPAは、Pod数を水平方向にスケールさせる機能です。負荷が増加するとPod数を増やし、負荷が減少するとPod数を減らします。 適用シーン： ステートレスなWebアプリケーション APIサーバー ワーカープロセス Vertical Pod Autoscaler（VPA） VPAは、個々のPodのリソース要求（CPU/メモリ）を垂直方向に調整する機能です。実際の使用状況に基づいて、より適切なリソース割り当てを推奨・適用します。 適用シーン： ステートフルなアプリケーション データベースやキャッシュサーバー バッチ処理ジョブ HPA実践ガイド 基本的なHPA設定 まずはシンプルなCPUベースのHPAから始めましょう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: web-api namespace: production spec: replicas: 3 selector: matchLabels: app: web-api template: metadata: labels: app: web-api spec: containers: - name: web-api image: myregistry/web-api:v1.2.3 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1000m memory: 512Mi ports: - containerPort: 8080 readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 --- # hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-api-hpa namespace: production spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-api minReplicas: 3 maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 selectPolicy: Max カスタムメトリクスを使ったHPA CPUやメモリだけでなく、アプリケーション固有のメトリクスでスケーリングすることも可能です。 ...

Kubernetesキャパシティ設計実践：HPA/VPA/Cluster Autoscalerを衝突させない運用術 Kubernetes は「自動でスケールするから安心」と思われがちですが、実運用では逆です。HPA、VPA、Cluster Autoscaler（CA）の設定が噛み合わないと、スケールアウトと再スケジューリングが衝突し、レイテンシ悪化やコスト増大を引き起こします。 本記事では、3つのオートスケーリング機構を同時運用する際の設計ポイントを、障害対応目線で整理します。 1. 役割分担を明確にする まず前提として、各コンポーネントの責務を固定します。 HPA: Pod 数を短期的に増減 VPA: Pod あたりの requests/limits を中長期で最適化 CA: ノード数を増減 この役割分担が曖昧だと、同じ問題を複数レイヤーで同時に解こうとして不安定化します。特に Web/API ワークロードでは、HPA を主軸、VPA は recommendation 中心で始めるのが安全です。 2. requests/limits が崩れていると全て失敗する HPA の CPU 指標は requests 基準で計算されます。requests が不正確だと、HPA の判断もズレます。最初にやるべきは次です。 過去 2 週間の実使用量を可視化 p95 使用量を requests の初期値に設定 limits は requests の 1.5〜2 倍で開始 極端に低い requests は「見かけの高負荷」を作り、不要スケールを誘発します。逆に高すぎる requests は CA の過剰増設を招きます。 3. HPA 指標選定の実践 CPU だけで運用すると、I/O 待ちや外部 API 待ちのボトルネックを見逃します。推奨は複合指標です。 CPU Utilization（基本） メモリ使用率（リーク監視） RPS あたりレイテンシ（SLO 接続） Queue 長（非同期処理） autoscaling/v2 では複数メトリクスを扱えるため、最初から設計しておくと後で楽です。 ...