Kubernetes v1.35 抢先一览

作者 Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao | 译者 Wenjun Lou |

随着 Kubernetes v1.35 发布的临近，Kubernetes 项目持续演进。 为了改善项目的整体健康状况，某些功能可能会被弃用、移除或替换。 本博客文章概述了 v1.35 版本的计划变更， 发布团队认为你应该了解这些变更，以确保 Kubernetes 集群的持续平稳运行， 并让你了解最新进展。 以下信息基于 v1.35 版本的当前状态，在最终发布日期之前可能会发生变化。

Kubernetes v1.35 的弃用和移除

cgroup v1 支持

在 Linux 节点上，容器运行时通常依赖于 cgroups（"control groups" 的缩写）。 自 v1.25 以来，Kubernetes 中对 cgroup v2 的支持已经稳定， 为原有的 v1 cgroup 支持提供了替代方案。 虽然 cgroup v1 提供了初始的资源控制机制， 但它存在众所周知的不一致性和局限性。 添加对 cgroup v2 的支持允许使用统一的控制组层次结构， 改善了资源隔离，并为现代功能奠定了基础， 使得传统的 cgroup v1 支持可以准备移除。 移除 cgroup v1 支持只会影响在不支持 cgroup v2 的旧版 Linux 发行版上运行节点的集群管理员； 在这些节点上，kubelet 将无法启动。 管理员必须将其节点迁移到启用了 cgroup v2 的系统。 关于兼容性要求的更多详细信息将在 v1.35 发布后不久在博客文章中提供。

要了解更多信息，请阅读关于 cgroup v2； 你也可以通过 KEP-5573：移除 cgroup v1 支持 跟踪切换工作。

kube-proxy 中 ipvs 模式的弃用

许多版本之前，Kubernetes 项目在 kube-proxy 中实现了 ipvs 模式。 它被采用作为一种提供高性能服务负载均衡的方式， 性能优于现有的 iptables 模式。 然而，由于技术复杂性和需求分歧， 在 ipvs 和其他 kube-proxy 模式之间保持功能对等变得困难。 这造成了重大的技术债务，并使 ipvs 后端难以与更新的网络功能一起支持。

Kubernetes 项目计划在 v1.35 版本中弃用 kube-proxy ipvs 模式， 以简化 kube-proxy 代码库。 对于 Linux 节点，推荐的 kube-proxy 模式已经是 nftables。

你可以在 KEP-5495：弃用 kube-proxy 中的 ipvs 模式 中找到更多信息。

Kubernetes 正在弃用 containerd v1.y 支持

虽然 Kubernetes v1.35 仍然支持 containerd 1.7 和其他 containerd LTS 版本， 但由于自动化的 cgroup 驱动程序检测， Kubernetes SIG Node 社区已正式商定了 containerd v1.X 的最终支持时间表。 Kubernetes v1.35 是提供此支持的最后一个版本（与 containerd 1.7 EOL 对齐）。

这是最终警告：如果你正在使用 containerd 1.X， 必须在将 Kubernetes 升级到下一个版本之前切换到 2.0 或更高版本。 你可以监控 kubelet_cri_losing_support 指标来确定 集群中的任何节点是否正在使用即将不受支持的 containerd 版本。

你可以在官方博客文章 或 KEP-4033：从 CRI 发现 cgroup 驱动程序 中找到更多信息。

以下增强功能是可能包含在 v1.35 版本中的部分功能。 这不是承诺，发布内容可能会发生变化。

节点声明式特性

在调度 Pod 时，Kubernetes 使用节点标签、污点和容忍度 来匹配工作负载需求与节点能力。 然而，由于控制平面和节点之间的版本偏移， 在集群升级期间管理功能兼容性变得具有挑战性。 这可能导致 Pod 被调度到缺少所需功能的节点上，从而导致运行时失败。

**节点声明式特性（Node Declared Features）**框架将引入一种标准机制， 让节点声明其所支持的 Kubernetes 特性。 启用这一新的 Alpha 特性后，节点会报告其可以支持的特性， 通过新的 .status.declaredFeatures 字段将此信息发布到控制平面。 然后，kube-scheduler、准入控制器和第三方组件可以使用这些声明。 例如，你可以强制执行调度和 API 验证约束， 确保 Pod 仅在兼容的节点上运行。

这种方法可以减少手动为节点打标签的操作，提高调度准确性， 并主动防止不兼容的 Pod 放置。 它还与集群自动扩缩器（Cluster Autoscaler）集成，以便做出明智的扩容决策。 特性声明是临时性的，并与 Kubernetes 特性门控绑定， 从而实现安全的推出和清理。

目标是在 v1.35 中达到 Alpha 阶段，节点声明式特性旨在通过明确节点能力 来解决版本偏移调度问题，在异构版本环境中增强可靠性和集群稳定性。

在官方文档发布之前了解更多信息，你可以阅读 KEP-5328。

Pod 资源的原地更新

Kubernetes 正在将 Pod 资源的原地更新提升到正式发布（GA）状态。 此特性允许用户在不重启 Pod 或容器的情况下调整 cpu 和 memory 资源。 以前，此类修改需要重新创建 Pod，这可能会中断工作负载， 特别是对于有状态或批处理应用程序。

之前的 Kubernetes 版本已经允许你更改现有 Pod 的基础设施资源设置（requests 和 limits）。 这允许更平滑的垂直扩缩容， 提高效率，还可以简化解决方案开发。

容器运行时接口（CRI）也得到了改进， 为 Windows 和未来的运行时扩展了 UpdateContainerResources API， 同时允许 ContainerStatus 报告实时的资源配置情况。 这些更改一起使 Kubernetes 中的扩缩容更快、更灵活且无中断。 此特性在 v1.27 中作为 Alpha 特性引入，在 v1.33 中升级到 Beta， 并且计划在 v1.35 中升级到稳定状态。

你可以在 KEP-1287：Pod 资源的原地更新 中找到更多信息。

Pod 证书

在运行微服务时，Pod 通常需要强加密身份， 以便使用双向 TLS（mTLS）相互进行身份认证。 虽然 Kubernetes 提供服务账号令牌， 但这些令牌设计用于向 API 服务器进行身份认证， 而不是用于通用工作负载身份。

在此增强之前，操作员必须依赖复杂的外部项目（如 SPIFFE/SPIRE 或 cert-manager） 来为其工作负载提供和轮换证书。 但是，如果你可以原生且自动地为 Pod 颁发唯一的短期证书呢？ KEP-4317 旨在启用这种原生工作负载身份。 它通过允许 kubelet 通过投影卷为 Pod 请求和挂载证书， 为保护 Pod 到 Pod 的通信开辟了多种可能性。

Pod 证书为工作负载身份提供了一种内置的机制，包括自动证书轮换， 显著简化了服务网格和其他零信任网络策略的设置。 该特性在 v1.34 中作为 Alpha 特性引入，目标是在 v1.35 中达到 Beta 阶段。

你可以在 KEP-4317：Pod 证书 中找到更多信息。

数值形式的污点

Kubernetes 正在通过添加数值比较运算符（如 Gt（大于）和 Lt（小于）） 来增强污点和容忍度。

以前，容忍度仅支持精确（Equal）或存在（Exists）匹配， 这不适用于可靠性 SLA 等数值属性。

通过此更改，Pod 可以使用容忍度来"选择"满足特定数值阈值的节点。 例如，Pod 可以要求 SLA 污点值大于 950 的节点（operator: Gt，value: "950"）。

这种方法比节点亲和性更强大，因为它支持 NoExecute 效果， 如果节点的数值降至容忍阈值以下，允许自动驱逐 Pod。

你可以在 KEP-5471：启用基于 SLA 的调度 中找到更多信息。

用户名字空间

在运行 Pod 时，你可以使用 securityContext 来去除特权， 但 Pod 内的容器通常仍以 root（UID 0）运行。 这种简单性带来了重大挑战，因为容器 UID 0 直接映射到主机的 root 用户。

在此增强之前，容器逃逸漏洞可能授予攻击者对节点的完全 root 访问权限。 但是，如果你可以将容器的 root 用户动态重新映射到主机上的安全、无特权用户呢？ KEP-127 专门为 Linux 用户名字空间提供原生支持。 它通过隔离容器和主机用户/组 ID 为 Pod 安全开辟了各种可能性。 这允许进程在其名字空间内拥有 root 权限（UID 0）， 同时在主机上以非特权的高编号 UID 运行。

该特性在 v1.25 中作为 Alpha 特性发布，并在 v1.30 中进阶到 Beta 阶段， 在 Beta 成熟度级别，此特性仍在进一步演化， 为真正的"无 root"容器铺平道路， 这些改进大大减少了一整类安全漏洞的攻击面。

你可以在 KEP-127：用户名字空间 中找到更多信息。

支持将 OCI 镜像挂载为卷

在配置 Pod 时，你经常需要为容器打包数据、二进制文件或配置文件。 在此增强之前，人们通常将此类数据直接包含在主容器镜像中， 或需要自定义 Init 容器将文件下载并解压到 emptyDir 中。 当然，你仍然可以采用这两种方法中的任何一种。

但是，如果你可以直接使用 OCI 镜像库中的纯数据工件填充卷， 就像拉取容器镜像一样呢？ Kubernetes v1.31 添加了对 image 卷类型的支持， 允许 Pod 以声明的方式将 OCI 容器镜像工件拉取并解压到卷中。

这一特性使我们能够使用标准镜像库工具无缝分发数据、二进制文件或 ML 模型， 完全将数据与容器镜像解耦，并消除对复杂 Init 容器或启动脚本的需求。 此卷类型自 v1.33 以来一直处于 Beta 状态，并可能在 v1.35 中默认启用。

你可以试用 image 卷 的 Beta 版本， 或者你可以从 KEP-4639：OCI 卷源 了解更多计划。

想了解更多？

新特性和弃用也在 Kubernetes 发布说明中宣布。 我们将正式宣布 Kubernetes v1.35 的新内容， 作为该版本 CHANGELOG 的一部分。

Kubernetes v1.35 版本计划于 2025 年 12 月 17 日发布。请关注更新！

你还可以在以下版本的发布说明中查看变更公告：

参与进来

参与 Kubernetes 最简单的方法是加入众多 特别兴趣小组（SIG）中 与你兴趣相符的一个。 有什么想向 Kubernetes 社区广播的内容吗？ 在我们的每周社区会议上 以及通过下面的渠道分享你的声音。 感谢你持续的反馈和支持。