Kubernetes コントロールプレーンのスケーリングを制限する3つの異なるボトルネック

Kubernetes のスケーリング課題は、しばしば単純なノード数上限の問題と誤解されがちですが、最近の分析では、チャーン、状態、ノード容量という3つの明確な障害モードが存在することが明らかになっています。クラスターが5,000ノードを超えたり、エージェントによる負荷の高いワークロードを処理したりする場合、API サーバーの標準的な水平スケーリングはメモリ圧力を緩和するどころか、むしろ悪化させる可能性があります。これらの特定のボトルネックを理解することで、インフラチームは上流コンポーネント（stock upstream components）を活用し、的確なアーキテクチャ修正を適用できます。

何が起きたか

多くのエンジニアリングチームは、Kubernetes コントロールプレーンのスケーリングを、API サーバーを追加することで解決できる線形の問題だと考えています。しかし、実際の運用環境にあるクラスターでは、根本的なボトルネックがリクエスト量ではなく、メモリ常駐性や書き込み強度である場合、このアプローチはしばしば失敗します。例えば、あるトレーニング用フリートは数千ノードで安定して動作していましたが、15,000ノードへ拡張した際に etcd のエラーや API サーバーのメモリ枯渇を引き起こしました。対照的に、数千ノードしか持たないエージェントプラットフォームでも、毎分数千回のオブジェクト遷移が発生し、ノード数に関係なくコントロールプレーンを圧倒する「書き込みストーム」が生じることがあります。

もう一つのシナリオは、数百個のオペレーターと数万個の静的オブジェクトを持つプラットフォームクラスターです。ここでは問題はアクティビティではなく「状態」にあります。すべての API サーバーは、その watch キャッシュに全オブジェクトのコピーを保持しています。このような状況で API サーバーを増やすと、キャッシュ全体が複製され、パフォーマンス向上なしにメモリ使用量が増加します。これら3つのシナリオ——ノードバウンド、チャーンバウンド、ステートバウンド——はそれぞれ異なる解決策を必要としますが、公開されているガイダンスの多くは5,000ノードまでのノード数にのみ焦点を当てています。

大規模または複雑なクラスターに対する戦略のドキュメント不足により、チームは逆効果な変更を行ってしまいます。ステートバウンドのクラスターに API サーバーを追加すると、各新規インスタンスが完全な watch キャッシュを複製するため、メモリ圧力が高まります。解決策はカスタムフォークではなく、Kubernetes アーキテクチャの「シーム」、つまりコンポーネントを分離し、特定の種類の負荷に対応するために独立して設定できるポイントを理解することにあります。

仕組み

Kubernetes のスケーラビリティは、コンポーネント間の置換ポイントである4つのアーキテクチャ上の「シーム」によって制約されています。最初のシームは「ストレージ」であり、どのリソースタイプをどのバックエンドで保持するかを決定します。すべてのデータに同じ耐久性が必要ではありません。ノードリースやイベントなどの一時的な項目は、プライマリ etcd クラスターからルーティングを外すことで、書き込み負荷を軽減できます。2番目のシームは「ノードの生存確認（liveness）」であり、ハートビートデータがどのようにコントロールプレーンに届くかを扱います。ノード向けティアでリース更新を吸収したり、etcd でインメモリのリースリフレッシュを使用したりすることで、数千個の kubelet が生成する書き込み QPS を大幅に削減できます。

3番目のシームは「シャーディング」であり、オブジェクトがコントローラーやキャッシュ間でどのように分割されるかを定義します。レイヤー間でシャーディング軸の合意が得られない場合、コントローラーは自身のスコープ外のオブジェクトを取得するためにリソースを無駄遣いします。4番目のシームは「キャッシュ常駐性」であり、API サーバーがメモリ内に何を保持するかを制御します。ステートバウンドのクラスターでは、すべての API サーバーがすべてのオブジェクトをキャッシュするため問題を抱えます。キャッシュ内容を特定のシャードやロールに関連するオブジェクトのみに制限することで、メモリ使用量を大幅に削減できますが、RBAC オブジェクトに関する一定のベースラインオーバーヘッドは避けられません。

主要な詳細

• ノードバウンドのクラスター は kubelet のハートビートによって制限されます。大規模環境では、リース更新が書き込み QPS の約70%を占めます。
• チャーンバウンドのクラスター は、ノード数とは無関係に、エージェントセッションなど短命のカスタムリソースからの高い書き込みレートに直面します。
• ステートバウンドのクラスター はメモリ使用量によって制約されます。各 API サーバーが数万個のオブジェクトからなる完全な watch キャッシュを複製するためです。
• KEP-4743 はストレージインターフェースの境界を定義し、--etcd-servers-overrides を介してリソースタイプを異なるバックエンドへルーティングできるようにします。
• KEP-5866 は API トラフィックに対するハッシュレンジフィルタリングを導入し、コントローラーとキャッシュ間での整合性のあるシャーディングの基盤を提供します。
• Role-Split 構成 は、API 提供、スケジューリング、etcd 用にマシンプールを分離し、最大20,000ノードまでのスケーリングを可能にします。

なぜ重要なのか

ソフトウェアエンジニアやインフラリーダーにとって、具体的なスケーリング制限の種類を認識することは、コストのかかる誤設定を避けるために極めて重要です。チャーンバウンドのエージェントプラットフォームをノードバウンドの問題として扱うと、etcd 内の書き込みボトルネックを無視したまま計算リソースを過剰にプロビジョニングすることになります。同様に、ステートバウンドのプラットフォームクラスターに API サーバーを追加しても、レイテンシは改善せず、メモリコストが増加するだけです。クラスターがノードハートビート、オブジェクトチャーン、それとも状態常駐性によって制限されているかを特定することで、チームは力技のスケーリングではなく、精密な修正を適用できます。

これらの知見は、文書化されていないフォークに頼るのではなく、意図的な設定とともに上流コンポーネント（stock upstream components）を使用することの重要性も浮き彫りにします。提案されている「レシピラダー」は、クラシックな高可用性セットアップからパーティショニングされたストアやシャーディングされたスライスへの移行パスを提供しており、すべて継続的インテグレーション（CI）でテストされています。このアプローチにより、スケーリング戦略が Kubernetes リリースを通じて有効であることを保証し、設定失敗が本番環境ではなく CI パイプラインの早期段階で検出されるようにします。

実行できること

• 書き込み QPS のソースを分析し、ノードリース、カスタムリソースのチャーン、静的オブジェクトの状態を区別することで、クラスターの主要なボトルネックを特定してください。
• Role-Split 構成を実装し、最大20,000ノードのクラスターにおいて、API 提供、スケジューリング、etcd を専用のマシンプールに分離してください。
• --etcd-servers-overrides を使用して、イベントやリースなどの一時的なリソースを別のバックエンドへルーティングし、プライマリ etcd クラスターへの負荷を軽減してください。
• ノード向けティアの評価を行い、リース更新を吸収させ、実際の状態遷移のみを伝播させることで、コントロールプレーンへの書き込み負担を低減してください。
• SIG API Machinery にチャーンバウンドのクラスターからの実世界の書き込みレートデータを貢献し、CRD ごとのストレージ設定に対する将来のサポート形成を支援してください。
• KEP-5866 およびキャッシュ常駐性拡張のプロトタイプブランチを確認し、今後のシャーディングおよびメモリ最適化機能に備えてください。