KubernetesでHPAとVPAを併用し、CPU指標の競合を避ける

負荷を複数のPodに分散できるならHPAでレプリカ数を調整し、PodごとのCPU・メモリ要求量を実際の使用状況に合わせたいならVPAを使う。KubernetesのHPA公式文書にあるCPU使用率は、現在の使用量をコンテナのCPU requestsと比べて計算するため、要求量の変更はHPAの判断にも影響する。

両方を使う場合は、まずVPAをOffモードにして推奨値だけを確認する。KubernetesのVPA公式文書では、Offモードの推奨値はVPAオブジェクトのstatusに記録され、Podには自動適用されない。継続的に併用するなら、HPAがCPU使用率を見る構成ではVPAの変更対象をメモリに限定するなど、CPU requestsをVPAが自動変更しない条件を作る。

CPU要求量を共有すると判断が揺れる理由

HPAがCPU使用率を指標にするとき、分母はPodのCPU requestsになる。VPAがそのrequestsを引き下げれば、実際のCPU使用量が同じでも使用率は高く見える。HPAがPodを増やした後にはPod当たりの使用量が変わり、それを見たVPAが再び要求量を調整し得る。互いの変更が次の判断材料に入り込む構造だ。

CAST AIの運用解説は、CPU使用率を使うHPAとCPU requestsを自動調整するVPAの組み合わせで、このフィードバックが生じると説明している。回避する方法は、VPAをOffにして推奨値を手動で扱う、HPAをリクエスト数やキュー長などCPU requestsを分母にしない指標で動かす、またはCPUをHPA、メモリをVPAの管理対象に分けることだ。

指標を分けても、VPAが推奨値を適用する際のPod更新は別の問題として残る。併用を決めるときは、HPAが何を測るかに加え、VPAがどのリソースを、どの更新方式で変更するかを指定する必要がある。

Web API：負荷を分散できるならHPAを軸にする

独立したリクエストを追加のPodへ振り分けられるWeb APIでは、急なアクセス増への対応にHPAが合う。CPU使用率は設定しやすい候補だが、CPU負荷がリクエスト量を十分に表さないサービスなら、Pod当たりのリクエスト数や処理待ちを指標にする方が目的に近い。HPAの指標を決める前に、追加したPodが準備完了となり、実際に通信を受けられるまでの時間も見積もる。

CPU使用率を採用する場合は、指標の対象となるコンテナにCPU requestsを設定する。対象Pod内に必要なrequestsが欠けていると、PodのCPU使用率を定義できず、その指標ではHPAが増減を判断できない。サイドカーを含むPod全体の使用率がアプリケーション本体の負荷を隠す場合は、対象コンテナを指定する指標も候補になる。

この構成でVPAの推奨値を得るなら、最初はOffにする。メモリ要求量だけを自動調整する段階に進む場合は、VPAのcontainerPoliciesでcontrolledResourcesをmemoryに限定し、CPU requestsを管理対象から外す。リクエスト数などをHPAに渡す構成では、値を計測するだけでなく、対応するカスタム指標または外部指標のAPIへ公開するアダプターも必要だ。

JVMサービス：レプリカ数とPod内のメモリを分けて考える

JVMサービスが複数Podへ仕事を分配できるなら、アクセスや処理待ちに応じたHPAを検討できる。ただし、Podを増やしても、個々のプロセスのヒープ設定とコンテナのメモリ枠が合っていなければ、そのPodのメモリ不足は解消しない。まず現在のrequests、メモリ使用量、起動に要する時間を確認し、VPAの推奨値と照らしてPod単位の設定を見直す。

CPU使用率でHPAを動かすなら、VPAにCPU requestsを自動変更させない構成が分かりやすい。VPAのInitialモードは稼働中のPodを更新せず、新しく作られたPodに推奨値を適用する。しかしCPUも制御対象なら、新旧PodでCPU使用率の基準となるrequestsが異なり得る。Initialを選ぶだけで指標の干渉がなくなるわけではない。

メモリだけをVPAに任せる場合も、requestsとlimitsの扱いを分ける。controlledValuesをRequestsOnlyにすれば要求量だけが変わり、既存のlimitは残る。メモリの要求量を適正化できても、アプリケーションに必要な上限が足りるかは別途判断する必要がある。

単一Podのデータベース：更新時の停止を先に評価する

単一Podのデータベースでは、HPAでレプリカを増やす前に、複製、書き込み先、接続先の切り替えを設計しているかが分岐点になる。これらを備えずにPod数だけ増やしても、同じデータを安全に処理できる構成にはならない。CPU・メモリ要求量の見直しが目的なら、VPAをOffで動かし、推奨値を計画した更新へ反映する方が判断しやすい。

VPAのRecreateモードは、Podを退避させ、ワークロードのコントローラーが作る代替Podに新しい要求量を適用する。単一Podでこの更新を許すなら、サービス停止と復旧にかかる時間を運用上受け入れられるか確かめる。InPlaceOrRecreateモードはその場での変更を試みるが、適用できない場合は退避と再作成に切り替わるため、無停止を前提に選べない。

複製されたデータベースでも、HPAが適切かは読み取りと書き込みの役割、データ同期、追加Podが利用可能になるまでの時間に左右される。レプリカを増やせるという技術上の条件と、負荷増に応じて自動で増やすべきかという運用上の判断を分けておく。

設定と導入順をどう組み立てるか

設定では、HPAのscaleTargetRefに対象ワークロードを指定し、metricsに負荷を表す指標を置く。VPAではtargetRefで同じ対象を指定したうえで、updatePolicy.updateModeとresourcePolicy.containerPoliciesにより、推奨値の適用方法と変更するリソースを絞る。以下は値を固定しない構成例であり、requestsやHPAのしきい値は対象サービスの実測から決める。

Web APIの急増負荷：HPAは分散可能なリクエスト量などを指標にし、必要な指標アダプターを用意する。VPAはOffから始め、推奨値を確認してrequestsへ反映する。
CPU使用率で伸縮させるWeb APIまたはJVMサービス：対象コンテナにCPU requestsを設定する。VPAによる継続的な調整が必要ならcontrolledResourcesをmemoryに限定し、更新方式によるPodの入れ替えも評価する。
単一Podのデータベース：レプリカ増加を前提にせず、VPAのOffモードで推奨値を得る。要求量の変更は、バックアップ、停止可能時間、復旧手順を含む計画的な更新に組み込む。

VPAはKubernetes本体とは別に導入する必要があり、利用状況を得るメトリクス源も要る。HPAがCPUなどのリソース指標を使う場合は、通常Metrics Serverが提供するmetrics.k8s.ioを利用する。カスタム指標や外部指標を使う場合は、それぞれの指標APIからHPAが値を取得できる構成が必要になる。

導入時は現在のrequestsと負荷時の使用量を把握し、VPAをOffにしてstatus.recommendationを確認する。その値を手動で反映した後、HPAが使う指標とPodの準備完了までの時間を観察する。自動適用へ進む判断は、指標の分担に加え、VPAの更新によってPodを入れ替えてもサービス要件を満たせるかで決める。