Kubernetes 1.31:对 cgroup v1 的支持转为维护模式

随着 Kubernetes 不断发展,为了适应容器编排全景图的变化,社区决定在 v1.31 中将对 cgroup v1 的支持转为维护模式。 这一转变与行业更广泛地向 cgroup v2 的迁移保持一致,后者的功能更强, 包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前, 先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。

理解 cgroup

控制组(Control Group)也称为 cgroup, 是 Linux 内核的一项特性,允许在进程之间分配、划分优先级、拒绝和管理系统资源(如 CPU、内存、磁盘 I/O 和网络带宽)。 这一功能对于维护系统性能至关重要,确保没有单个进程能够垄断系统资源,这在多租户环境中尤其重要。

cgroup 有两个版本: v1v2。 虽然 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 中被置于维护模式时,这意味着:

  1. 特性冻结:不会再向 cgroup v1 添加新特性。
  2. 安全修复:仍将提供关键的安全修复。
  3. 尽力而为的 Bug 修复:在可行的情况下可能会修复重大 Bug,但某些问题可能保持未解决。

为什么要转入维护模式?

转入维护模式的原因是为了与更广泛的生态体系保持一致,也为了鼓励采用 cgroup v2,后者提供了更好的性能、安全性和可用性。 通过将 cgroup v1 转入维护模式,Kubernetes 可以专注于增强对 cgroup v2 的支持,并确保其满足现代工作负载的需求。 需要注意的是,维护模式并不意味着弃用;cgroup v1 将继续按需进行关键的安全修复和重大 Bug 修复。

这对集群管理员意味着什么

目前强烈鼓励那些依赖 cgroup v1 的用户做好向 cgroup v2 过渡的计划。这一过渡涉及:

  1. 升级系统:确保底层操作系统和容器运行时支持 cgroup v2。
  2. 测试工作负载:验证工作负载和应用程序在 cgroup v2 下正常工作。

进一步阅读