本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.31：将 cgroup v1 支持移入维护模式
随着 Kubernetes 不断发展并适应容器编排领域的变化，社区决定在 v1.31 中将 cgroup v1 支持转入维护模式。这一转变与整个行业向 cgroup v2 的迁移保持一致，cgroup v2 提供了改进的功能：包括可扩展性和更一致的接口。在我们深入探讨这对 Kubernetes 的影响之前，让我们先回顾一下 cgroup 是什么以及它们在 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、无根（rootless）支持等。
鉴于这些优势，Kubernetes 也在采取行动，以更全面地拥抱 cgroup v2。然而，这一过渡需要谨慎处理，以避免中断现有的工作负载，并为用户提供平滑的迁移路径。
将 cgroup v1 支持转入维护模式
维护模式意味着什么？
当 Kubernetes 中的 cgroup v1 进入维护模式时，这意味着：
- 功能冻结：不会再为 cgroup v1 支持添加新功能。
- 安全修复：仍会提供关键的安全修复。
- 尽力而为的错误修复：如果可行，可能会修复重大错误，但某些问题可能仍未解决。
为什么要进入维护模式？
进入维护模式的动机是为了与更广泛的生态系统保持一致，并鼓励采用 cgroup v2，因为它提供了更好的性能、安全性和可用性。通过将 cgroup v1 过渡到维护模式，Kubernetes 可以专注于增强对 cgroup v2 的支持，并确保其满足现代工作负载的需求。需要注意的是，维护模式并不意味着弃用；cgroup v1 将根据需要继续接收关键的安全修复和重大错误修复。
这对集群管理员意味着什么
强烈建议当前依赖 cgroup v1 的用户规划向 cgroup v2 的过渡。这一过渡包括：
- 升级系统：确保底层的操作系统和容器运行时支持 cgroup v2。
- 测试工作负载：验证工作负载和应用程序在 cgroup v2 下能正常运行。