翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# OOM エラーの回避
<a name="windows-oom"></a>

Windows には、Linux out-of-memoryのプロセスキラーはありません。Windows は常にすべてのユーザーモードのメモリ割り当てを仮想として扱い、ページファイルは必須です。最終的な効果は、Windows が Linux と同じようにメモリ不足状態にならないことです。プロセスは、メモリ不足 (OOM) の終了ではなく、ディスクにページングされます。メモリが過剰にプロビジョニングされ、すべての物理メモリが枯渇した場合、ページングによってパフォーマンスが低下する可能性があります。

## システムと kubelet メモリの予約
<a name="_reserving_system_and_kubelet_memory"></a>

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 ノード](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)ドキュメントに従って、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 コンテナのメモリ要件
<a name="_windows_container_memory_requirements"></a>

[Microsoft のドキュメント](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/system-requirements)によると、NANO 用の Windows Server ベースイメージには少なくとも 30MB が必要ですが、Server Core には 45MB が必要です。これらの数は、.NET Framework、Web Services as IIS、アプリケーションなどの Windows コンポーネントを追加するにつれて増加します。

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
```

## 結論
<a name="_conclusion"></a>

このアプローチを使用すると、メモリが枯渇するリスクは最小限に抑えられますが、それを防ぐことはできません。Amazon CloudWatch Metrics を使用すると、メモリが枯渇した場合のアラートと修復を設定できます。