适用于 Windows 节点的资源管理

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

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

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

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

内存管理

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

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

CPU 管理

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

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

资源预留

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

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

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