Kubernetes 1.31：对 cgroup v1 的支持转为维护模式
随着 Kubernetes 不断发展，为了适应容器编排全景图的变化，社区决定在 v1.31 中将对 cgroup v1 的支持转为维护模式。 这一转变与行业更广泛地向 cgroup v2 的迁移保持一致，后者的功能更强， 包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前， 先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。
理解 cgroup
控制组（Control Group）也称为 cgroup， 是 Linux 内核的一项特性，允许在进程之间分配、划分优先级、拒绝和管理系统资源（如 CPU、内存、磁盘 I/O 和网络带宽）。 这一功能对于维护系统性能至关重要，确保没有单个进程能够垄断系统资源，这在多租户环境中尤其重要。
cgroup 有两个版本： v1 和 v2。 虽然 cgroup v1 提供了足够的资源管理能力，但其局限性促使了 cgroup v2 的开发。 cgroup v2 在更好的资源控制特性之外提供了更统一且更一致的接口。
Kubernetes 中的 cgroup
对于 Linux 节点，Kubernetes 在管理和隔离 Pod 中运行的容器所消耗的资源方面高度依赖 cgroup。 Kubernetes 中的每个容器都放在其自己的 cgroup 中，这使得 Kubernetes 能够强制执行资源限制、 监控使用情况并确保所有容器之间的资源公平分配。
Kubernetes 如何使用 cgroup
- 资源分配
- 确保容器不超过其分配的 CPU 和内存限制。
- 隔离
- 将容器相互隔离，防止资源争用。
- 监控
- 跟踪每个容器的资源使用情况，以提供洞察数据和指标。
向 cgroup v2 过渡
Linux 社区一直在聚焦于为 cgroup v2 提供新特性和各项改进。 主要的 Linux 发行版和像 systemd 这样的项目正在过渡到 cgroup v2。 使用 cgroup v2 相较于使用 cgroup v1 提供了多个好处，例如统一的层次结构、改进的接口、更好的资源控制， 以及 cgroup 感知的 OOM 杀手、 非 root 支持等。
鉴于这些优势，Kubernetes 也正在更全面地转向 cgroup v2。然而， 这一过渡需要谨慎处理，以避免干扰现有的工作负载，并为用户提供平滑的迁移路径。
对 cgroup v1 的支持转入维护模式
维护模式意味着什么？
当 cgroup v1 在 Kubernetes 中被置于维护模式时，这意味着：
- 特性冻结：不会再向 cgroup v1 添加新特性。
- 安全修复：仍将提供关键的安全修复。
- 尽力而为的 Bug 修复：在可行的情况下可能会修复重大 Bug，但某些问题可能保持未解决。
为什么要转入维护模式？
转入维护模式的原因是为了与更广泛的生态体系保持一致，也为了鼓励采用 cgroup v2，后者提供了更好的性能、安全性和可用性。 通过将 cgroup v1 转入维护模式，Kubernetes 可以专注于增强对 cgroup v2 的支持，并确保其满足现代工作负载的需求。 需要注意的是，维护模式并不意味着弃用；cgroup v1 将继续按需进行关键的安全修复和重大 Bug 修复。
这对集群管理员意味着什么
目前强烈鼓励那些依赖 cgroup v1 的用户做好向 cgroup v2 过渡的计划。这一过渡涉及：
- 升级系统：确保底层操作系统和容器运行时支持 cgroup v2。
- 测试工作负载：验证工作负载和应用程序在 cgroup v2 下正常工作。