水平 Pod 自動スケーリング

このページでは、水平 Pod 自動スケーリングの概要と、Google Kubernetes Engine（GKE）で水平 Pod 自動スケーリングがどのように機能するかについて説明します。クラスタで水平 Pod 自動スケーリングを構成して使用する方法についても説明します。

HorizontalPodAutoscaler は、Pod の数を自動的に調整して Kubernetes ワークロードの形状を変化させます。この調整は、ワークロードの CPU やメモリの消費量、Kubernetes から報告されるカスタム指標、クラスタ外部のソースから取得した外部指標に応じて行われます。

ノードの自動プロビジョニングを使用した GKE クラスタでは、Pod 数の変化に基づいてクラスタ内のノード数が自動的にスケーリングされます。このため、すべてのクラスタで水平 Pod 自動スケーリングを使用することをおすすめします。

水平 Pod 自動スケーリングを使用する理由

Kubernetes クラスタにワークロードを初めてデプロイする段階では、明確なリソース要件を把握することはできません。使用パターン、外部依存関係などの要因でリソース要件がどのように変化するのかは予測できません。水平 Pod 自動スケーリングを使用すると、さまざまな状況でワークロードが一貫して機能することを確認できます。また、必要なときにのみ追加容量分を支払うことで、費用を管理できます。

指標からワークロードのリソース不足や低使用率を予測するのは必ずしも簡単なことではありません。HorizontalPodAutoscaler は、次のタイプの 1 つ以上の指標に基づいて、ワークロード内の Pod 数を自動的にスケーリングします。

  • 実際のリソース使用量: 特定の Pod の CPU またはメモリ使用量がしきい値を超えているかどうかを判断できます。これは、そのままの数値で表すことも、そのリソースに対するポッドの要求数の割合で表すこともできます。

  • カスタム指標: 1 秒あたりのクライアント要求数や、1 秒あたりの I/O 書き込み数など、クラスタ内の Kubernetes オブジェクトによって報告される任意の指標です。

    これは、アプリケーションが CPU やメモリではなく、ネットワークのボトルネックになりやすい場合に有効です。

  • 外部指標: クラスタ外部のアプリケーションやサービスから取得した指標です。

    たとえば、Pub/Sub などのパイプラインから大量の要求を取り込むと、ワークロードの CPU 使用量が増えることがあります。キューのサイズ用の外部指標を作成して、キューサイズが所定のしきい値に達したときに Pod 数を自動的に増やし、キューサイズが縮小したときに Pod 数を減らすように HorizontalPodAutoscaler を構成できます。

HorizontalPodAutoscaler と VerticalPodAutoscaler を組み合わせることができますが、いくつかの制限があります。

水平 Pod 自動スケーリングの仕組み

構成した HorizontalPodAutoscaler のオブジェクトは制御ループを使用して動作します。ワークフローごとに個別の HorizontalPodAutoscaler があります。HorizontalPodAutoscaler は、特定のワークロードの指標と構成する目標しきい値と定期的に比較し、ワークロードの形状を自動的に変更します。

Pod ごとのリソース

CPU など、Pod ごとに割り当てられるリソースの場合、コントローラは API を使用して、Pod で実行されるコンテナごとにリソースの指標を取得します。

  • CPU またはメモリに未加工の値を指定した場合は、その値が使用されます。
  • CPU またはメモリのパーセンテージ値を指定した場合、HorizontalPodAutoscaler はその Pod の CPU またはメモリ要求の割合として平均使用率を計算します。
  • カスタム指標と外部指標は、未加工の値または平均値で表します。

コントローラは、報告された指標の平均値または未加工値を使用して比率を計算し、その比率を使用してワークロードを自動的にスケーリングします。詳しくは、Kubernetes プロジェクト ドキュメントで水平ポッド オートスケーラーのアルゴリズムの説明をご覧ください。

複数の指標への対応

ワークロードを複数の指標に基づいて自動スケールするように構成した場合、HorizontalPodAutoscaler はそれぞれの指標を個別に評価し、スケーリング アルゴリズムを使用して新しいワークロードのスケールを特定します。自動スケールのアクションには最大スケールが選択されています。

なんらかの理由で 1 つ以上の指標が利用できない場合でも、HorizontalPodAutoscaler は計算した最大サイズに基づいてスケールアップを行いますが、スケールダウンは行いません。

スラッシングの防止

スラッシングとは、ワークロードが前の自動スケーリングへの対応を完了する前に、HorizontalPodAutoscaler が新しい自動スケーリングを試みた状況を意味します。スラッシングを防ぐため、HorizontalPodAutoscaler は直近 5 分間の状況に基づいて最大の推奨値を選択します。

制限事項

  • CPU とメモリに対しては、HorizontalPodAutoscaler と VerticalPodAutoscaler を併用しないでください。HorizontalPodAutoscaler と VerticalPodAutoscaler を併用して、他の指標を測定できます。
  • Deployment がある場合は、ReplicaSet またはそれをバックアップするレプリケーション コントローラに水平 Pod 自動スケーリングを構成しないでください。Deployment またはレプリケーション コントローラにローリング アップデートを実行すると、新しいレプリケーション コントローラに置き換わります。その代わりに、Deployment 自体に水平 Pod 自動スケーリングを構成します。
  • DaemonSet などのスケーリングできないワークロードには、水平 Pod 自動スケーリングを使用できません。
  • 水平 Pod 自動スケーリングでカスタム指標または外部指標を使用して Pod を 0 にスケールダウンしてからスケールアップすることはできません。
  • 水平 Pod 自動スケーリングでは指標が Kubernetes リソースとして公開されます。そのため、指標名には大文字や「/」文字を使用できないなどの制限事項が存在します。指標アダプタでは、名前の変更が許可されている場合があります。たとえば、prometheus-adapter as 演算子をご覧ください。

スケーラビリティ

HorizontalPodAutoscaler は、サポートされる HPA オブジェクト数にハードリミットはありません。ただし、HPA オブジェクトが特定の数を超えると、HPA の再計算の間隔が標準の 15 秒を超える場合があります。

  • GKE マイナー バージョン 1.21 以前: 再計算期間は、最大 100 HPA オブジェクトで 15 秒以内に収まる必要があります。
  • GKE マイナー バージョン 1.22 以降: 再計算期間は、最大 300 HPA オブジェクトで 15 秒以内である必要があります。

次の要因もパフォーマンスに影響する可能性があります。

  • 複数の指標でのスケーリング: すべての指標で推奨事項を計算するためのフェッチ呼び出しが追加されるため、再計算時間に影響します。
  • カスタム指標スタックのレイテンシ: 約 50 ミリ秒を超えるレスポンス時間は、標準の Kubernetes 指標で通常観察されるよりも長く、再計算時間に影響します。

HorizontalPodAutoscaler オブジェクトの操作

ワークロードの HorizontalPodAutoscaler を構成し、自動スケーリング イベントとその原因に関する情報を取得するには、Google Cloud コンソールの [ワークロード] ページにアクセスします。

各 HorizontalPodAutoscaler は、クラスタ内に HorizontalPodAutoscaler オブジェクトとして存在します。これらのオブジェクトを操作するには、kubectl get hpa や kubectl describe hpa HPA_NAME などのコマンドを使用します。

また、HorizontalPodAutoscaler オブジェクトを作成するには、kubectl autoscale コマンドを使用します。

次のステップ