本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 避免 OOM 错误
Windows 不像 Linux 那样有 out-of-memory进程杀手。Windows 始终将所有用户模式的内存分配视为虚拟内存分配，并且页面文件是必需的。最终效果是，Windows不会像Linux那样达到内存不足的情况。进程将分页到磁盘，而不是受到内存不足 (OOM) 终止的影响。如果内存过度配置且所有物理内存耗尽，则分页可能会降低性能。
## 预留系统和 kubelet 内存
与 Linux 不同，后者为 kubernetes 系统守护程序（例如 kubelet、容器运行时等）`--kubelet-reserve`**捕**获资源预留；为 sshd、udev 等操作系统守护程序`--system-reserve`**捕获**资源预留。在 **Windows** 上，这些标志不会**捕获**和**设置** **kubelet** 或节点上运行的**进程**的内存限制。
但是，你可以将这些标志组合起来，设法**NodeAllocatable**减少节点的容量，同时使用 Pod 清单**内存资源限制**来控制每个 Pod 的内存分配。使用这种策略，您可以更好地控制内存分配，并可以在 Windows 节点上使用最小化 out-of-memory (OOM) 的机制。
在 Windows 节点上，最佳做法是为操作系统和进程预留至少 2GB 的内存。`--kubelet-reserve` and/or `--system-reserve`用于减少 NodeAllocatable。
按照 [Amazon EKS 自托管 Windows 节点](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)文档，使用 CloudFormation 模板启动一个新的 Windows 节点组，并对 kubelet 配置进行了自定义。 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 Server基础映像至少需要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
```
## 结论
使用这种方法可以最大限度地降低内存耗尽的风险，但不能防止内存耗尽的发生。使用 Amazon CloudWatch Metrics，您可以设置警报和补救措施，以防出现内存耗尽的情况。