Kubernetes の自動スケーリング — HPA から Karpenter
自動スケーリングは、Kubernetes でワークロードを実行する主な理由の 1 つです。トラフィックの増減に応じてリソースを手動で調整する代わりに、Kubernetes はさまざまなレベルで多くの自動スケーリング メカニズムを提供します。この記事では、従来の HPA から KEDA イベント駆動型スケーリング、最新のインプレース ポッド リソース更新、クラスター レベルのスケーリング用の Karpenter まで、自動スケーリング エコシステム全体について説明します。
1.水平ポッドオートスケーラー (HPA)
HPA は、最も一般的な水平スケーリング メカニズムです。メトリクスに基づいて Pod レプリカの数を自動的に増減します。
1.1 HPA (CPU およびメモリ付き)
コードブロック_0
重要な注意: 使用率を計算するには、HPA がコンテナに resources.requests を設定する必要があります。リクエストが設定されていない場合、HPA は「その数の 70%」を認識できません。
1.2 カスタム メトリクス API
HPA は、カスタム メトリック API (通常は Prometheus アダプターによって提供されます) を介して任意のメトリックにスケールできます:
コードブロック_1
1.3 スケールダウンクールダウン
スケールダウンのための
stabilizationWindowSeconds は運用環境では非常に重要です。設定が低すぎると、短期間のトラフィックのスパイクによってクラスターがスケールアップしてから継続的にスケールダウンする (フラッピング) ことが発生します。ベスト プラクティス:
- スケールアップ:
stabilizationWindowSeconds: 0から30— トラフィックの増加に対する迅速な対応__HTMLTAG_33___ - スケールダウン:
stabilizationWindowSeconds: 300から600— ポッドを減らす前に 5 ～ 10 分待ちます__HTMLTAG_39___
2.垂直ポッドオートスケーラー (VPA)
VPA は、実際の使用状況に基づいてコンテナの requests と limits を自動的に調整します。ポッドを追加するのではなく、各ポッドを「大きく」または「小さく」します。
コードブロック_2
2.1 VPA モード
- オフ: VPA は推奨事項を計算するだけであり、何も変更しません。 VPA Recommender からの提案を表示するために使用されます。
- 初期: VPA はポッドが新しく作成されるときにリソースを設定しますが、実行中のポッドは更新しません。
- 再作成: VPA はエビクトとポッドの再作成によって更新されます — 短いダウンタイムが発生します。
- Auto: 再作成と同様に機能するようになりました。将来的には、インプレース更新が使用される予定です。
2.2 VPA の推奨事項を表示
コードブロック_3
2.3 VPA の制限__HTMLTAG_74___
- 同じメトリックを持つ HPA と共存することはできません: HPA が CPU ごとにスケールする場合、VPA は同じデプロイメントの CPU を管理できません。ソリューション: HPA はカスタムメトリクスに従ってスケールし、VPA は CPU/メモリを管理します。または、VPA の代わりにインプレース更新を使用します。
- ポッドを再起動する必要があります: 再作成/自動モードでは、各 VPA 更新はポッドの再起動になります。ステートフル アプリには適していません。
- 別途インストールする必要があります: VPA は Kubernetes では使用できません。Helm またはマニフェスト経由でインストールする必要があります。
3.ポッドリソースのインプレース更新 (K8s 1.35 GA)
これは、最近の Kubernetes の最も重要な機能の 1 つです。再起動せずに、実行中のポッド の__HTMLTAG_92___resources.requests および resources.limits を変更できる機能です.
3.1 インプレース更新が重要な理由
以前は、リソースを変更するたびにポッドの再起動が必要でした。これは次の場合には受け入れられませんでした:
- データベース ポッド: PostgreSQL、MySQL は再起動後にキャッシュをウォームアップする必要があります
- _長時間実行される ML ジョブ: トレーニング ジョブには数時間かかり、再起動 = すべての進行状況が失われます
- ステートフル アプリケーション: メモリ内状態のアプリケーション
- JVM アプリケーション: Java アプリケーションには JIT ウォームアップ時間が必要
3.2 サイズ変更ポリシー
コードブロック_4
_restartPolicy:
- _必須ではありません: リソースはその場で変更でき、コンテナを再起動する必要はありません
- RestartContainer: リソースを変更すると、コンテナの再起動がトリガーされます (それでもポッド全体は再起動されません)
3.3 インプレースサイズ変更の実行
コードブロック_5
3.4 導入時のインプレースサイズ変更__HTMLTAG_140___
コードブロック_6
コードブロック_7
4. KEDA — Kubernetes イベント駆動型自動スケーリング
_KEDA は、Kubernetes のイベント駆動型自動スケーリングを提供する CNCF 段階的プロジェクトです。 HPA と比較した最大の違い: KEDA は__HTMLTAG_146___ゼロまでスケール できます — イベントがなければポッドは存在しません。
4.1 KEDA のインストール
コードブロック_8
4.2 ScaledObject — スケール展開
ScaledObject は KEDA の主要な CRD であり、デプロイメントおよび StatefulSet の HPA を置き換えます:
コードブロック_9
4.3 ScaledJob — スケール ジョブ
ScaledJob は、タスク キューに最適な、イベント バッチごとに新しいジョブを作成します:
コードブロック_10
4.4 人気の KEDA スケーラー__HTMLTAG_164___
コードブロック_11
4.5 KEDA ゼロへのスケールとゼロからのスケールアップ
ゼロへのスケールは KEDA のキラー機能です。24 時間 365 日実行されないワークロードの大幅なコスト削減:
コードブロック_12
KEDA がイベント (例: Kafka ラグ > 0) を検出すると、数秒で 0 から 1 にスケールします。その後、HPA (KEDA によって管理) は負荷に基づいてより高いスケールを続けます。
5.クラスター オートスケーラー
クラスター オートスケーラー (CA) は、ポッドをスケジュールできない (ノードがいっぱい) 場合、またはノードが空である (リソースの無駄) 場合に、ノードを自動的に追加/削除します。
コードブロック_13
6. Karpenter — 次世代のクラスター スケーリング
_Karpenter は、AWS のオープンソース ノード プロビジョナーであり、現在 Azure もサポートしています。これはクラスター オートスケーラーよりもはるかにスマートです。既存のノード グループを単にスケーリングするのではなく、Karpenter 自体が起動する最適なインスタンス タイプを決定します。
6.1 ノードプール — ノード グループを置き換えます
コードブロック_14
6.2 EC2NodeClass
コードブロック_15
6.3 Karpenter とクラスター オートスケーラー__HTMLTAG_188___
- 起動時間: Karpenter は約 60 秒、CA は約 3 ～ 4 分 (CA は ASG をスケールしてから待機する必要があります)
- インスタンスの選択: Karpenter は保留中の Pod に最適なインスタンス タイプを選択します。 CA は既存のグループのみをスケーリングします
- _スポット中断処理: ビルトイン Karpenter、インスタンスが終了する前の正常なドレイン
- ノードの統合: Karpenter は、Pod を削除してノードを終了することにより、空のノードまたは負荷の軽いノードを自動的に統合します__HTMLTAG_205___
- _コストの最適化: Karpenter は可能な場合はスポットを積極的に選択し、スポットが利用できない場合はオンデマンドにフォールバックします
6.4 スポット中断処理
コードブロック_16
7.組み合わせ戦略: HPA + KEDA + Karpenter
本番環境では、スケーリング レイヤーを一緒に使用することがよくあります:
- _KEDA: イベント (Kafka ラグ、キューの深さ) に基づいてポッドを 0 から N にスケールします
- HPA: KEDA がポッドを開始したときに CPU/メモリに基づいてスケーリングを微調整します
- インプレース更新: 再起動せずに実行中のポッドのリソースを調整
- Karpenter: ノード不足によりポッドをスケジュールできない場合、Karpenter は最適なノードを自動的にプロビジョニング__HTMLTAG_233___
コードブロック_17
効果的な自動スケーリングは、多くのメカニズムを適切に組み合わせたものです。各ツール (リソースベースのスケーリング用の HPA、イベント駆動型のスケーリング用の KEDA、ダウンタイムなしのリソース調整用のインプレース更新、インテリジェントなノード プロビジョニング用の Karpenter) を理解することは、応答性とコスト効率の両方を備えたシステムを構築するのに役立ちます。