Windows 节点的资源管理

本页面概述了 Linux 和 Windows 在资源管理方式上的差异。

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

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

Windows 容器运行时必须启用命名空间过滤。这意味着系统权限不能在主机的上下文中声明，因此特权容器在 Windows 上不可用。容器不能继承主机的身份，因为安全帐户管理器 (SAM) 是独立的。

内存管理

Windows 没有类似 Linux 的内存不足进程终止器。Windows 始终将所有用户模式内存分配视为虚拟内存，并且分页文件是强制性的。

Windows 节点不会对进程进行内存过量分配。其最终效果是 Windows 不会像 Linux 那样出现内存不足的情况，进程会分页到磁盘而不是因内存不足 (OOM) 而被终止。如果内存过度配置并且所有物理内存都已耗尽，分页可能会降低性能。

CPU 管理

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

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

资源预留

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

在 Windows 上，一个好的做法是预留至少 2GiB 的内存。

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