Kubernetesのオートスケーリングツールが競合する理由と、自律型ソリューションへの進化

現代のKubernetes環境における矛盾のジレンマ

サイト信頼性エンジニアリング（SRE）チームがアプリケーションの適切なサイズや実行に必要なレプリカ数について尋ねられると、設定ファイルは特定の回答を提示する一方で、稼働中のシステムは全く異なる現実を反映していることがよくあります。多くの場合、水平ポッドオートスケーラー（HPA）はCPU消費量に基づいてレプリカ数を増やそうとし、垂直ポッドオートスケーラー（VPA）はリソースが過剰にプロビジョニングされていると主張します。その一方で、KEDAのようなツールは外部キューの遅延を理由に追加のレプリカを要求し、Karpenterのようなノード管理ツールは実際の消費量ではなく宣言された要求に基づいて全く新しいインフラストラクチャをプロビジョニングします。

これらの矛盾した回答は、各コントローラーが論理的には正しく動作していても、互いに完全に隔離されているために発生します。これは、現代のKubernetes運用における根本的なアーキテクチャの欠陥を浮き彫りにしています。つまり、中央での調整なしに、同じAPIフィールドやノードサイズが同時に変更されているのです。

柔軟なシステムにおけるUNIX哲学の崩壊

Kubernetesのコンポーネントは、単一の機能を効率的に実行する小さく独立したツールを構築するという伝統的なUNIX哲学に基づいています。HPA、VPA、KEDA、Karpenter、およびGitOpsメディアはすべて、ワークロードのサイズに対する排他的な制御を前提とした独立した調整ループ内で動作します。しかし、ワークロードの容量を決定することは独立したプロセスではなく、相互に関連する数学的な方程式です。この方程式を分散した非同期のコントローラー間で断片化することは、標準的な効率性ではなく、絶え間ない振動を引き起こします。

スケーリングツール間の4つの競合パターン

相互に関連する変数が相互作用し、フィードバックループの特定の失敗パターンを引き起こします。

• 分母の崩壊（HPA対VPA）： VPAがCPU要求を削減すると、HPAの方程式における分母が小さくなります。その結果、トラフィックがわずかに急増しただけでHPAのしきい値を超え、過剰な数の小さなコンテナを生成する水平スケーリングプロセスがトリガーされます。
• マルチライター間の競合状態（HPA対KEDA）：** 両方のコントローラーが同じサブソースをターゲットにすることで、互いの効果を打ち消し合う連続的なスケールアップ・スケールダウンイベントが発生し、処理効率が阻害されます。
• 宣言型インフラストラクチャ（GitOps）との矛盾： 負荷のピーク時にHPAが動的に変更を行うと、アプリケーションの状態がGitリポジトリと同期しなくなり、ベースライン状態の誤ったリセットを招く恐れがあります。
• ノード層における増幅効果： Karpenterのようなツールは、実際の消費量ではなく宣言された要求に基づいてリソース割り当ての決定を行うため、クラウドコストの無駄を増幅させます。