Kubernetes v1.34、ノードスワップ対応でAIワークロードの高密度実行を実現

スワップを有効にしたノードでの実行をサポートするKubernetesの機能は、バージョン1.34で一般提供（GA）段階に到達しました。このアップデートにより、クラスタオペレーターは高速なローカルストレージを利用してメモリのオーバーフローに対処できるようになり、大量のRAMを消費しながらも多くの時間をアイドル状態で過ごす現代的なエージェント型AIワークロードにおける重要なボトルネックが解消されます。

何が起きたのか

Kubernetesクラスタにおいて、メモリ容量はしばしば最初に直面するハードな制限となります。CPUリソースが完全に使い切られる前に、物理RAMが枯渇してしまうケースが多く見られます。この制約は、初期化や信頼できないコードの実行のために substantial なメモリフットプリントを必要とするエージェント型AIワークロードの増加に伴い、より深刻になっています。これらのエージェントは初期の活動バーストの後、ユーザーからのプロンプトを待って長い間アイドル状態に入ることがよくあります。この休眠状態を高価な物理RAMに保持し続けると、単一ノードでホストできるPod数が制限され、インフラコストが増大します。

Kubernetes v1.34のリリースは、ノードスワップを公式にサポートすることでこの状況を変えます。Linuxカーネルが匿名メモリをディスクへページアウトすることを可能にすることで、スワップはトラフィックスパイク時やメモリ過剰割り当てが激しい期間におけるバッファとして機能します。高速なNVMeソリッドステートドライブ（SSD）をバックエンドに使用すれば、ノードは休眠中のメモリページをオフロードし、各マシン上に大幅に多くのPodを詰め込むことができます。ベンチマークによると、この手法により最大3倍の密度向上が得られ、レイテンシへの影響は最小限であることが示されています。

歴史的に、Kubernetes環境ではスワップは主に2つの理由から推奨されていませんでした。第一に、cgroup v1下でのメモリ会計ではメモリとスワップが結合された制限として扱われるため、コンテナの実メモリ使用量を分離して予測することが困難でした。第二に、従来の回転式ディスクへのページングは深刻なレイテンシペナルティをもたらしていました。新しいサポートは個別のスワップ会計を提供するcgroup v2に依存しており、高速なNVMeストレージと組み合わせることでレイテンシの問題を緩和し、本番環境での実用的な利用を可能にしています。

仕組み

ノードスワップは、オペレーティングシステムが非アクティブなメモリページをRAMからディスク上の指定されたスワップスペースへ移動することによって機能します。Kubernetes v1.34では、これはkubelet設定を通じて管理されます。オペレーターは failSwapOn を false に設定し、swapBehavior を LimitedSwap に定義します。この設定により、ノードはプライマリメモリとしてスワップに依存するのではなく、必要に応じてのみスワップを使用するようになります。

このメカニズムの有効性は、基盤となるストレージの速度に大きく依存します。スワップをLocal SSDへルーティングすることで、ページングに関連するI/O待ち時間は劇的に短縮されます。この構成は、コンテナのメモリ上限（limit）が要求量（request）よりも高く設定されるBurstable Quality of Service (QoS) クラスで最も効果的です。ノードはその後、アイドルアプリケーションのメモリ使用量に基づいて自動的にスワップスペースを配分し、アクティブなプロセスは高速な物理RAMに保持しつつ、休眠データをディスクへ移動させます。

主要な詳細

• Kubernetes v1.34は、ノードスワップサポートの一般提供（GA）を示すマイルストーンです。
• この機能には、独立したスワップ会計と分離のためのcgroup v2が必要です。
• ベンチマークでは、LinuxカーネルビルドのRAMフットプリントが600 MBから300 MBへと50%削減されることが確認されました。
• gVisorを使用するヘッドレスChrome Podでは、同時実行Pod数が80から160へと100%の密度向上が見られました。
• 隔離されたPythonサンドボックスでは、同時セッション数が80から240へと200%の密度改善が達成されました。
• ピーク密度時のレイテンシ増加は、主にスワップI/OではなくCPU競合によって引き起こされています。

なぜ重要なのか

AIエージェントやCI/CDパイプライン向けのプラットフォームを構築するエンジニアにとって、この開発はインフラコストを削減するための直接的な道を提供します。エージェント型ワークロードは本質的にバースト性があり、初期化とコード実行時にスパイクし、その後はアイドル状態が続きます。スワップがない場合、オペレーターはピークに対応できるだけのRAMをプロビジョニングする必要があり、アイドル期間中にその大半が無駄になります。ノードスワップにより、チームはアクティブな使用に対するメモリ要求を適正サイズに調整しつつ、バーストに対する保険としてディスクスペースを利用できます。

これはセキュリティアーキテクチャにも影響を与えます。gVisorやKata Containersのような安全な実行環境は、分離要件のためにメモリオーバーヘッドを追加します。従来、このオーバーヘッドは厳密にPod密度を制限していました。ノードスワップがあれば、これらの安全なランタイムによる追加のメモリコストは、アクティブに使用されていない際にページアウトできます。つまり、チームは信頼できないコードに対して厳格なセキュリティ境界を維持しつつ、高密度スケジューリングによる経済的メリットを犠牲にせずに済むということです。

実施可能なこと

• GA版のノードスワップ機能にアクセスするために、Kubernetesクラスタをバージョン1.34以降へアップグレードしてください。
• kubeletを failSwapOn: false および memorySwap.swapBehavior: LimitedSwap で設定してください。
• スワップレイテンシを最小化するために、ノードに高速なNVMe Local SSDを搭載していることを確認してください。
• Burstable QoS動作を有効にするために、コンテナのメモリ上限（limit）を要求量（request）より高く設定してください。
• RAMとスワップスペースの最適な比率を決定するために、特定のワークロードでベンチマークを実行してください。
• 高密度時にはスワップI/Oよりも先にCPU競合が主なボトルネックになるため、これを監視してください。