翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
OOM エラーの回避
Windows には、Linux out-of-memoryのプロセスキラーはありません。Windows では、常にすべてのユーザーモードのメモリ割り当てが仮想として扱われ、ページファイルは必須です。最終的な効果は、Windows が Linux と同じようにメモリ不足状態にならないことです。プロセスは、メモリ不足 (OOM) の終了を受けるのではなく、ディスクにページングされます。メモリが過剰にプロビジョニングされ、すべての物理メモリが枯渇した場合、ページングによってパフォーマンスが低下する可能性があります。
システムと kubelet メモリの予約
kubelet、コンテナランタイムなどの kubernetes システムデーモンのリソース予約を--kubelet-reserveキャプチャし、sshd、udev などの OS システムデーモンのリソース予約を--system-reserveキャプチャする Linux とは異なります。Windows では、これらのフラグはノードで実行されている kubelet またはプロセスにメモリ制限をキャプチャして設定しません。
ただし、これらのフラグを組み合わせて NodeAllocatable を管理し、ポッドマニフェストのメモリリソース制限を使用してノードのキャパシティを減らし、ポッドごとのメモリ割り当てを制御することができます。この戦略を使用すると、メモリ割り当てをより適切に制御できるだけでなく、Windows ノードのout-of-memory (OOM) を最小限に抑えるメカニズムも利用できます。
Windows ノードでは、OS とプロセス用に少なくとも 2GB のメモリを予約するのがベストプラクティスです。--kubelet-reserve および/または --system-reserveを使用して NodeAllocatable を減らします。
Amazon EKS セルフマネージド Windows ノードのドキュメントに従って、CloudFormation テンプレートを使用して、kubelet 設定をカスタマイズした新しい Windows ノードグループを起動します。CloudFormation には、 と同じ BootstrapArguments という要素がありますKubeletExtraArgs。次のフラグと値で を使用します。
--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"eksctl がデプロイツールである場合は、次のドキュメントを参照して kubelet 設定をカスタマイズします。https://eksctl.io/usage/customizing-the-kubelet/
Windows コンテナのメモリ要件
Microsoft のドキュメント
Windows コンテナイメージに必要な最小メモリ量、つまりベースイメージとそのアプリケーションレイヤーを把握し、ポッド仕様でコンテナのリソース/リクエストとして設定することが不可欠です。また、アプリケーションの問題が発生した場合にポッドが使用可能なすべてのノードメモリを消費しないように制限を設定する必要があります。
以下の例では、Kubernetes スケジューラがノードにポッドを配置しようとすると、ポッドのリクエストを使用して、スケジューリングに十分なリソースがあるノードが決定されます。
spec:
- name: iis
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
resources:
limits:
cpu: 1
memory: 800Mi
requests:
cpu: .1
memory: 128Mi結論
このアプローチを使用すると、メモリが枯渇するリスクは最小限に抑えられますが、それを防ぐことはできません。Amazon CloudWatch Metrics を使用すると、メモリが枯渇した場合のアラートと修復を設定できます。
