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