Kubernetes v1.35：Timbernetes（世界树版本）

作者 v1.35 发布团队(https://github.com/kubernetes/sig-release/blob/master/releases/release-1.35/release-team.md) | 译者 Wenjun Lou |

编辑：Aakanksha Bhende、Arujjwal Negi、Chad M. Crowell、Graziano Casto、Swathi Rao

与之前版本类似，Kubernetes v1.35 的发布引入了新的稳定（GA）、Beta 和 Alpha 特性。 持续交付高质量版本，体现了我们开发周期的韧性，也离不开社区的热情支持。

此版本包含 60 个增强项，其中包括 17 个稳定（GA）特性、19 个 Beta 特性和 22 个 Alpha 特性。

本次发布还包含一些弃用与移除内容，请务必阅读相关说明。

2025 年在 Octarine：The Color of Magic（v1.33）的微光中启程， 又乘着 Of Wind & Will（v1.34）的疾风前行。 我们在年末将双手搭在世界树上，灵感来自 Yggdrasil——那棵连接诸多世界的生命之树。 如同所有伟大的树木，Kubernetes 也在全球社区的悉心呵护下， 以年轮为记、以版本为序，不断成长。

在这棵树的中心，是环抱地球的 Kubernetes 方向盘标。 它之所以稳固，源于那些始终如一的维护者、贡献者与用户。 在本职工作与生活变迁之间，在持续的开源维护之中， 他们修剪旧 API、嫁接新特性，让这个全球最大开源项目之一保持健康。

三只松鼠守护着这棵树： 为评阅者举起 LGTM 卷轴的法师； 为发布团队挥斧开枝、并举起 Kubernetes 盾牌的战士； 以及为分诊者照亮幽深 Issue 队列的提灯游侠。

它们共同象征着一支规模更大的冒险队伍。 Kubernetes v1.35 为世界树再添一圈年轮——这一道新切面由无数双手、 无数条路径与一个根系更深、枝叶更高的社区共同塑造。

重点更新速览

Kubernetes v1.35 带来了大量新特性与改进。下面是发布团队希望重点介绍的几个更新！

稳定（GA）阶段：Pod 资源原地更新

Kubernetes 已将 Pod 资源的原地更新特性升级为正式发布（GA）。

该特性允许用户在不重启 Pod 或容器的情况下，调整 CPU 与内存资源。 此前，这类修改需要重建 Pod，可能会干扰工作负载，尤其是有状态或批处理应用。 更早的 Kubernetes 版本仅允许你为现有 Pod 修改基础设施资源设置（requests 与 limits）。 新的原地更新能力支持更平滑、不中断的纵向扩缩容，提高效率，也能简化开发流程。

此项工作是 KEP #1287 的一部分，由 SIG Node 牵头完成。

Beta：用于工作负载身份与安全的 Pod 证书

此前，要向 Pod 下发证书，往往需要外部控制器（cert-manager、SPIFFE/SPIRE）、 CRD 编排以及 Secret 管理，并由边车或 Init 容器负责证书轮换。 Kubernetes v1.35 通过自动化证书轮换，实现原生工作负载身份， 大幅简化服务网格与零信任架构。

现在，kubelet 会生成密钥，通过 PodCertificateRequest 请求证书， 并将凭据包直接写入 Pod 的文件系统。 kube-apiserver 会在准入阶段强制执行节点限制， 消除第三方签名者最常见的陷阱：无意间突破节点隔离边界。 这使得签发路径中无需持有者令牌即可实现纯双向 TLS 流程。

此项工作是 KEP #4317 的一部分，由 SIG Auth 牵头完成。

Alpha：调度前节点声明式特性

当控制平面启用新特性、但节点侧进度滞后时（Kubernetes 版本偏差策略允许这种情况）， 调度器可能会将需要这些特性的 Pod 调度到不兼容的旧节点上。

节点声明式特性框架允许节点声明其所支持的 Kubernetes 特性。 启用这一 Alpha 特性后，Node 会通过新的 .status.declaredFeatures 字段上报其支持的特性， 并将信息发布到控制平面。 随后，kube-scheduler、准入控制器以及第三方组件都可以使用这些声明。 例如，你可以强制执行调度与 API 校验约束，确保 Pod 只运行在兼容的节点上。

此项工作是 KEP #5328 的一部分，由 SIG Node 牵头完成。

进入稳定（GA）阶段的特性

以下列出 v1.35 发布后进入稳定（GA）阶段的一些改进。

PreferSameNode 流量分配

Service 的 trafficDistribution 字段已更新，以便更明确地控制流量路由。 新增选项 PreferSameNode：在可用时严格优先选择本节点上的端点， 否则再回退到远端端点。

同时，现有的 PreferClose 选项已重命名为 PreferSameZone。 这一变更让 API 更加直观、自解释：它明确表示优先在当前可用区内选择流量路径。 虽然为了向后兼容仍保留 PreferClose，但 PreferSameZone 现在是可用区级别路由的标准选项， 确保“节点级”与“可用区级”的偏好能够清晰区分。

此项工作是 KEP #3015 的一部分，由 SIG Network 牵头完成。

Job API 的 managed-by 机制

Job API 新增 managedBy 字段，允许外部控制器接管 Job 状态同步。 该特性在 Kubernetes v1.35 中进入稳定（GA）阶段， 主要由 MultiKueue 推动。 MultiKueue 是一种多集群分发系统，在管理集群创建的 Job 会被镜像到工作集群执行，并将状态更新回传。 为实现这一工作流，需要让内置 Job 控制器不要处理某个特定 Job 资源， 从而由 Kueue 控制器接管状态更新。

其目标是让 Job 同步能够清晰地委派给另一个控制器。 它并不意图向该控制器传递自定义参数，也不打算修改 CronJob 的并发策略。

此项工作是 KEP #4368 的一部分，由 SIG Apps 牵头完成。

使用 .metadata.generation 可靠跟踪 Pod 更新

在历史上，Pod API 缺少 metadata.generation 字段（其他对象例如 Deployment 具备该字段）。 因此，控制器与用户无法可靠地确认 kubelet 是否已经处理了 Pod 规约的最新变更。 这种不确定性在诸如Pod 资源原地纵向扩缩容 等特性中尤为突出，因为很难精确判断资源调整请求何时真正生效。

Kubernetes v1.33 以 Alpha 形式为 Pod 增加了 .metadata.generation 字段。 在 v1.35 的 Pod API 中，该字段已进入稳定（GA）阶段。 每当更新 Pod 的 spec 时，.metadata.generation 的值都会递增。 作为这一改进的一部分，Pod API 还新增了 .status.observedGeneration 字段， 用于报告 kubelet 已经成功看到并处理的 generation。 Pod 的各类状况（conditions）也各自包含独立的 observedGeneration 字段， 客户端可以上报和/或观测这些字段。

由于该特性在 v1.35 进入稳定（GA）阶段，它对所有工作负载可用。

此项工作是 KEP #5067 的一部分，由 SIG Node 牵头完成。

为拓扑管理器提供可配置 NUMA 节点上限

拓扑管理器过去使用硬编码上限 8， 作为其可支持的 NUMA 节点最大数量，以避免在亲和性计算期间出现状态爆炸。 这里有个重要细节：NUMA 节点（NUMA node）与 Kubernetes API 中的 Node 并不是同一概念。 这一 NUMA 节点数量上限，限制了 Kubernetes 对现代高端服务器的充分利用， 因为这类服务器越来越常见地采用拥有超过 8 个 NUMA 节点的 CPU 架构。

Kubernetes v1.31 为拓扑管理器策略配置引入了新的 Beta 选项max-allowable-numa-nodes。 在 Kubernetes v1.35 中，该选项已进入稳定（GA）阶段。 启用该选项的集群管理员可以使用拥有超过 8 个 NUMA 节点的服务器。

尽管这一配置选项已进入稳定（GA）阶段，Kubernetes 社区仍注意到在大型 NUMA 主机上性能欠佳， 并提出了旨在改进该问题的增强提案（KEP-5726）。 要了解更多信息，请阅读在节点上控制拓扑管理策略。

此项工作是 KEP #4622 的一部分，由 SIG Node 牵头完成。

Beta 中的新特性

以下列出 v1.35 发布后进入 Beta 阶段的一些改进。

通过 Downward API 暴露节点拓扑标签

过去，要在 Pod 内访问节点拓扑信息（例如区域与可用区），通常需要查询 Kubernetes API 服务器。 这种做法虽然可行，但为了获取基础设施元数据，往往需要授予较宽泛的 RBAC 权限， 或引入边车容器，从而带来复杂度与安全风险。 Kubernetes v1.35 将“通过 Downward API 直接暴露节点拓扑标签”的能力提升为 Beta。

现在，kubelet 可以将标准拓扑标签（例如 topology.kubernetes.io/zone 与 topology.kubernetes.io/region）注入到 Pod 中， 以环境变量或投射卷文件（projected volume files）的形式呈现。 其主要收益是让工作负载以更安全、更高效的方式具备拓扑感知能力。 应用可以在不依赖 API 服务器的情况下原生适配其所在可用区或区域， 通过坚持最小特权原则来增强安全性，并简化集群配置。

说明： Kubernetes 现在会为每个 Pod 注入可用的拓扑标签， 使其可以作为 Downward API 的输入。 升级到 v1.35 后，大多数集群管理员会看到每个 Pod 新增了若干标签； 这是设计的一部分，属于预期行为。

此项工作是 KEP #4742 的一部分，由 SIG Node 牵头完成。

存储版本迁移的原生支持

在 Kubernetes v1.35 中，存储版本迁移的原生支持升级为 Beta 并默认启用。 这一改动将迁移逻辑直接集成到 Kubernetes 核心控制平面（in-tree）中， 从而消除对外部工具的依赖。

在过去，管理员依赖手工的“读/写循环”（read/write loops）， 常见做法是把 kubectl get 的输出通过管道传给 kubectl replace， 用来更新资源的模式（Schema）或重新加密静态数据。 这种方式效率低且容易产生冲突，尤其是对 Secret 这类较大的资源更是如此。 在本次发布中，内置控制器会自动处理更新冲突与一致性令牌， 以更安全、简化且可靠的方式确保存储数据保持最新，并将运维开销降到最低。

此项工作是 KEP #4192 的一部分，由 SIG API Machinery 牵头完成。

可变更的卷挂接上限

CSI（Container Storage Interface）驱动是 Kubernetes 插件， 为存储系统向容器化工作负载暴露能力提供一致的方式。 CSINode 对象会记录节点上安装的所有 CSI 驱动的详细信息。 不过，节点上报告的挂接容量与实际挂接容量可能出现不一致： 当 CSI 驱动启动后卷槽位被消耗时，kube-scheduler 可能把有状态 Pod 调度到挂接容量不足的节点上，最终卡在 ContainerCreating 状态。

Kubernetes v1.35 使 CSINode.spec.drivers[*].allocatable.count 可变更， 以便动态更新节点可用的卷挂接容量。它还通过 CSIDriver 对象引入可配置的刷新间隔， 允许 CSI 驱动控制在所有节点上更新 allocatable.count 值的频率。 此外，当检测到因容量不足导致的卷挂接失败时， 它会自动更新 CSINode.spec.drivers[*].allocatable.count。 尽管该特性在 v1.34 中已升级为 Beta， 但当时特性门控 MutableCSINodeAllocatableCount 默认关闭； 在 v1.35 中它仍处于 Beta，以便留出反馈时间，同时该特性门控默认启用。

此项工作是 KEP #4876 的一部分，由 SIG Storage 牵头完成。

机会式批处理

在过去，Kubernetes 调度器按顺序处理 Pod，其时间复杂度为 O(Pod 个数 × 节点个数)， 这会导致对“可兼容 Pod”执行重复计算。此 KEP 引入一种机会式批处理机制， 旨在通过 Pod scheduling signature 识别这类可兼容 Pod 并将它们批量处理， 从而在这些 Pod 之间共享过滤与打分结果以提升性能。

**Pod 调度签名（Pod Scheduling Signature）**机制确保从调度视角看，具有相同签名的两个 Pod 是“相同的”。 它不仅会考虑 Pod 与节点属性，还会纳入系统中的其他 Pod 以及有关放置的全局数据。 这意味着：具有给定签名的任意 Pod，在任意一组节点上都会得到相同的打分/可行性判断结果。

该批处理机制包含两个可按需调用的操作：create 与 nominate。 create 会基于具有有效签名的 Pod 的调度结果，创建一组新的批处理信息。 nominate 会使用 create 生成的批处理信息， 为一个新 Pod（其签名与规范 Pod 的签名一致）设置提名的节点名称。

此项工作是 KEP #5598 的一部分，由 SIG Scheduling 牵头完成。

StatefulSet 的 maxUnavailable

StatefulSet 运行一组 Pod，并为其中每个 Pod 维护粘性身份（Sticky Identity）。 这对需要稳定网络标识符或持久存储的有状态工作负载至关重要。 当 StatefulSet 的 .spec.updateStrategy.<type> 设置为 RollingUpdate 时， StatefulSet 控制器会删除并重建 StatefulSet 中的每个 Pod。 它会按 Pod 终止的顺序（从最大序号到最小序号）推进，一次只更新一个 Pod。

Kubernetes v1.24 在 StatefulSet 的 rollingUpdate 配置中新增了一个 Alpha 字段 maxUnavailable，除非你的集群管理员显式选择启用， 否则该字段不会出现在 Kubernetes API 中。 在 Kubernetes v1.35 中，该字段升级为 Beta 且默认可用。 你可以用它定义更新期间最多允许不可用的 Pod 数量。 该设置与将 .spec.podManagementPolicy 设为 Parallel 组合使用时最有效。 你可以把 maxUnavailable 设置为一个正整数（例如：2）， 或设置为期望 Pod 数量的百分比（例如：10%）。 如果未指定该字段，它默认为 1，以保持此前“一次只更新一个 Pod”的行为。 这一改进使有状态应用（可容忍多个 Pod 同时不可用）能够更快完成更新。

此项工作是 KEP #961 的一部分，由 SIG Apps 牵头完成。

kuberc 中可配置的凭据插件策略

可选的 kuberc 文件 用于将服务器配置与集群凭据和用户偏好相分离，而不会因意外输出而打断已经在运行的 CI 流水线。

作为 v1.35 发布的一部分，kuberc 增加了允许用户配置凭据插件策略的能力。 此变更引入两个字段：credentialPluginPolicy（允许或拒绝所有插件）， 以及 credentialPluginAllowlist（允许指定允许插件的列表）。

此项工作是 KEP #3104 的一部分， 由 SIG Auth 与 SIG CLI 协作完成。

KYAML

YAML 是一种便于人类阅读的数据序列化格式。 在 Kubernetes 中，YAML 文件用于定义与配置资源，例如 Pod、Service 与 Deployment。 不过，复杂 YAML 很难阅读：YAML 对缩进与嵌套要求严格； 同时，其可选的字符串引用也可能导致意外的类型强制转换（参见：The Norway Bug）。 虽然 JSON 可以作为一种替代方案，但它不支持注释，并对尾随逗号与键的引号有严格要求。

KYAML 是专为 Kubernetes 设计的、更安全且更少歧义的 YAML 子集。 它在 v1.34 作为可选的 Alpha 特性引入， 并在 Kubernetes v1.35 升级为 Beta 且默认启用。 你可以通过设置环境变量 KUBECTL_KYAML=false 来禁用它。

KYAML 旨在解决 YAML 与 JSON 的一些共性挑战。 所有 KYAML 文件也都是合法的 YAML 文件， 这意味着你可以编写 KYAML 并将其作为输入提供给任意版本的 kubectl。 这也意味着，即使输入并非严格 KYAML，也仍然可以被解析。

此项工作是 KEP #5295 的一部分，由 SIG CLI 牵头完成。

可配置的 HorizontalPodAutoscalers 容忍度

水平 Pod 自动扩缩容器（Horizontal Pod Autoscaler，HPA）长期依赖固定的全局 10% 容忍度来执行扩缩容。 这一硬编码值的缺点是：对需要高灵敏度的工作负载（例如希望在负载增加 5% 时就扩容）不够友好， 这些工作负载常常无法触发扩缩容；而另一些工作负载则可能产生不必要的振荡。

在 Kubernetes v1.35 中，“可配置容忍度”特性升级为 Beta 并默认启用。 该增强允许用户在 HPA 的 behavior 字段中，按资源粒度定义自定义容忍窗口。 通过设置特定容忍度（例如将其降低到 0.05 来表示 5%），运维人员可以更精确地控制自动扩缩容灵敏度， 确保关键工作负载能对小幅指标变化快速响应，而无需进行集群范围的配置调整。

此项工作是 KEP #4951 的一部分，由 SIG Autoscaling 牵头完成。

Pod 中的用户命名空间支持

Kubernetes 增加了对用户命名空间（user namespaces）的支持， 使 Pod 可以使用相互隔离的用户/组 ID 映射运行，而不是共享主机上的 ID。 这意味着容器在内部可以以 root 身份运行， 但在主机上实际映射为一个非特权用户，从而在发生入侵时降低提权风险。 该特性提升了 Pod 级别的安全性，使需要在容器内使用 root 的工作负载更安全。 随着时间推移，该能力也通过 ID 映射挂载（id-mapped mounts）扩展到无状态与有状态 Pod。

此项工作是 KEP #127 的一部分，由 SIG Node 牵头完成。

VolumeSource：OCI 工件和/或镜像

在创建 Pod 时，你常常需要为容器提供数据、二进制文件或配置文件。 这通常意味着要么把内容打进主容器镜像，要么使用自定义 Init 容器下载并解包到 emptyDir 中。 这两种方式仍然有效。Kubernetes v1.31 增加了对 image 卷类型的支持， 允许 Pod 以声明的方式拉取并将 OCI 容器镜像工件解包到卷中。 这使你可以使用标准 OCI 镜像库工具来打包与分发纯数据工件，例如配置、二进制文件或机器学习模型。

借助该特性，你可以将数据与容器镜像彻底分离，并去除额外 Init 容器或启动脚本的需求。 image 卷类型自 v1.33 起处于 Beta，并在 v1.35 中默认启用。 请注意，使用该特性需要兼容的容器运行时，例如 containerd v2.1 或更高版本。

此项工作是 KEP #4639 的一部分，由 SIG Node 牵头完成。

对缓存镜像强制执行 kubelet 凭据校验

当前，imagePullPolicy: IfNotPresent 允许 Pod 使用节点上已经缓存的容器镜像， 即使 Pod 本身并不具备拉取该镜像所需的凭据。这种行为在多租户集群中会带来安全漏洞： 如果某个具备有效凭据的 Pod 把敏感的私有镜像拉取到某节点上， 同一节点上后续的未授权 Pod 只需依赖本地缓存就能访问该镜像。

此 KEP 引入一种机制：由 kubelet 对缓存镜像强制执行凭据校验。 在允许 Pod 使用本地缓存镜像之前，kubelet 会检查 Pod 是否具备拉取该镜像的有效凭据。 这确保只有经授权的工作负载才能使用私有镜像， 无论该镜像是否已经存在于节点上，从而显著增强共享集群的安全性。

在 Kubernetes v1.35 中，该特性升级为 Beta 并默认启用。 用户仍可将 KubeletEnsureSecretPulledImages 特性门控设为 false 来禁用它。 此外，imagePullCredentialsVerificationPolicy 参数允许运维人员配置期望的安全级别， 从优先保证向后兼容的模式到提供最高安全性的严格强制模式不等。

此项工作是 KEP #2535 的一部分，由 SIG Node 牵头完成。

细粒度的容器重启规则

在过去，restartPolicy 字段只能在 Pod 级别定义，从而强制 Pod 内所有容器采用相同行为。 这一全局设置对复杂工作负载（例如 AI/ML 训练作业）缺乏足够的粒度。 这类作业往往需要 Pod 使用 restartPolicy: Never 以管理作业完成， 但某些容器仍希望能针对可重试的特定错误（如网络抖动或 GPU 初始化失败）执行原地重启。

Kubernetes v1.35 通过在容器 API 本身中启用 restartPolicy 与 restartPolicyRules 来解决这一问题。这允许用户为单个普通容器与 Init 容器定义重启策略， 并使其与 Pod 的整体策略相互独立。例如，你可以将容器配置为仅在以特定错误码退出时才自动重启， 从而避免因短暂故障而重调度整个 Pod 的昂贵开销。

在本次发布中，该特性升级为 Beta 并默认启用。用户可以立即在容器规约中使用 restartPolicyRules， 为长时间运行的工作负载优化恢复时间与资源利用率，而无需改变 Pod 更宏观的生命周期逻辑。

此项工作是 KEP #5307 的一部分，由 SIG Node 牵头完成。

CSI 驱动可选择通过 secrets 字段获取 ServiceAccount 令牌

在向 CSI（Container Storage Interface）驱动提供 ServiceAccount 令牌时， 传统上依赖把令牌注入到 volume_context 字段中。 这种方式存在显著安全风险：volume_context 主要用于非敏感配置数据， 并且常被驱动与调试工具以明文形式记录到日志中，从而可能泄露凭据。

Kubernetes v1.35 引入一套可选择启用的机制， 让 CSI 驱动通过 NodePublishVolume 请求中的专用 secrets 字段获取 ServiceAccount 令牌。 驱动现在可以在其 CSIDriver 对象中将 serviceAccountTokenInSecrets 设为 true 来启用此行为， 从而指示 kubelet 以更安全的方式填充该令牌。

其主要收益是防止凭据在日志与错误信息中被意外暴露。 这一变更确保敏感的工作负载身份通过合适的安全通道处理， 在保持对既有驱动向后兼容的同时，也更符合密文管理最佳实践。

此项工作是 KEP #5538 的一部分， 由 SIG Auth 牵头并与 SIG Storage 协作完成。

Deployment 状态：正在终止的副本计数

在过去，Deployment 状态会提供可用副本与已更新副本的详细信息， 但缺少对“正在关闭过程中的 Pod”的明确可见性。 这一缺失使用户与控制器难以区分“稳定的 Deployment”与“仍有 Pod 正在执行清理任务或处于较长优雅终止期”的 Deployment。

Kubernetes v1.35 将 Deployment 状态中的 terminatingReplicas 字段提升为 Beta。 该字段提供已设置删除时间戳但尚未从系统移除的 Pod 数量。该特性是一个更大计划中的基础一步， 旨在改进 Deployment 如何处理 Pod 替换，并为未来制定“在滚动发布期间何时创建新 Pod”的策略奠定基础。

其主要收益是提升生命周期管理工具与运维人员的可观测性。 通过公开正在终止的 Pod 数量，可以让外部系统做出更明智的决策， 例如在继续后续任务之前等待完全关闭，而无需手工查询并筛选各个 Pod 的列表。

此项工作是 KEP #3973 的一部分，由 SIG Apps 牵头完成。

Alpha 阶段的新特性

以下列出 v1.35 发布后进入 Alpha 阶段的一些改进。

Kubernetes 中的 Gang 调度支持

对相互依赖的工作负载（例如 AI/ML 训练作业或 HPC 仿真）进行调度， 传统上一直很有挑战性，因为默认的 Kubernetes 调度器会逐个调度 Pod。 这常导致“部分调度”：部分 Pod 已启动，而其他 Pod 由于资源不足无限期等待， 从而引发死锁并浪费集群容量。

Kubernetes v1.35 通过新的 Workload API 与 PodGroup 概念， 引入对所谓成组调度（Gang Scheduling）的原生支持。 该特性实现“全有或全无”的调度策略：只有当集群有足够资源同时容纳整个 Pod 组时，才会对该组进行调度。

其主要收益是提升批处理与并行工作负载的可靠性与效率。通过避免部分部署，它消除了资源死锁， 并确保昂贵的集群容量只在能够运行完整作业时才会被使用，从而显著优化大规模数据处理任务的编排。

此项工作是 KEP #4671 的一部分，由 SIG Scheduling 牵头完成。

受限的身份扮演（Impersonation）

在过去，Kubernetes RBAC 中的 impersonate 动词按“全有或全无”运作： 一旦用户被授权可以扮演某个目标身份，就会获得该身份所关联的全部权限。 这种宽泛授权的缺点是违背最小特权原则，使管理员难以将模拟者的权限限制到特定动作或特定资源上。

Kubernetes v1.35 引入一个新的 Alpha 特性：受限的身份扮演（Constrained Impersonation）， 它在身份扮演流程中增加一次二次鉴权检查。当 ConstrainedImpersonation 特性门控被启用后， API 服务器不仅会校验基础的 impersonate 权限，还会使用新的动词前缀（例如 impersonate-on:<mode>:<verb>） 检查身份扮演者是否被授权执行特定动作。 这使管理员可以定义细粒度策略——例如允许支持工程师模拟集群管理员仅用于查看日志， 而不授予完整的管理员访问权限。

此项工作是 KEP #5284 的一部分，由 SIG Auth 牵头完成。

Kubernetes 组件的 Flagz

在过去，要验证 Kubernetes 组件（例如 API 服务器或 kubelet）的运行时配置， 通常需要对宿主机节点或进程参数具有特权访问权限。 为解决这一问题，引入了 /flagz 端点，通过 HTTP 公开其命令行选项。 但其最初输出仅为纯文本，使自动化工具难以可靠地解析并校验配置。

在 Kubernetes v1.35 中，/flagz 端点增强为支持结构化、机器可读的 JSON 输出。 经授权的用户现在可以通过标准 HTTP 内容协商请求版本化的 JSON 响应， 同时原先的纯文本格式仍保留，便于人工查看。 此更新显著改进可观测性与合规工作流，让外部系统无需脆弱的文本解析或直接基础设施访问， 即可通过编程方式审计组件配置。

此项工作是 KEP #4828 的一部分，由 SIG Instrumentation 牵头完成。

Kubernetes 组件的 Statusz

传统上，排查 kube-apiserver 或 kubelet 等 Kubernetes 组件问题， 往往需要解析非结构化日志或文本输出，这种方式脆弱且难以自动化。 此前虽然存在基础的 /statusz 端点， 但缺乏标准化、机器可读的格式，从而限制了外部监控系统的可用性。

在 Kubernetes v1.35 中，/statusz 端点增强为支持结构化、机器可读的 JSON 输出。 经授权的用户现在可以通过标准 HTTP 内容协商请求这一格式， 以获取精确的状态数据——例如版本信息与健康指标——而无需依赖脆弱的文本解析。 该改进为所有核心组件的自动化调试与可观测性工具提供了可靠且一致的接口。

此项工作是 KEP #4827 的一部分，由 SIG Instrumentation 牵头完成。

CCM：基于 Informer 的 Watch 式路由控制器调谐

在云环境中管理网络路由，传统上依赖云控制器管理器（CCM）定期轮询云提供商 API 来校验并更新路由表。 这种固定间隔的调谐方式可能效率不高， 常会产生大量不必要的 API 调用，并在节点状态变化与路由更新之间引入延迟。

在 Kubernetes v1.35 中，cloud-controller-manager 库为路由控制器引入基于 watch 的调谐策略。 控制器不再依赖定时器，而是利用 Informer 监听特定的 Node 事件，例如新增、删除或相关字段更新， 仅在确有变更发生时触发路由同步。

其主要收益是显著减少对云提供商 API 的使用，从而降低触发速率限制的风险并减少运维开销。 此外，这种事件驱动模型通过确保路由表在集群拓扑变化后立即更新，提升了集群网络层的响应速度。

此项工作是 KEP #5237 的一部分，由 SIG Cloud Provider 牵头完成。

用于基于阈值放置的扩展容忍度运算符

Kubernetes v1.35 通过允许工作负载表达可靠性要求，引入 SLA 感知调度（SLA-aware scheduling）。 该特性为容忍度增加数值比较运算符， 让 Pod 可以依据与 SLA 相关的污点（例如服务保障或故障域质量）来匹配或避开节点。

其主要收益是让调度器具备更精确的放置能力。关键工作负载可要求更高 SLA 的节点， 而低优先级工作负载则可选择使用较低 SLA 的节点。这在不牺牲可靠性的前提下提升了利用率并降低成本。

此项工作是 KEP #5471 的一部分，由 SIG Scheduling 牵头完成。

Job 挂起时可变更的容器资源

运行批处理工作负载时，经常需要对资源限制进行反复试错。 目前 Job 规约是不可变的，这意味着当 Job 因内存不足（OOM）或 CPU 不足而失败时， 用户无法直接调整资源；他们必须删除 Job 并重新创建，从而丢失执行历史与状态信息。

Kubernetes v1.35 引入一种能力：对处于挂起状态的 Job 更新资源请求与限制。 通过 MutableJobPodResourcesForSuspendedJobs 特性门控启用后， 用户可以暂停一个失败的 Job，修改其 Pod 模板中的资源值，然后在修正配置后恢复执行。

其主要收益是让配置错误的 Job 具备更平滑的恢复流程。 通过允许在挂起期间进行原地修正，用户可以消除资源瓶颈， 而不会破坏 Job 的生命周期标识，也不会丢失完成状态追踪， 从而显著改善批处理场景下的开发体验。

此项工作是 KEP #5440 的一部分，由 SIG Apps 牵头完成。

其他值得关注的变更

动态资源分配（DRA）的持续创新

核心能力在 v1.34 中进阶至稳定（GA）阶段，并允许关闭。 在 v1.35 中，此特性将始终被启用。此外，若干 Alpha 特性也得到了显著改进，已准备好进行测试。 我们鼓励用户就这些能力提供反馈，以帮助它们在后续版本中更顺利地走向 Beta。

通过 DRA 扩展资源请求

相较于通过设备插件（Device Plugins）实现的扩展资源请求， 当前版本补齐了若干特性差距，例如对 Init 容器中设备的打分与复用能力。

设备污点与容忍度

新的 “None” 效果可用于报告问题，而不会立刻影响调度或正在运行的 Pod。 DeviceTaintRule 现在还会提供正在进行驱逐的状态信息。 在真正开始驱逐 Pod 之前，可以先用 “None” 效果进行一次“演练”（dry run）：

  • 使用 effect: None 创建 DeviceTaintRule。
  • 检查状态，了解将会驱逐多少个 Pod。
  • 将 effect: None 替换为 effect: NoExecute。

可切分设备

属于同一类可切分设备（Partitionable Devices）的设备， 现在可以定义在不同的 ResourceSlice 中。

更多信息请参阅官方文档。

可消耗容量与设备绑定条件

该版本修复了若干缺陷并添加了更多测试。

你可以在官方文档中进一步了解可消耗容量 与绑定条件。

可比较的资源版本语义

Kubernetes v1.35 改变了客户端被允许解释资源版本（resource versions）的方式。

在 v1.35 之前，客户端唯一受支持的比较方式是字符串相等性检查： 如果两个资源版本相等，它们就是同一个版本。 客户端也可以向 API 服务器提供资源版本，并请求控制平面执行内部比较， 例如流式获取自某个资源版本以来的所有事件。

在 v1.35 中，所有 in-tree 的资源版本都满足更严格的新定义： 它们的取值是一种特殊形式的十进制数。由于这些值可比较， 客户端也可以自行比较两个不同的资源版本。

例如，这意味着客户端在崩溃后重新连接时，可以检测自己是否丢失了更新， 而不仅仅是判断“期间是否有更新但没有丢失变更”的情况。

这一语义变更还支撑了其他重要用例，例如 存储版本迁移、对 informers （一种客户端辅助概念）的性能改进，以及控制器可靠性提升。 这些用例都需要能够判断一个资源版本是否比另一个更新。

此项工作是 KEP #5504 的一部分，由 SIG API Machinery 牵头完成。

v1.35 的升级、弃用与移除

进入稳定（GA）阶段的特性

这里列出所有进入稳定（也称为 正式发布（GA））阶段的特性。 要获取包含新增特性与从 Alpha 升级到 Beta 等在内的完整更新列表，请参阅发布说明。

本次发布共有 15 个增强项进入稳定（GA）阶段：

弃用、移除与社区更新

随着 Kubernetes 的发展与成熟，为提升项目整体健康度， 一些特性可能会被弃用、移除，或被更好的方案替代。 关于这一过程的更多信息，请参阅 Kubernetes 的弃用与移除策略。 Kubernetes v1.35 包含了若干项弃用内容。

Ingress NGINX 退役

多年来，Ingress NGINX 控制器一直是将流量路由到 Kubernetes 集群的热门选择。 它灵活、被广泛采用，并长期作为无数应用的标准入口。

然而，项目维护已经变得难以为继。由于维护者严重短缺且技术债不断累积， 社区近期做出了艰难决定：让该项目退役。这虽然并非严格意义上的 v1.35 发布内容， 但它影响重大，我们希望在这里特别强调。

因此，Kubernetes 项目宣布 Ingress NGINX 将仅提供尽力而为的维护， 直至 2026 年 3 月。 此日期之后，该项目将归档并不再更新。 推荐的后续路径是迁移到 Gateway API， 它提供了更现代、更安全且更可扩展的流量管理标准。

更多信息请参阅官方博客文章。

移除对 cgroup v1 的支持

在 Linux 节点的资源管理方面，Kubernetes 历史上依赖 cgroups（control groups）。 尽管最初的 cgroup v1 可以工作，但它常常不一致且存在局限。 因此，Kubernetes 在 v1.25 引入对 cgroup v2 的支持， 提供了更干净的统一层级结构与更好的资源隔离能力。

由于 cgroup v2 现已成为现代标准， Kubernetes 准备在 v1.35 中退役遗留的 cgroup v1 支持。 这对集群管理员而言是一项重要提醒： 如果你仍在运行不支持 cgroup v2 的旧 Linux 发行版节点， 你的 kubelet 将无法启动。 为避免停机，你需要将这些节点迁移到启用了 cgroup v2 的系统上。

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

kube-proxy 中 ipvs 模式的弃用

多年前，Kubernetes 在 kube-proxy 中采用ipvs 模式， 以提供比标准iptables 更快的负载均衡。 虽然它带来了性能提升，但为了跟上不断演进的网络需求， 维护其一致性所带来的技术债与复杂度已过高。

由于这一维护负担，Kubernetes v1.35 弃用 ipvs 模式。尽管该模式在本次发布中仍可用， 但当 kube-proxy 被配置为使用该模式时，将在启动时发出警告。 该弃用的目标是精简代码库并聚焦于现代标准。 对于 Linux 节点，你应开始迁移到nftables， 它现在是推荐的替代方案。

更多信息请参阅 KEP-5495：弃用 kube-proxy 的 ipvs 模式。

containerd v1.X 的最后通告

尽管 Kubernetes v1.35 仍支持 containerd 1.7 与其他 LTS 版本， 但这是最后一个提供此类支持的版本。 SIG Node 社区已将 v1.35 指定为最后一个支持 containerd v1.X 系列的版本。

这是一条重要提醒： 在升级到下一个 Kubernetes 版本之前，你必须切换到 containerd 2.0 或更高版本。 为帮助识别哪些节点需要关注，你可以在集群中监控 kubelet_cri_losing_support 指标。

更多信息可参阅官方博客文章， 或阅读 KEP-4033：从 CRI 发现 cgroup driver。

kubelet 重启期间的 Pod 稳定性改进

此前，重启 kubelet 服务往往会造成 Pod 状态的短暂波动。在重启期间，kubelet 会重置容器状态， 导致健康的 Pod 被标记为 NotReady 并从负载均衡器中移除，即便应用本身仍在正常运行。

为解决这一可靠性问题，该行为已被修正，以确保节点维护更平滑。 kubelet 现在会在启动时从运行时中正确恢复现有容器状态， 确保你的工作负载保持 Ready，并使流量在 kubelet 重启或升级期间持续不中断。

更多信息请参阅 KEP-4781：修复 kubelet 重启后容器就绪状态不一致问题。

发布说明

请在我们的发布说明 中查看 Kubernetes v1.35 发布的完整细节。

可用性

Kubernetes v1.35 可通过GitHub 或 Kubernetes 下载页面获取。

要开始使用 Kubernetes，请查看这些交互式教程， 或使用 minikube 在本地运行 Kubernetes 集群。 你也可以使用 kubeadm 轻松安装 v1.35。

发布团队

Kubernetes 之所以成为可能，离不开社区的支持、承诺与辛勤付出。 每个发布团队由一群投入的社区志愿者组成，他们一起构建你所依赖的 Kubernetes 发布版本的诸多部分。 这需要来自社区各个角落的专业能力：从代码本身到文档与项目管理。

我们在此缅怀Han Kang ——一位长期贡献者与备受尊敬的工程师，他的技术卓越与感染力十足的热情， 为 Kubernetes 社区留下了深远影响。Han 是 SIG Instrumentation 与 SIG API Machinery 中的重要力量， 并因其关键工作与对项目核心稳定性的持续投入， 获得了2021 Kubernetes Contributor Award。 除技术贡献之外，Han 也因其作为导师的慷慨与联结人们的热情而广受敬重。 他以“为他人打开大门”而闻名——无论是带领新贡献者完成第一次 PR， 还是以耐心与善意支持同事。Han 的遗产将通过他所激励的工程师、他参与构建的健壮系统， 以及他在云原生生态中所塑造的温暖协作精神延续下去。

我们感谢整个发布团队 为向社区交付 Kubernetes v1.35 所付出的辛勤时间。 发布团队成员既有第一次参与的 shadow，也有历经多轮发布周期、经验丰富的回归 team lead。 我们尤其感谢发布负责人Drew Hagen： 他既以务实指导带我们穿越复杂挑战，也以充沛能量点燃了这次成功发布背后的社区精神。

项目活跃度

CNCF K8s 的DevStats 项目汇总了与 Kubernetes 及其各子项目活跃度相关的一系列有趣数据点。 这些数据涵盖从个人贡献到参与贡献公司的数量等多个方面， 体现了推动该生态演进所投入努力的深度与广度。

在 v1.35 发布周期（从 2025 年 9 月 15 日到 2025 年 12 月 17 日，共 14 周）期间， Kubernetes 收到了来自多达 85 家公司与 419 名个人的贡献。 在更广泛的云原生生态中，这一数字上升到 281 家公司，共计 1769 名贡献者。

请注意，这里的“贡献”统计包括：提交 commit、进行代码评审、发表评论、创建 Issue 或 PR、 评审 PR（包括博客与文档）以及对 Issue 与 PR 的评论等。
如果你有兴趣参与贡献，请访问贡献者网站上的Getting Started。

数据来源：

活动更新

了解即将到来的 Kubernetes 与云原生活动，包括 KubeCon + CloudNativeCon、KCD 与全球其他重要会议。 保持关注并参与 Kubernetes 社区！

2026 年 2 月

2026 年 3 月

2026 年 5 月

2026 年 6 月

2026 年 7 月

你可以在此处查看最新活动详情。

即将举行的发布网络研讨会

欢迎在 2026 年 1 月 14 日（星期三）17:00（UTC） 与 Kubernetes v1.35 发布团队成员一起， 了解本次发布的重点亮点。有关更多信息与注册方式，请访问 CNCF Online Programs 网站上的活动页面。

参与其中

参与 Kubernetes 最简单的方式之一，是加入与你兴趣相符的众多特别兴趣小组（Special Interest Groups，SIG） 之一。你想向 Kubernetes 社区发布一些内容吗？欢迎在我们每周的社区会议 上发声，也可以通过以下渠道参与交流。感谢你持续的反馈与支持。

  • 分享你的 Kubernetes 故事
  • 在博客阅读 Kubernetes 的更多动态