diff --git a/content/zh-cn/blog/_posts/2024-08-14-moving-cgroup-v1-support-maintenance-mode-kubernetes-1-31.md b/content/zh-cn/blog/_posts/2024-08-14-moving-cgroup-v1-support-maintenance-mode-kubernetes-1-31.md new file mode 100644 index 0000000000000..ce0462adc2810 --- /dev/null +++ b/content/zh-cn/blog/_posts/2024-08-14-moving-cgroup-v1-support-maintenance-mode-kubernetes-1-31.md @@ -0,0 +1,198 @@ +--- +layout: blog +title: "Kubernetes 1.31:对 cgroup v1 的支持转为维护模式" +date: 2024-08-14 +slug: kubernetes-1-31-moving-cgroup-v1-support-maintenance-mode +author: Harshal Patil +translator: > + [Michael Yao](https://github.com/windsonsea) (DaoCloud) +--- + + + +随着 Kubernetes 不断发展,为了适应容器编排全景图的变化,社区决定在 v1.31 中将对 cgroup v1 +的支持转为[维护模式](#what-does-maintenance-mode-mean)。 +这一转变与行业更广泛地向 cgroup v2 的迁移保持一致,后者的功能更强, +包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前, +先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。 + + +## 理解 cgroup {#understanding-cgroups} + +[控制组(Control Group)](https://man7.org/linux/man-pages/man7/cgroups.7.html)也称为 cgroup, +是 Linux 内核的一项特性,允许在进程之间分配、划分优先级、拒绝和管理系统资源(如 CPU、内存、磁盘 I/O 和网络带宽)。 +这一功能对于维护系统性能至关重要,确保没有单个进程能够垄断系统资源,这在多租户环境中尤其重要。 + + +cgroup 有两个版本: +[v1](https://docs.kernel.org/admin-guide/cgroup-v1/index.html) 和 +[v2](https://docs.kernel.org/admin-guide/cgroup-v2.html)。 +虽然 cgroup v1 提供了足够的资源管理能力,但其局限性促使了 cgroup v2 的开发。 +cgroup v2 在更好的资源控制特性之外提供了更统一且更一致的接口。 + + +## Kubernetes 中的 cgroup + +对于 Linux 节点,Kubernetes 在管理和隔离 Pod 中运行的容器所消耗的资源方面高度依赖 cgroup。 +Kubernetes 中的每个容器都放在其自己的 cgroup 中,这使得 Kubernetes 能够强制执行资源限制、 +监控使用情况并确保所有容器之间的资源公平分配。 + + +### Kubernetes 如何使用 cgroup {#how-kubernetes-uses-cgroups} + +**资源分配** +: 确保容器不超过其分配的 CPU 和内存限制。 + +**隔离** +: 将容器相互隔离,防止资源争用。 + +**监控** +: 跟踪每个容器的资源使用情况,以提供洞察数据和指标。 + + +## 向 cgroup v2 过渡 {#transitioning-to-cgroup-v2} + +Linux 社区一直在聚焦于为 cgroup v2 提供新特性和各项改进。 +主要的 Linux 发行版和像 [systemd](https://systemd.io/) +这样的项目正在[过渡](https://github.com/systemd/systemd/issues/30852)到 cgroup v2。 +使用 cgroup v2 相较于使用 cgroup v1 提供了多个好处,例如统一的层次结构、改进的接口、更好的资源控制, +以及 [cgroup 感知的 OOM 杀手](https://github.com/kubernetes/kubernetes/pull/117793)、 +[非 root 支持](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless/README.md#cgroup)等。 + + +鉴于这些优势,Kubernetes 也正在更全面地转向 cgroup v2。然而, +这一过渡需要谨慎处理,以避免干扰现有的工作负载,并为用户提供平滑的迁移路径。 + +## 对 cgroup v1 的支持转入维护模式 {#moving-cgroup-v1-support-into-maintenance-mode} + +### 维护模式意味着什么? {#what-does-maintenance-mode-mean} + +当 cgroup v1 在 Kubernetes 中被置于维护模式时,这意味着: + + +1. **特性冻结**:不会再向 cgroup v1 添加新特性。 +2. **安全修复**:仍将提供关键的安全修复。 +3. **尽力而为的 Bug 修复**:在可行的情况下可能会修复重大 Bug,但某些问题可能保持未解决。 + + +### 为什么要转入维护模式? {#why-move-to-maintenance-mode} + +转入维护模式的原因是为了与更广泛的生态体系保持一致,也为了鼓励采用 cgroup v2,后者提供了更好的性能、安全性和可用性。 +通过将 cgroup v1 转入维护模式,Kubernetes 可以专注于增强对 cgroup v2 的支持,并确保其满足现代工作负载的需求。 +需要注意的是,维护模式并不意味着弃用;cgroup v1 将继续按需进行关键的安全修复和重大 Bug 修复。 + + +## 这对集群管理员意味着什么 {#what-this-means-for-cluster-administrators} + +目前强烈鼓励那些依赖 cgroup v1 的用户做好向 cgroup v2 过渡的计划。这一过渡涉及: + +1. **升级系统**:确保底层操作系统和容器运行时支持 cgroup v2。 +2. **测试工作负载**:验证工作负载和应用程序在 cgroup v2 下正常工作。 + + +## 进一步阅读 {#further-reading} + +- [Linux cgroup](https://man7.org/linux/man-pages/man7/cgroups.7.html) +- [Kubernetes 中的 cgroup v2](/zh-cn/docs/concepts/architecture/cgroups/) +- [Kubernetes 1.25:cgroup v2 进阶至 GA](/zh-cn/blog/2022/08/31/cgroupv2-ga-1-25/)