Kubernetes 1.31：将 cgroup v1 支持迁移到维护模式
随着 Kubernetes 的不断发展和适应容器编排不断变化的环境，社区决定将 cgroup v1 支持在 v1.31 中转移到维护模式。这一转变与行业向 cgroup v2 更广泛的迁移保持一致，后者提供了改进的功能，包括可伸缩性和更一致的接口。在我们深入探讨对 Kubernetes 的影响之前，先回顾一下 cgroups 是什么以及它们在 Linux 中的重要性。
理解 cgroups
控制组 (cgroups) 是一项 Linux 内核特性，允许在进程之间分配、优先排序、拒绝和管理系统资源（如 CPU、内存、磁盘 I/O 和网络带宽）。此功能对于维护系统性能至关重要，并确保没有单个进程可以垄断系统资源，这在多租户环境中尤为重要。
cgroups 有两个版本：v1 和v2。虽然 cgroup v1 提供了足够的资源管理能力，但它存在一些限制，这导致了 cgroup v2 的开发。Cgroup v2 在更好的资源控制功能之上，提供了更统一和一致的接口。
Kubernetes 中的 cgroups
对于 Linux 节点，Kubernetes 严重依赖 cgroups 来管理和隔离在 Pod 中运行的容器所消耗的资源。Kubernetes 中的每个容器都被放置在其自己的 cgroup 中，这允许 Kubernetes 强制执行资源限制、监控使用情况，并确保所有容器之间的公平资源分配。
Kubernetes 如何使用 cgroups
- 资源分配
- 确保容器不超过其分配的 CPU 和内存限制。
- 隔离
- 将容器彼此隔离，以防止资源争用。
- 监控
- 跟踪每个容器的资源使用情况，以提供见解和指标。
过渡到 Cgroup v2
Linux 社区一直专注于 cgroup v2 的新功能和改进。主要的 Linux 发行版和像systemd 这样的项目正在向 cgroup v2 过渡。使用 cgroup v2 相比 cgroup v1 有许多优势，例如统一的层级结构、改进的接口、更好的资源控制、cgroup 感知的 OOM Killer、无 root 支持等。
鉴于这些优势，Kubernetes 也在朝着更全面地拥抱 cgroup v2 迈进。然而，这种过渡需要谨慎处理，以避免中断现有工作负载，并为用户提供平滑的迁移路径。
将 cgroup v1 支持转移到维护模式
维护模式意味着什么？
当 cgroup v1 在 Kubernetes 中被置于维护模式时，这意味着
- 功能冻结：不会向 cgroup v1 支持添加新功能。
- 安全修复：将继续提供关键安全修复。
- 尽力而为的 Bug 修复：如果可行，可能会修复主要 bug，但有些问题可能仍未解决。
为什么要转移到维护模式？
转移到维护模式是由与更广泛的生态系统保持一致并鼓励采用 cgroup v2 的需要驱动的，cgroup v2 提供了更好的性能、安全性和可用性。通过将 cgroup v1 过渡到维护模式，Kubernetes 可以专注于增强对 cgroup v2 的支持，并确保它满足现代工作负载的需求。需要注意的是，维护模式不意味着弃用；cgroup v1 将继续接收关键安全修复，并在需要时接收主要 bug 修复。
这对集群管理员意味着什么
强烈建议当前依赖 cgroup v1 的用户规划过渡到 cgroup v2。此过渡包括
- 升级系统：确保底层操作系统和容器运行时支持 cgroup v2。
- 测试工作负载：验证工作负载和应用在 cgroup v2 下正常运行。