Windowsノードにおけるリソース管理

このページでは、LinuxとWindowsにおけるリソース管理の違いについて説明します。

Linuxノードでは、cgroups がリソース管理のPodの境界として使われています。 コンテナはネットワーク、プロセス、ファイルシステムが分離された境界内に作成されます。 Linux cgroup APIsを利用して、CPU, IO、メモリの統計情報を収集することが出来ます。

対照的に、Windows は、システム名前空間フィルターを使用してコンテナごとにjob objectを利用し、すべてのプロセスをコンテナ内に含めて、ホストからの論理的な分離を実現しています。 (JobオブジェクトはWindowsのプロセス分離のための機構であり、KubernetesのJobとは異なります。)

Windowsコンテナではネームスペースフィルタリングを行わずに実行する方法はありません。 つまり、システム権限はホストのコンテキストでは宣言することが出来ません。 そのため、Windows上で特権コンテナは利用出来ません。 Security Account Manager(SAM)が分離されているため、コンテナはホストからの認証情報を受け取ることはできません。

メモリ管理

WindowsではLinuxのようなOut-of-Memoryによるプロセスの終了は提供されていません。 Windowsではすべてのユーザモードでのメモリアロケーションを仮想的に取り扱います、そのためpagefilesが必ず必要になります。

Windowsノードではプロセスのメモリオーバコミットを行いません。 そのため、WindowsではプロセスはLinuxのようにメモリ不足状態になる事はなく、Out-Of-Memory(OOM)により終了するのではなくディスクへのページングを行います。 メモリが過剰に確保され物理メモリが使い果たされた場合に、ページングによりパフォーマンスが低下する可能性があります。

CPU管理

Windowsは様々なプロセスに割り当てるCPU時間を制限することは出来ますが、最小限のCPU時間を保証することは出来ません。

Windowsでは、 kubeletプロセスの --windows-priorityclass コマンドラインフラグによる scheduling priority の設定をサポートしています。 このフラグによりkubeletプロセスは同じWindowsホスト上で動作している他のプロセスと比べて多くのCPU時間のスライスを得ることが出来ます。 許容される値とその意味に関する詳細は Windows Priority Classes を参照して下さい。 実行中のPodによりkubeletのCPUサイクルが不足しないためには、このフラグを ABOVE_NORMAL_PRIORITY_CLASS 以上に設定して下さい。

リソースの予約

オペレーティングシステムやコンテナランタイム、kubeletのようなKubernetesのホストプロセスによって利用されるCPUやメモリを考慮するために、kubeletの --kube-reserved や --system-reserved フラグを利用して、リソースを予約することが出来ます（また、予約する必要もあります）。 Windowsではこれらの値はノードの allocatable リソースの計算のみに利用されます。

Windowsでは少なくとも2GiBのメモリを予約する事を推奨します。

どの程度、CPUを予約すればよいのか決定するには、各ノードでのPodの密度を特定し、ノードで実行されるシステムサービスのCPU利用率を監視し、ワークロードのニーズを満たす値を選択します。