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 下正常工作。