そのKubernetesノードプール戦略、保存する前にもう古い

手動のノードプール管理が破綻するのは、podリクエスト、オートスケーラーの挙動、spot中断の変化が、どんなスプレッドシートの更新よりも速いからです。3つの要因が、この計算を成り立たなくしています。

第一に、podリクエストがドリフトします。開発チームは1日に何度もデプロイします。ロールアウトのたびにCPUとメモリのリクエストが変わり得ます。意図的な場合もあれば、ベースイメージ更新に伴って偶発的に起きる場合もあります。スプレッドシートはpodが500m CPUを必要とする前提でした。昨日のリリースで750mに上がりました。シートには誰も伝えていません。

第二に、オートスケーラーがリアルタイムでクラスターを組み替えます。KarpenterとCluster Autoscalerは、現在のペンディングpod、ビンパッキング制約、可用性に基づいてインスタンスタイプを選びます。「m6i.2xlargeを12ノード運用中」という計画は、ある一瞬のスナップショットに過ぎません。1時間後には8台のc7i.xlargeと4台のr7i.largeになっているかもしれず、どちらもその瞬間のワークロードには正しい構成です。

第三に、spot中断が毎週のように前提を崩します。AWSがノードを回収し、Karpenterが別のインスタンスファミリーに差し替え、想定していたトポロジーはもう存在しません。「このファミリーは70%がspot」という前提でコストモデルを組んでいるなら、それは当て推量です。

FinOps Foundationもこの点を明言しています。テクノロジー領域の広がりつつある部分では、静的な長期計画よりもアジャイルで反復的な計画が推奨されるのです。ノードトポロジーは、まさにその中核に位置します。

ノードのライトサイジングは、クラスターに適したインスタンスファミリーとサイズを選ぶことです。podのライトサイジングは、各ワークロードに適したCPUとメモリのリクエストを設定することです。両者は別々の問題として扱われがちで、だからこそ両方が誤ったままになりがちです。

podリクエストがノード選択を左右する

podリクエストが膨らんでいれば、スケジューラはそれを収めるために大きなノードを必要とします。結果として、どのワークロードも使わない余剰にお金を払うことになります。リクエストを実使用量に合わせて絞れば、同じワークロードが突然、より小さく安いノードに収まります。変えるべきはノードプールではなく、podだったのです。

ノード選択がpodの性能を左右する

メモリバウンドなJavaサービスをコンピュート最適化のインスタンスファミリーで動かせば、JVMヒープをどれだけ丁寧にチューニングしてもOOMKillと戦うことになります。コンテナイメージを確認せずにARMベースのインスタンスを選べば、podの半分はスケジュールされません。ノードファミリーはコストだけでなく、性能の意思決定でもあるのです。

2つではなく、1つのループ

どちらの問題も単独では解けません。PerfectScaleはワークロードの挙動とノードトポロジーを一体で分析し、podの再起動なしに変更を適用します。この最後の点が肝心です。Vertical Pod Autoscalerはリクエストを変更するためにpodを再起動しますが、これはステートレスなワークロードなら問題なくても、それ以外では厄介です。再起動を必要としない継続的なライトサイジングこそが、ダッシュボードや手動レビューでは開いたままのループを閉じます。

インスタンスファミリーの選択が実際のワークロードに与える影響については、nodepool selection strategiesでトレードオフを詳しく解説しています。

プラットフォームエンジニアは、分析ループを自動化し、ワークロードを運用するEngineersに説明責任を委ねることでKubernetesノードプールを計画します。これは中央集権的なスプレッドシート管理から分散型の意思決定へのシフトであり、使用量とコストの説明責任をエッジに寄せるというFinOpsの原則そのものです。

実現に向けた実践的な打ち手はいくつかあります。

• まず計測、次に判断。 pod単位の使用量データ、ノード使用率、トポロジー履歴を一箇所に集約する必要があります。データが3つのツールに分散していれば、名前を変えただけのスプレッドシートに逆戻りです。
• 推奨事項を担当者に紐付ける。 名前のついていない推奨は誰の仕事にもなりません。ワークロード別のライトサイジング提案を、そのワークロードを所有する開発チームに提示できるプラットフォームチームほど、採用が早く進みます。
• 安全なものは自動化する。 安定していて挙動が把握できているワークロードのライトサイジングに、人の手は不要です。人的レビューは、SLAが厳しいものや異例のパターンを持つワークロードに絞りましょう。
• SLA制約を尊重する。 平均値しか見ないML主導のライトサイジングは、p99を過小プロビジョニングします。時点スナップショットではなく、時系列でワークロード挙動をモデル化する分析を選びましょう。

Paramount PicturesはPerfectScale導入後、レジリエンス関連の問題を90%削減しました。その大部分は、これまでプラットフォームエンジニアリングの時間を奪っていた手作業を排除したことによるものです。これがスプレッドシート主導の計画から継続的ループへ移行した実務的な成果です。

これから体制を整えるチームには、Kubernetesクラスターを無駄なく保つ究極ガイドで、これを機能させる運用習慣を解説しています。

ダッシュボードは、何が起きたかを見せてくれます。Vertical Pod Autoscalerはpodリクエストを変更しますが、そのためにpodを再起動します。継続的最適化は、分析を行い、再起動なしに変更を適用します。これはツールとしてカテゴリが違います。

実務上の違いはこうです。ダッシュボードは「ノードグループXは使用率40%」と教えてくれます。結構。ここから誰かが対処を決め、ワークロードを所有するチームと調整し、変更ウィンドウを確保し、スプレッドシートを更新しなければなりません。これは手間仕事で、運用中のワークロード数に比例して線形に増えます。

VPAはpodリクエストを自動調整することで一部を解決しますが、ノードトポロジーを認識しておらず、変更を適用するためにpodを再起動します。ステートフルなサービスや長時間動作のバッチジョブでは、その再起動コストは無視できません。

PerfectScaleはEKS、GKE、AKS、そしてセルフマネージドクラスターで継続的に稼働し、helm chartの変更もコード修正も不要です。セットアップから最初の推奨までは5分未満。分析はpodの挙動、ノードトポロジー、SLA制約を一体で考慮し、変更はpodの再起動なしに適用されます。500以上の本番クラスターで、各チームは約40%のコスト削減と、リソース起因インシデントの60%削減を実現しています。

これがシフトです。「はい、ダッシュボードです。あとは頑張って」から、「ループは回っています。変更をレビューしてください」へ。