Windows 节点的资源管理

此页面概述了 Linux 和 Windows 之间资源管理方式的不同之处。

在 Linux 节点上，cgroups 用作资源控制的 Pod 边界。容器在该边界内创建，用于网络、进程和文件系统隔离。Linux cgroup API 可用于收集 CPU、I/O 和内存使用统计信息。

相反，Windows 为每个容器使用一个作业对象，并带有系统命名空间过滤器，以包含容器中的所有进程，并提供与主机之间的逻辑隔离。（作业对象是 Windows 进程隔离机制，与 Kubernetes 所指的Job 不同）。

没有办法在没有命名空间过滤的情况下运行 Windows 容器。这意味着系统权限不能在主机的上下文中断言，因此特权容器在 Windows 上不可用。容器无法从主机中获取身份，因为安全帐户管理器 (SAM) 是独立的。

内存管理

Windows 没有像 Linux 那样的内存不足进程杀手。Windows 始终将所有用户模式内存分配视为虚拟的，并且页面文件是强制性的。

Windows 节点不会为进程过度分配内存。最终结果是，Windows 不会像 Linux 那样达到内存不足的情况，而进程会换页到磁盘，而不是受到内存不足 (OOM) 终止的影响。如果过度配置内存并耗尽所有物理内存，则换页会降低性能。

CPU 管理

Windows 可以限制为不同进程分配的 CPU 时间量，但不能保证最少的 CPU 时间。

在 Windows 上，kubelet 支持一个命令行标志来设置 kubelet 进程的调度优先级：--windows-priorityclass。此标志允许 kubelet 进程与 Windows 主机上运行的其他进程相比获得更多 CPU 时间片。有关允许值及其含义的更多信息，请访问Windows 优先级类。为了确保运行的 Pod 不会使 kubelet 饿死 CPU 周期，请将此标志设置为 ABOVE_NORMAL_PRIORITY_CLASS 或更高。

资源预留

为了说明操作系统、容器运行时以及 kubelet 等 Kubernetes 主机进程使用的内存和 CPU，您可以（也应该）使用 --kube-reserved 和/或 --system-reserved kubelet 标志预留内存和 CPU 资源。在 Windows 上，这些值仅用于计算节点的可分配 资源。

在 Windows 上，最佳做法是预留至少 2GiB 的内存。

要确定预留多少 CPU，请确定每个节点的最大 Pod 密度，并监视运行在该节点上的系统服务的 CPU 使用率，然后选择一个满足工作负载需求的值。