本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 避免 OOM 错误
Windows没有像Linux那样有内存不足的进程杀手。Windows 始终将所有用户模式内存分配视为虚拟内存分配，并且页面文件是强制性的。最终结果是，Windows不会像Linux那样达到内存不足的状态。进程将分页到磁盘，而不是受到内存不足 (OOM) 终止的影响。如果内存过度配置且所有物理内存都耗尽，则分页可能会降低性能。
## 预留系统和 kubelet 内存
与 Linux 不同，后者为 kubelet、容器运行时等 kubernetes 系统守护程序`--kubelet-reserve`**捕获**资源预留；为 sshd、udev 等操作系统守护程序`--system-reserve`**捕获**资源预留。在 ** Windows 上，**这些标志不会**捕获**和**设置**节点上**运行的 ** kubelet ** 或**进程的内存限制。
但是，你可以组合这些标志**NodeAllocatable**来设法减少节点的容量，同时使用 Pod 清单**内存资源限制**来控制每个 Pod 的内存分配。使用这种策略，你可以更好地控制内存分配，并有一种机制可以最大限度地减少 Windows 节点上的内存不足 (OOM)。
在 Windows 节点上，最佳做法是为操作系统和进程预留至少 2GB 的内存。`--kubelet-reserve` and/or `--system-reserve`用于减少 NodeAllocatable。
按照[亚马逊 EKS Self-managed 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 容器内存要求
根据[微软文档](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/system-requirements)，NANO的Windows服务器基础映像至少需要30MB，而服务器核心需要45MB。随着您添加 Windows 组件（例如.NET 框架、作为 IIS 的 Web 服务和应用程序），这些数字也会增加。
你必须知道你的 Windows 容器镜像（即基础镜像及其应用层）所需的最低内存量，并在 pod 规范 resources/requests 中将其设置为容器。你还应该设置一个限制，以避免 pod 在应用程序出现问题时消耗所有可用的节点内存。
在下面的示例中，当 Kubernetes 调度器尝试将 pod 放置在节点上时，该 pod 的请求用于确定哪个节点有足够的资源可用于调度。
```
spec:
- name: iis
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
resources:
limits:
cpu: 1
memory: 800Mi
requests:
cpu: .1
memory: 128Mi
```
## 结论
使用这种方法可以最大限度地减少内存耗尽的风险，但不能防止内存耗尽的发生。使用亚马逊 CloudWatch 指标，您可以设置警报和补救措施，以防发生内存耗尽。