水平Pod自動スケーリング

Kubernetesでは、HorizontalPodAutoscaler は自動的にワークロードリソース(DeploymentやStatefulSetなど)を更新し、需要に合わせて自動的にスケーリングすることを目指します。

水平スケーリングとは、負荷の増加に対応するために、より多くのPodをデプロイすることを意味します。 これは、Kubernetesの場合、既に稼働しているワークロードのPodに対して、より多くのリソース(例: メモリーやCPU)を割り当てることを意味する 垂直 スケーリングとは異なります。

負荷が減少し、Podの数が設定された最小値より多い場合、HorizontalPodAutoscalerはワークロードリソース(Deployment、StatefulSet、または他の類似のリソース)に対してスケールダウンするよう指示します。

水平Pod自動スケーリングは、スケーリングできないオブジェクト(例: DaemonSet)には適用されません。

HorizontalPodAutoscalerは、Kubernetes APIリソースとコントローラーとして実装されています。 リソースはコントローラーの動作を決定します。 Kubernetesコントロールプレーン内で稼働している水平Pod自動スケーリングコントローラーは、平均CPU利用率、平均メモリ利用率、または指定した任意のカスタムメトリクスなどの観測メトリクスに合わせて、ターゲット(例: Deployment)の理想的なスケールを定期的に調整します。

水平Pod自動スケーリングの使用例のウォークスルーがあります。

HorizontalPodAutoscalerの仕組みは?

graph BT hpa[HorizontalPodAutoscaler] --> scale[スケール] subgraph rc[Deployment] scale end scale -.-> pod1[Pod 1] scale -.-> pod2[Pod 2] scale -.-> pod3[Pod N] classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; class hpa hpa; class rc rc; class scale scale; class pod1,pod2,pod3 pod

図1. HorizontalPodAutoscalerはDeploymentとそのReplicaSetのスケールを制御します

Kubernetesは、水平Pod自動スケーリングを断続的に動作する制御ループとして実装しています(これは連続的なプロセスではありません)。 その間隔はkube-controller-managerの--horizontal-pod-autoscaler-sync-periodパラメーターで設定します(デフォルトの間隔は15秒です)。

各ループ中に一度、コントローラーマネージャーはHorizontalPodAutoscalerの各定義に指定されたメトリクスに対するリソース使用率を照会します。 コントローラーマネージャーはscaleTargetRefによって定義されたターゲットリソースを見つけ、ターゲットリソースの.spec.selectorラベルに基づいてPodを選択し、リソースメトリクスAPI(Podごとのリソースメトリクスの場合)またはカスタムメトリクスAPI(他のすべてのメトリクスの場合)からメトリクスを取得します。

  • Podごとのリソースメトリクス(CPUなど)の場合、コントローラーはHorizontalPodAutoscalerによってターゲットとされた各PodのリソースメトリクスAPIからメトリクスを取得します。 その後、使用率の目標値が設定されている場合、コントローラーは各Pod内のコンテナの同等のリソース要求に対する割合として使用率を算出します。 目標値が生の値として設定されている場合、メトリクスの実測値が直接使用されます。 次に、コントローラーは対象となるすべてのPod間で使用率または生の値(指定されたターゲットのタイプに応じて)の平均を取り、望ましいレプリカ数にスケールするために使用する比率を算出します。

    Podのコンテナの一部に関連するリソース要求が設定されていない場合、PodのCPU利用率は定義されず、オートスケーラーはそのメトリクスに対して何も行わないことに注意してください。 オートスケーリングアルゴリズムの動作についての詳細は、以下のアルゴリズムの詳細をご覧ください。

  • Podごとのカスタムメトリクスについては、コントローラーはPodごとのリソースメトリクスと同様に機能しますが、使用率の値ではなくメトリクスの実測値で動作します。

  • オブジェクトメトリクスと外部メトリクスについては、問題となるオブジェクトを表す単一のメトリクスが取得されます。 このメトリクスは目標値と比較され、上記のような比率を生成します。 autoscaling/v2 APIバージョンでは、比較を行う前にこの値をPodの数で割ることもできます。

HorizontalPodAutoscalerを使用する一般的な目的は、集約API(metrics.k8s.io、custom.metrics.k8s.io、またはexternal.metrics.k8s.io)からメトリクスを取得するように設定することです。 metrics.k8s.io APIは通常、別途起動する必要があるメトリクスサーバーというアドオンによって提供されます。 リソースメトリクスについての詳細は、メトリクスサーバーをご覧ください。

メトリクスAPIのサポートでは、これらの異なるAPIの安定性の保証とサポート状況について説明しています。

HorizontalPodAutoscalerコントローラーは、スケーリングをサポートするワークロードリソース(DeploymentやStatefulSetなど)にアクセスします。 これらのリソースはそれぞれscaleというサブリソースを持っており、これはレプリカの数を動的に設定し、各々の現在の状態を調べることができるインターフェースを提供します。 Kubernetes APIのサブリソースに関する一般的な情報については、Kubernetes API Conceptsをご覧ください。

アルゴリズムの詳細

最も基本的な観点から言えば、HorizontalPodAutoscalerコントローラーは、理想のメトリクス値と現在のメトリクス値との間の比率に基づいて動作します:

$$\begin{equation*} desiredReplicas = ceil\left\lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \right\rceil \end{equation*}$$

たとえば、現在のメトリクス値が200mで、理想の値が100mの場合、レプリカの数は倍増します。なぜなら、\( { 200.0 \div 100.0 } = 2.0 \)だからです。 現在の値が50mの場合、レプリカの数は半分になります。なぜなら、\( { 50.0 \div 100.0 } = 0.5 \)だからです。 コントロールプレーンは、比率が十分に1.0に近い場合(設定可能な許容範囲内で、デフォルトでは0.1)には、任意のスケーリング操作をスキップします。

targetAverageValueまたはtargetAverageUtilizationが指定されている場合、currentMetricValueは、HorizontalPodAutoscalerのスケールターゲット内のすべてのPodで指定されたメトリクスの平均を取ることで計算されます。

許容範囲を確認し、最終的な値を決定する前に、コントロールプレーンは、メトリクスが欠けていないか、また何個のPodがReady状態であるかを考慮します。 削除タイムスタンプが設定されているすべてのPod(削除タイムスタンプがあるオブジェクトはシャットダウンまたは削除の途中です)は無視され、失敗したPodはすべて破棄されます。

特定のPodがメトリクスを欠いている場合、そのPodは後の処理のために保留されます。 メトリクスが欠けているPodは、最終的なスケーリング量の調整に使用されます。

CPUに基づいてスケーリングする場合、まだReadyになっていないPod(まだ初期化中か、おそらく不健全)がある場合、または そのPodの最新のメトリクスポイントがReadyになる前に取得されたものである場合、そのPodも保留されます。

技術的な制約により、HorizontalPodAutoscalerコントローラーは、特定のCPUメトリクスを保留にするかどうかを判断する際に、Podが初めてReadyになった時刻を正確に決定することはできません。 その代わり、Podが起動してから設定可能な短い時間内にReadyに遷移した場合、そのPodを「まだReadyになっていない」とみなします。 この値は、--horizontal-pod-autoscaler-initial-readiness-delayコマンドラインオプションで設定し、デフォルトは30秒です。 Podが一度Readyになった後でも、起動から一定時間(設定可能)が経過するまでは、その間に発生したすべてのReady状態への遷移を最初の遷移として扱います。 この値は、--horizontal-pod-autoscaler-cpu-initialization-periodコマンドラインオプションで設定し、デフォルトは5分です。

次に、上記で保留されたり、破棄されたりしていない残りのPodを使用して、\( currentMetricValue \over desiredMetricValue \)の基本スケール比率が計算されます。

メトリクスが欠落しているPodがある場合、コントロールプレーンはより保守的に平均を再計算します。 スケールダウンの場合は、メトリクスが欠落しているPodが目標値の100%を消費していると仮定し、スケールアップの場合は0%を消費していると仮定します。 これにより、過度なスケーリングが抑制されます。

さらに、まだReadyでないPodが存在し、メトリクスが欠落しているPodやまだReadyでないPodを考慮せずにワークロードがスケールアップする場合、コントローラーは保守的に、まだReadyでないPodが目標メトリクスの0%を消費していると仮定し、スケールアップの規模をさらに抑制します。

まだReadyでないPodとメトリクスが欠落しているPodを考慮した後、コントローラーは使用率の比率を再計算します。 新しい比率がスケールの方向を逆転させるか、許容範囲内である場合、コントローラーはスケーリング操作を行いません。 その他の場合、新しい比率がPodの数の変更を決定するために使用されます。

新しい使用率が使用される場合でも、HorizontalPodAutoscalerのステータスを通じて報告される平均使用率の 元の 値は、まだReadyでないPodやメトリクスが欠落しているPodを考慮しないものであることに注意してください。

HorizontalPodAutoscalerに複数のメトリクスが指定されている場合、この計算は各メトリクスに対して行われ、その後、理想のレプリカ数の最大値が選択されます。 これらのメトリクスのいずれかが理想のレプリカ数に変換できない場合(例えば、メトリクスAPIからのメトリクスの取得エラーなど)で、かつ取得可能なメトリクスがスケールダウンを提案する場合、スケーリングはスキップされます。 これは、1つ以上のメトリクスが現在の値よりも大きなdesiredReplicasを示す場合でも、HPAはまだスケーリングアップ可能であることを意味します。

最後に、HPAがターゲットをスケールする直前に、スケール推奨値が記録されます。 コントローラーは、設定可能なウィンドウ内のすべての推奨値を考慮し、そのウィンドウ内で最も高い推奨値を選択します。 この値は、--horizontal-pod-autoscaler-downscale-stabilizationコマンドラインオプションを使用して設定でき、デフォルトは5分です。 これは、スケールダウンが段階的に行われ、急激に変動するメトリクス値の影響を平滑化することを意味します。

Podの準備状態と自動スケーリングメトリクス

HorizontalPodAutoscaler(HPA)コントローラーには、起動時にPodからCPUメトリクスを収集する際の動作に影響を与える2つのコマンドラインオプションがあります:

  1. --horizontal-pod-autoscaler-cpu-initialization-period(デフォルト: 5分)

これは、Pod起動後の時間ウィンドウを定義し、その間は次の条件を満たさない限り CPUの使用状況が無視されます: - PodがReady状態である かつ - メトリクスサンプルがReady状態の期間中に完全に取得されている

このコマンドラインオプションは、初期化中のPod(例: ウォームアップ中のJavaアプリケーション)からの 誤解を招く高いCPU使用率を除外 し、HPAスケーリングの決定に役立ちます。

  1. --horizontal-pod-autoscaler-initial-readiness-delay(デフォルト: 30秒)

このオプションは、Pod起動後の短い遅延期間を定義します。 この期間中、以前に一時的にReady状態に遷移していたとしても、現在Unready状態のPodはHPAコントローラーによって依然として初期化中として扱われます。

これは次のことを目的としています: - 起動時にReadyとUnreadyの間で急速に変動するPodを含めることを避ける。 - HPAがメトリクスを有効とみなす前に、初期準備状態シグナルの安定性を確保する。

これらのコマンドラインオプションは、クラスター全体でのみ設定できます。

Podの準備状態の主な挙動

  • PodがReadyで、Readyのままである場合、遅延時間内であってもメトリクスに貢献していると見なされます。
  • PodがReadyとUnreadyの間で急速に切り替わる場合、安定してReadyと見なされるまでメトリクスは無視されます。

Podの準備状態のベストプラクティス

  • 高いCPU使用率が収まるまで成功しないstartupProbeを設定する、または
  • initialDelaySecondsを使用して、CPUスパイクが収まった 後 にのみReadyを報告するreadinessProbeを設定する。

そして理想的には、起動期間をカバーする ように--horizontal-pod-autoscaler-cpu-initialization-periodを設定します。

APIオブジェクト

HorizontalPodAutoscalerは、Kubernetesのautoscaling APIグループのAPIリソースです。 現在の安定バージョンはautoscaling/v2 APIバージョンで提供されており、メモリやカスタムメトリクスに基づくスケーリングをサポートしています。 autoscaling/v2で導入された新たなフィールドは、autoscaling/v1で作業する際にはアノテーションとして保持されます。

HorizontalPodAutoscaler APIオブジェクトを作成するときは、指定された名前が有効なDNSサブドメイン名であることを確認してください。 APIオブジェクトについての詳細は、HorizontalPodAutoscaler Objectを参照してください。

ワークロードのスケーリングの安定性

HorizontalPodAutoscalerを使用してレプリカ群のスケールを管理する際、評価されるメトリクスの動的な性質により、レプリカの数が頻繁に変動し続ける可能性があります。 これは、スラッシング または フラッピング と呼ばれることがあります。 これは、サイバネティクスにおける ヒステリシス の概念に似ています。

ローリングアップデート中の自動スケーリング

Kubernetesでは、Deploymentに対してローリングアップデートを行うことができます。 その場合、Deploymentが基礎となるReplicaSetを管理します。 Deploymentに自動スケーリングを設定すると、HorizontalPodAutoscalerを単一のDeploymentに結びつけます。 HorizontalPodAutoscalerはDeploymentのreplicasフィールドを管理します。 Deploymentコントローラーは、ロールアウト時およびその後も適切な数になるように、基礎となるReplicaSetのreplicasを設定する責任があります。

自動スケールされたレプリカ数を持つStatefulSetのローリングアップデートを実行する場合、StatefulSetは直接そのPodのセットを管理します(ReplicaSetのような中間リソースは存在しません)。

リソースメトリクスのサポート

HPAの任意のターゲットは、スケーリングターゲット内のPodのリソース使用状況に基づいてスケールすることができます。 Podの仕様を定義する際には、cpuやmemoryなどのリソース要求を指定する必要があります。 これはリソースの使用状況を決定するために使用され、HPAコントローラーがターゲットをスケールアップまたはスケールダウンするために使用されます。 リソース使用状況に基づくスケーリングを使用するには、以下のようなメトリクスソースを指定します:

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

このメトリクスを使用すると、HPAコントローラーはスケーリングターゲット内のPodの平均使用率を60%に保ちます。 使用率は、Podの要求したリソースに対する現在のリソース使用量の比率です。 使用率がどのように計算され、平均化されるかの詳細については、アルゴリズムを参照してください。

コンテナリソースメトリクス

FEATURE STATE: Kubernetes v1.30 [stable](enabled by default)

HorizontalPodAutoscaler APIは、コンテナメトリクスソースもサポートしています。 これは、ターゲットリソースをスケールするために、HPAが一連のPod内の個々のコンテナのリソース使用状況を追跡できるようにするものです。 これにより、特定のPodで最も重要なコンテナのスケーリング閾値を設定することができます。 例えば、Webアプリケーションとロギングを提供するサイドカーコンテナがある場合、サイドカーコンテナとそのリソース使用を無視して、Webアプリケーションのリソース使用に基づいてスケーリングすることができます。

ターゲットリソースを新しいPodの仕様に修正し、異なるコンテナのセットを持つようにした場合、新たに追加されたコンテナもスケーリングに使用されるべきであれば、HPAの仕様も修正すべきです。 メトリクスソースで指定されたコンテナが存在しないか、または一部のPodのみに存在する場合、それらのPodは無視され、推奨が再計算されます。 計算に関する詳細は、アルゴリズムを参照してください。 コンテナリソースを自動スケーリングに使用するためには、以下のようにメトリクスソースを定義します:

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60

上記の例では、HPAコントローラーはターゲットをスケールし、すべてのPodのapplicationコンテナ内のCPUの平均使用率が60%になるようにします。

カスタムメトリクスでのスケーリング

FEATURE STATE: Kubernetes v1.23 [stable]

(以前のautoscaling/v2beta2 APIバージョンでは、これをベータ機能として提供していました)

autoscaling/v2 APIバージョンを使用することで、HorizontalPodAutoscalerをカスタムメトリクス(KubernetesまたはKubernetesのコンポーネントに組み込まれていない)に基づいてスケールするように設定することができます。 HorizontalPodAutoscalerコントローラーはこれらのカスタムメトリクスをKubernetes APIからクエリします。

要件については、メトリクスAPIのサポートを参照してください。

複数メトリクスでのスケーリング

FEATURE STATE: Kubernetes v1.23 [stable]

(以前のautoscaling/v2beta2 APIバージョンでは、これをベータ機能として提供していました)

autoscaling/v2 APIバージョンを使用することで、HorizontalPodAutoscalerがスケールするための複数のメトリクスを指定することができます。 その後、HorizontalPodAutoscalerコントローラーは各メトリクスを評価し、そのメトリクスに基づいた新しいスケールを提案します。 HorizontalPodAutoscalerは、各メトリクスで推奨される最大のスケールを取得し、そのサイズにワークロードを設定します(ただし、これが設定した全体の最大値を超えていないことが前提です)。

メトリクスAPIのサポート

デフォルトでは、HorizontalPodAutoscalerコントローラーは一連のAPIからメトリクスを取得します。 これらのAPIにアクセスするためには、クラスター管理者は以下を確認する必要があります:

  • API集約レイヤーが有効になっていること。

  • 対応するAPIが登録されていること:

    • リソースメトリクスの場合、これは一般的にメトリクスサーバーによって提供されるmetrics.k8s.io APIです。 クラスターのアドオンとして起動することができます。

    • カスタムメトリクスの場合、これはcustom.metrics.k8s.io APIです。 これはメトリクスソリューションベンダーが提供する「アダプター」APIサーバーによって提供されます。 利用可能なKubernetesメトリクスアダプターがあるかどうかは、メトリクスパイプラインで確認してください。

    • 外部メトリクスの場合、これはexternal.metrics.k8s.io APIです。 これは上記のカスタムメトリクスアダプターによって提供される可能性があります。

これらの異なるメトリクスパスとその違いについての詳細は、HPA V2、custom.metrics.k8s.io、およびexternal.metrics.k8s.ioの関連デザイン提案を参照してください。

これらの使用方法の例については、カスタムメトリクスの使用方法と外部メトリクスの使用方法を参照してください。

設定可能なスケーリング動作

FEATURE STATE: Kubernetes v1.23 [stable]

(以前のautoscaling/v2beta2 APIバージョンでは、これをベータ機能として提供していました)

v2 HorizontalPodAutoscaler APIを使用する場合、behaviorフィールド(APIリファレンスを参照)を使用して、スケールアップとスケールダウンの振る舞いを個別に設定することができます。 これらの振る舞いは、behaviorフィールドの下でscaleUpおよび/またはscaleDownを設定することにより指定します。

スケーリングポリシーにより、スケーリング中のレプリカの変化率を制御することができます。 また、フラッピングを防ぐために2つの設定を使用できます: レプリカ数を平滑化するための 安定化ウィンドウ を指定し、指定された閾値以下の小さなメトリクス変動を無視するための許容範囲を指定できます。

スケーリングポリシー

1つ以上のスケーリングポリシーをspecのbehaviorセクションで指定することができます。 複数のポリシーが指定された場合、デフォルトで最も多くの変更を許可するポリシーが選択されます。 次の例は、スケールダウンする際のこの振る舞いを示しています:

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

periodSecondsは、ポリシーが真でなければならない過去の時間の長さを示します。 periodSecondsに設定できる最大値は1800(30分)です。 最初のポリシー(Pods)では、1分間で最大4つのレプリカをスケールダウンできます。 2つ目のポリシー(Percent)では、1分間で現在のレプリカの最大10%をスケールダウンできます。

デフォルトでは、最も多くの変更を許可するポリシーが選択されるため、2つ目のポリシーはPodのレプリカの数が40を超える場合にのみ使用されます。 40レプリカ以下の場合、最初のポリシーが適用されます。 例えば、レプリカが80あり、ターゲットを10レプリカにスケールダウンしなければならない場合、最初のステップでは8レプリカが減少します。 次のイテレーションでは、レプリカの数が72で、Podの10%は7.2ですが、数値は8に切り上げられます。 オートスケーラーコントローラーの各ループで、変更するべきPodの数は現在のレプリカの数に基づいて再計算されます。 レプリカの数が40以下になると、最初のポリシー(Pods)が適用され、一度に4つのレプリカが減少します。

ポリシーの選択は、スケーリング方向のselectPolicyフィールドを指定することで変更できます。 この値をMinに設定すると、レプリカ数の最小変化を許可するポリシーが選択されます。 この値をDisabledに設定すると、その方向へのスケーリングが完全に無効になります。

安定化ウィンドウ

安定化ウィンドウは、スケーリングに使用されるメトリクスが変動し続ける場合のレプリカ数のフラッピングを制限するために使用されます。 自動スケーリングアルゴリズムは、このウィンドウを使用して以前の望ましい状態を推測し、ワークロードスケールへの望ましくない変更を避けます。

例えば、次の例のスニペットでは、scaleDownに対して安定化ウィンドウが指定されています。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

メトリクスがターゲットをスケールダウンすべきであることを示すと、アルゴリズムは以前に計算された望ましい状態を探し、指定された間隔から最高値を使用します。 上記の例では、過去5分間のすべての望ましい状態が考慮されます。

これはスライディングウィンドウ方式で最大値を近似し、スケーリングアルゴリズムが頻繁にPodを削除して、わずかな時間後に同等のPodの再作成をトリガーするのを防ぎます。

許容範囲

FEATURE STATE: Kubernetes v1.35 [beta](enabled by default)

toleranceフィールドは、メトリクス変動の閾値を設定し、その値以下の変化に対してオートスケーラーがスケーリングするのを防ぎます。

この許容範囲は、スケーリングが発生しない理想のメトリクス値周辺の変動量として定義されます。 例えば、目標メモリー消費量が100MiBで、スケールアップの許容範囲が5%に設定されたHorizontalPodAutoscalerを考えてみましょう:

behavior:
  scaleUp:
    tolerance: 0.05 # スケールアップに対して5%の許容範囲

この設定では、HPAアルゴリズムは、メモリー消費量が105MiB(つまり: 目標の5%上)を超える場合にのみスケールアップを検討します。

このフィールドを設定しない場合、HPAはデフォルトのクラスター全体の許容範囲である10%を適用します。 このデフォルト値は、kube-controller-managerの--horizontal-pod-autoscaler-toleranceコマンドライン引数を使用して、スケールアップとスケールダウンの両方に対して更新できます。 (Kubernetes APIを使用してこのデフォルト値を設定することはできません。)

デフォルトの動作

カスタムスケーリングを使用するためには、全てのフィールドを指定する必要はありません。 カスタマイズが必要な値のみを指定することができます。 これらのカスタム値はデフォルト値とマージされます。 デフォルト値はHPAアルゴリズムの既存の動作と一致します。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

スケールダウンの場合、安定化ウィンドウは 300 秒(--horizontal-pod-autoscaler-downscale-stabilizationコマンドラインオプションが指定されている場合はその値)です。 スケールダウンのための単一のポリシーがあり、現在稼働しているレプリカの100%を削除することが許可されています。 これは、スケーリングターゲットが最小許容レプリカ数までスケールダウンできることを意味します。 スケールアップの場合、安定化ウィンドウはありません。 メトリクスがターゲットをスケールアップするべきであることを示すと、ターゲットはすぐにスケールアップされます。 2つのポリシーがあり、HPAが安定状態に達するまで、最大で15秒ごとに4つのPodまたは現在稼働しているレプリカの100%が追加されます。

例: ダウンスケール安定化ウィンドウの変更

1分間のカスタムダウンスケール安定化ウィンドウを提供するには、HPAに以下の動作を追加します:

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

例: スケールダウン率の制限

HPAによるPodの除去率を毎分10%に制限するには、HPAに以下の動作を追加します:

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

1分あたりに削除されるPodが5つを超えないようにするには、固定サイズ5の2番目のスケールダウンポリシーを追加し、selectPolicyを最小に設定することができます。 selectPolicyをMinに設定すると、オートスケーラーは最少数のPodに影響を与えるポリシーを選択します:

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60
    - type: Pods
      value: 5
      periodSeconds: 60
    selectPolicy: Min

例: スケールダウンの無効化

selectPolicyの値がDisabledの場合、指定された方向のスケーリングをオフにします。 したがって、スケールダウンを防ぐには、次のようなポリシーが使われます:

behavior:
  scaleDown:
    selectPolicy: Disabled

kubectlにおけるHorizontalPodAutoscalerのサポート

HorizontalPodAutoscalerは、他のすべてのAPIリソースと同様にkubectlによって標準的にサポートされています。 kubectl createコマンドを使用して新しいオートスケーラーを作成することができます。 kubectl get hpaを使用してオートスケーラーを一覧表示したり、kubectl describe hpaを使用して詳細な説明を取得したりできます。 また、kubectl delete hpaを使用してオートスケーラーを削除することができます。

さらに、HorizontalPodAutoscalerオブジェクトを作成するための特別なkubectl autoscaleコマンドがあります。 例えば、kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80を実行すると、ReplicaSet foo のオートスケーラーが作成され、ターゲットのCPU使用率が80%に設定され、レプリカ数は2から5の間になります。

暗黙のメンテナンスモードの非活性化

HPAの設定自体を変更することなく、ターゲットのHPAを暗黙的に非活性化することができます。 ターゲットの理想のレプリカ数が0に設定され、HPAの最小レプリカ数が0より大きい場合、HPAはターゲットの調整を停止します(そして、自身のScalingActive条件をfalseに設定します)。 これは、ターゲットの理想のレプリカ数またはHPAの最小レプリカ数を手動で調整して再活性化するまで保持されます。

DeploymentとStatefulSetを水平自動スケーリングへ移行する

HPAが有効になっている場合、Deploymentおよび/またはStatefulSetのspec.replicasの値をそのマニフェストから削除することが推奨されます。 これを行わない場合、たとえばkubectl apply -f deployment.yamlを介してそのオブジェクトに変更が適用されるたびに、これはKubernetesに現在のPodの数をspec.replicasキーの値にスケールするよう指示します。 これは望ましくない場合があり、HPAがアクティブなときに問題になる可能性があり、スラッシングやフラッピングの動作を引き起こす可能性があります。

spec.replicasの削除により、このキーのデフォルト値が1であるため(参照: Deploymentのレプリカ数)、Pod数の一時的な減少が発生する可能性があることに注意してください。 更新時に、1つを除くすべてのPodが終了処理を開始します。 その後の任意のDeploymentアプリケーションは通常どおり動作し、望み通りのローリングアップデート設定を尊重します。 デプロイメントの変更方法に応じ、以下2つの方法のいずれかにより、このPod数の一時的な減少を回避することができます:

  1. kubectl apply edit-last-applied deployment/<deployment_name>
  2. エディターでspec.replicasを削除します。保存してエディターを終了すると、kubectlが更新を適用します。 このステップではPod数に変更はありません。
  3. これでマニフェストからspec.replicasを削除できます。 ソースコード管理を使用している場合は、変更をコミットするか、更新の追跡方法に適したソースコードの改訂に関するその他の手順を行います。
  4. ここからはkubectl apply -f deployment.yamlを実行できます。

サーバーサイドApplyを使用する場合は、この具体的なユースケースをカバーしている所有権の移行ガイドラインに従ってください。

次の項目

クラスターでオートスケーリングを設定する場合、ノードの自動スケーリングも検討して、適切な数のノードを実行していることを確認することをお勧めします。 垂直 Pod自動スケーリングの詳細も参照してください。

HorizontalPodAutoscalerに関する詳細情報:

最終更新 February 09, 2026 at 10:13 PM PST: Apply final reviewer suggestions from @kfess (982604aefe)