Kubernetes v1.36：ハル (Haru)

借由 Kubernetes v1.36 发布团队 | 译者 Paco Xu(DaoCloud) |

编辑：Chad M. Crowell、Kirti Goyal、Sophia Ugochukwu、Swathi Rao、Utkarsh Umre

与之前的版本类似，Kubernetes v1.36 的发布引入了新的稳定（GA）、Beta 和 Alpha 特性。 持续交付高质量版本，凸显了我们开发周期的韧性，以及社区充满活力的支持。

此版本包含 70 项增强。其中，18 项已进阶至稳定阶段，25 项进入 Beta 阶段，25 项进阶至 Alpha 阶段。

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

我们以 Kubernetes v1.36 开启 2026 年。 这个版本到来之时，季节更迭，山间光影流转。 ハル（Haru）在日语中富含多重意象； 其中我们最贴近的含义包括：春（spring）、晴れ（hare，晴空）和遥か（haruka，遥远）。 一个季节、一片天空和一条地平线。你将在接下来的内容中看到这三者。

该版本徽标由 avocadoneko / Natsuho Ide 创作， 灵感来自葛饰北斋的 《富嶽岳三十六景》 （富三十六景，Fugaku Sanjūrokkei）。 这一系列也诞生了了神奈川冲浪里这样的传世杰作。 我们的 v1.36 徽标重新诠释了这个系列中最著名的作品之一： 《凯风快晴》 （凱風快晴，Gaifū Kaisei），又名赤富士（Aka Fuji）： 夏日黎明中被照亮成红色、经历漫长融雪后已不覆雪的山。 三十六景与 v1.36 相映成趣，也提醒我们即便是北斋也没有止步于此。1 Kubernetes 舵轮守望着这一幕，与山一同融入天空。

富士山脚下坐着 Stella（左）和 Nacho（右）， 两只猫的项圈上带有 Kubernetes 舵轮， 象征着狛犬的角色： 守护日本神社的一对狮犬守护像。 它们成对出现，因为没有什么是独自守护的。 Stella 和 Nacho 代表着远比这两对爪子庞大得多的群体： SIG 和工作组、维护者和评审者、文档、博客与翻译背后的人们、发布团队、 迈出第一步的首次贡献者，以及年复一年回归的长期贡献者。 一如既往，Kubernetes v1.36 由众多双手托举。

徽标中横跨赤富士的书法是“晴れに翔け”（hare ni kake）， 意为“翱翔于晴空”。 这是一个对句的前半句，完整对句太长，无法完全放在山上：

晴れに翔け、未来よ明け
hare ni kake, asu yo ake
“翱翔于晴空；迎向明日朝阳。”2

这就是我们寄托于此版本的愿望： 让这个版本、这个项目，以及共同交付它的每个人，都能翱翔于晴空。 赤富士上破晓的晨光不是终点，而是一条通往未来的道路： 这个版本把我们带向下一个版本，而下一个版本又会通向再下一个版本， 一路迈向任何单一视角都无法穷尽的遥远地平线。

1. 这个系列非常受欢迎，北斋又增加了十幅版画，使总数达到四十六幅。
2. “未来”表示最宽泛意义上的“未来”，不只是明天，还包括一切尚未到来的事物。它通常读作 mirai；这里采用非正式读法 asu。

重点更新速览

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

稳定（GA）阶段：细粒度 API 鉴权

我们很高兴代表 Kubernetes SIG Auth 和 SIG Node 宣布： 细粒度 kubelet API 鉴权在 Kubernetes v1.36 中进阶至正式发布（GA）！

KubeletFineGrainedAuthz 特性门控在 Kubernetes v1.32 中作为可选的 Alpha 特性引入， 随后在 v1.33 中进阶为 Beta（默认启用）。 现在，此特性已正式发布（GA）。 该特性针对 kubelet 的 HTTPS API 实现了更精确、符合最小权限原则的访问控制， 替代了在常见监控和可观测性用例中授予过于宽泛的 nodes/proxy 权限的需求。

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

Beta：资源健康状态

在 v1.34 发布之前，Kubernetes 缺少一种原生方式来报告已分配设备的健康状况， 这使得诊断由硬件故障导致的 Pod 崩溃变得困难。 在 v1.31 中聚焦于设备插件的初始 Alpha 版本基础上， Kubernetes v1.36 通过将每个 Pod 的 .status 中的 allocatedResourcesStatus 字段提升至 Beta，扩展了这一特性。 此字段为所有专用硬件提供统一的健康报告机制。

用户现在可以运行 kubectl describe pod 来判断容器的崩溃循环是否由 Unhealthy 或 Unknown 设备状态导致，无论相关硬件是通过传统插件还是较新的 DRA 框架制备。 这种增强的可见性使管理员和自动化控制器能够快速识别故障硬件， 并简化高性能工作负载的恢复流程。

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

Alpha：工作负载感知调度（WAS）特性

此前，Kubernetes 调度器和 Job 控制器将 Pod 作为独立单元进行管理， 这常常会导致复杂分布式工作负载出现碎片化调度或资源浪费。 Kubernetes v1.36 引入了一整套 Alpha 阶段的工作负载感知调度（Workload-Aware Scheduling，WAS）特性， 将 Job 控制器与修订后的 Workload API 以及新的解耦 PodGroup API 原生集成， 从而把相关 Pod 作为单个逻辑实体处理。

Kubernetes v1.35 已经支持编组调度： 它要求在任何 Pod 绑定到节点之前，至少有指定数量的 Pod 可被调度。 v1.36 更进一步，引入新的 PodGroup 调度周期，以原子方式评估整个组： 组内所有 Pod 要么一起绑定，要么一个都不绑定。

此项工作跨越多个 KEP（包括 #4671、#5547、 #5832、#5732 和 #5710）， 由 SIG Scheduling 和 SIG Apps 牵头完成。

进阶至稳定阶段的特性

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

卷组快照

经过数个 Beta 周期后，VolumeGroupSnapshot 支持在 Kubernetes v1.36 中达到正式发布（GA）。 此特性允许你同时为多个 PersistentVolumeClaim 创建崩溃一致性快照。 卷组快照支持依赖一组用于组快照的扩展 API。 这些 API 允许用户为一组卷创建崩溃一致性快照。 一个关键目标是允许你将这组快照恢复到新卷， 并基于某个崩溃一致性恢复点恢复工作负载。

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

可变卷挂载限制

在 Kubernetes v1.36 中，可变 CSINode 可分配数量特性进阶至稳定（GA）阶段。 这一增强允许容器存储接口（CSI）驱动 动态更新所报告的某个节点可处理的最大卷数量。

通过这项更新，kubelet 可以动态更新节点的卷限制和容量信息。 kubelet 会基于周期性检查，或响应来自 CSI 驱动的资源耗尽错误来调整这些限制， 且无需重启组件。 这确保 Kubernetes 调度器能保持对存储可用性的准确视图， 避免因过期的卷限制导致 Pod 调度失败。

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

ServiceAccount 令牌外部签名 API

在 Kubernetes v1.36 中，面向 ServiceAccount 的外部 ServiceAccount 令牌签名器特性进阶至稳定（GA）阶段， 使集群可以将令牌签名卸载到外部系统，同时仍能与 Kubernetes API 清晰集成。 集群现在可以依赖外部 JWT 签名器签发投射的服务账户令牌， 这些令牌遵循标准的服务账户令牌格式，并在需要时支持延长过期时间。 这对已经依赖外部身份或密钥管理系统的集群尤其有用， 因为 Kubernetes 可以与其集成，而不必在控制平面内重复管理密钥。

kube-apiserver 已被连接到外部签名器，以发现并缓存其公钥， 并验证并非由 kube-apiserver 自身签发的令牌， 因此现有身份认证与鉴权流程会继续按预期工作。 在 Alpha 和 Beta 阶段，外部签名器插件的 API 与配置、路径验证以及 OIDC 发现 都经过了加固，以便安全处理真实部署和轮换模式。

随着 v1.36 中进入 GA，外部 ServiceAccount 令牌签名现在成为一种完全受支持的选项， 可供集中管理身份和签名的平台使用， 简化与外部 IAM 系统的集成，并减少在控制平面内直接管理签名密钥的需求。

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

进阶至稳定阶段的 DRA 特性

在 Kubernetes v1.36 中，随着关键治理和选择特性进阶至稳定（GA）阶段， 动态资源分配（DRA）生态的一部分已经达到完整的生产成熟度。 DRA 管理员访问进阶至 GA， 为集群管理员全局访问和管理硬件资源提供了永久且安全的框架； 同时，优先级列表的稳定化确保资源选择逻辑在所有集群环境中保持一致且可预测。

现在，组织可以在长期 API 稳定性和向后兼容性的保障下， 放心部署任务关键型硬件自动化。 这些特性使用户能够实现复杂的资源共享策略和管理性覆盖， 而这些能力对大规模 GPU 集群和多租户 AI 平台至关重要； 这也标志着下一代资源管理的核心架构基础已经完成。

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

变更性准入策略

随着 MutatingAdmissionPolicy（变更准入策略） 在 Kubernetes v1.36 中进阶至稳定（GA），声明式集群管理的成熟度达到新高度。 这一里程碑为传统 Webhook 提供了原生、高性能的替代方案： 管理员可以使用通用表达式语言（CEL）直接在 API 服务器中定义资源变更， 在许多常见用例中完全替代对外部基础设施的需求。

现在，集群操作人员可以修改传入请求， 而无需承担管理自定义准入 Webhook 所带来的延迟和运维复杂性。 通过将变更逻辑迁移到声明式、版本化的策略中， 组织可以获得更可预测的集群行为、更低的网络开销， 以及在长期 API 稳定性完整保障下的强化安全模型。

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

使用 validation-gen 对 Kubernetes 原生类型进行声明式验证

随着声明式验证（使用 validation-gen）在 Kubernetes v1.36 中进阶至稳定（GA）， 自定义资源的开发效率达到新水平。 这一里程碑允许开发者使用通用表达式语言（CEL）， 直接在 Go 结构体标签中定义复杂验证逻辑， 从而替代手动编写复杂 OpenAPI 模式这一通常容易出错的任务。

现在，Kubernetes 贡献者无需编写自定义验证函数， 而是可以直接在 API 类型定义（types.go）中使用 IDL 标记注释 （例如 +k8s:minimum 或 +k8s:enum）定义验证规则。 validation-gen 工具会解析这些注释，并在编译时自动生成稳健的 API 验证代码。 这降低了维护开销，并确保 API 验证与源代码保持一致和同步。

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

移除 Kubernetes API 类型对 gogo protobuf 的依赖

随着 gogoprotobuf 移除工作的完成， Kubernetes 代码库的安全性和长期可维护性在 Kubernetes v1.36 中迈出重要一步。 这项工作消除了对无人维护的 gogoprotobuf 库的重要依赖； 该库已经成为潜在安全漏洞的来源，也阻碍了现代 Go 语言特性的采用。

项目没有迁移到标准 Protobuf 生成方式，因为这会给 Kubernetes API 类型带来兼容性风险； 相反，项目选择对所需的生成逻辑进行 fork，并将其内置到 k8s.io/code-generator 中。 这种方式在保留现有 API 行为和序列化兼容性的同时， 成功从 Kubernetes 依赖图中消除了无人维护的运行时依赖。 对于 Kubernetes API Go 类型的使用者而言， 这一变更降低了技术债，并避免了与标准 protobuf 库的意外误用。

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

节点日志查询

过去，Kubernetes 要求集群管理员通过 SSH 登录节点， 或实现客户端读取器，以调试与控制平面节点或工作节点相关的问题。 虽然某些问题仍然需要直接访问节点， 但与 kube-proxy 或 kubelet 有关的问题可以通过检查其日志来诊断。 节点日志为集群管理员提供了一种方法： 使用 kubelet API 和 kubectl 插件查看这些日志， 从而简化故障排查，无需登录节点； 这类似于调试与 Pod 或容器相关的问题。 这种方法与操作系统无关，并要求服务或节点将日志写入 /var/log。

此特性在生产工作负载上经过充分性能验证后，于 Kubernetes 1.36 中达到 GA。 它通过 NodeLogQuery 特性门控在 kubelet 上默认启用。 此外，还必须启用 enableSystemLogQuery kubelet 配置选项。

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

支持 Pod 中的用户命名空间

随着对用户命名空间的支持进阶至稳定（GA）， 容器隔离与节点安全在 Kubernetes v1.36 中达到重要成熟度里程碑。 这一期待已久的特性允许将容器的 root 用户映射到主机上的非特权用户， 从而提供关键的纵深防御层： 即使某个进程逃逸出容器，它也不会对底层节点拥有管理权限。

现在，集群操作人员可以放心地为生产工作负载启用这种加固隔离， 以缓解容器逃逸漏洞的影响。 通过将容器内部身份与主机身份解耦， Kubernetes 提供了一种稳健、标准化的机制， 在长期 API 稳定性的完整保障下，保护多租户环境和敏感基础设施免受未授权访问。

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

支持基于 cgroup v2 的 PSI

随着压力停滞信息（PSI）指标导出进阶至稳定（GA）， 节点资源管理和可观测性在 Kubernetes v1.36 中变得更加精确。 此特性使 kubelet 能够报告 CPU、内存和 I/O 的“压力”指标， 相比传统利用率指标，它提供了关于资源竞争的更细粒度视图。

集群操作人员和自动伸缩器可以使用这些指标区分两类系统： 一种只是繁忙，另一种则因资源耗尽而出现停滞。 借助这些信号，用户可以更准确地调整 Pod 资源请求， 提升垂直自动伸缩的可靠性， 并在“吵闹邻居”效应导致应用性能下降或节点不稳定之前发现它们。

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

VolumeSource：OCI 制品和/或镜像

随着 OCI 卷源支持进阶至稳定（GA）， 容器数据分发在 Kubernetes v1.36 中变得更加灵活。 此特性允许 kubelet 直接从任何符合 OCI 标准的仓库拉取和挂载内容， 例如容器镜像或制品仓库， 从而突破了从外部存储提供商或 ConfigMap 挂载卷这一传统要求。

现在，开发者和平台工程师可以将应用数据、模型或静态资产打包为 OCI 制品， 并使用他们已经用于容器镜像的同一套仓库和版本控制工作流将其交付给 Pod。 镜像与卷管理的这种融合简化了 CI/CD 流水线， 减少了只读内容对专用存储后端的依赖， 并确保数据在任何环境中都保持可移植且可安全访问。

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

Beta 阶段的新特性

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

缓解控制器陈旧状态

Kubernetes 控制器中的陈旧状态是一个会影响许多控制器的问题， 并可能以细微方式影响控制器行为。 通常要等到为时已晚，即生产环境中的控制器已经采取了错误操作之后， 人们才会发现，由控制器作者某些底层假设导致的陈旧状态已经成为问题。 这可能会在缓存陈旧期间进行控制器调谐时导致冲突更新或数据损坏。

我们很高兴地宣布，Kubernetes v1.36 包含一些新特性， 有助于缓解控制器陈旧状态，并为控制器行为提供更好的可观测性。 这可以防止基于过时的集群状态视图执行调谐， 而这种调谐往往会导致有害行为。

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

IP/CIDR 验证改进

在 Kubernetes v1.36 中，面向 API IP 和 CIDR 字段的 StrictIPCIDRValidation 特性进阶至 Beta，收紧验证以捕获此前可能漏过的格式错误地址和前缀。 这有助于防止 Service、Pod、NetworkPolicy 或其他资源引用无效 IP 时产生隐蔽配置缺陷； 否则这些缺陷可能导致令人困惑的运行时行为或安全意外。

控制器已经更新，会对写回对象的 IP 进行规范化， 并在遇到已经存储的错误值时发出警告， 因此集群可以逐步收敛到干净、一致的数据。 进入 Beta 后，StrictIPCIDRValidation 已准备好进行更广泛的使用， 随着网络与策略不断演进，它可为操作人员提供更可靠的 IP 相关配置防护。

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

将 kubectl 用户偏好与集群配置分离

用于自定义 kubectl 用户偏好的 .kuberc 特性继续处于 Beta 阶段，并默认启用。 ~/.kube/kuberc 文件允许用户将别名、默认命令行参数和其他个人设置 与保存集群端点和凭据的 kubeconfig 文件分开存放。 这种分离可以防止个人偏好干扰 CI 流水线或共享的 kubeconfig 文件， 同时在不同集群和上下文中保持一致的 kubectl 体验。

在 Kubernetes v1.36 中，.kuberc 得到扩展， 能够为凭据插件定义策略（允许列表或拒绝列表），以强制实施更安全的身份认证实践。 如有需要，用户可以通过设置 KUBECTL_KUBERC=false 或 KUBERC=off 环境变量来禁用此功能。

此项工作是 KEP #3104 的一部分， 由 SIG CLI 牵头，并得到了 SIG Auth 的帮助。

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

在 Kubernetes v1.36 中，MutablePodResourcesForSuspendedJobs 特性进阶至 Beta 并默认启用。 这项更新放宽了 Job 验证，允许在 Job 挂起期间更新容器的 CPU、内存、 GPU 以及扩展资源的请求和限制。

这一能力允许队列控制器和操作人员根据实时集群状况调整批处理工作负载需求。 例如，排队系统可以挂起传入的 Job， 调整其资源需求以匹配可用容量或配额，然后取消挂起。 此特性严格将可变性限制在已挂起的 Job （或其 Pod 已在挂起时终止的 Job）上， 以防止对正在运行的 Pod 造成破坏性变更。

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

受限的身份扮演（Impersonation）

在 Kubernetes v1.36 中，用于用户身份扮演的 ConstrainedImpersonation 特性进阶至 Beta，将历史上“全有或全无”的机制收紧为真正能够遵循最小权限原则的机制。 启用此特性时，身份扮演者必须拥有两组不同的权限： 一组用于扮演给定身份，另一组用于代表该身份执行特定操作。 这可以防止支持工具、控制器或节点代理即使在身份扮演 RBAC 配置错误的情况下， 也通过身份扮演获得超出其自身被允许范围的访问权限。 现有的 impersonate 规则会继续工作， 但 API 服务器会优先使用新的受限检查， 使迁移成为增量过程，而不是一次性切换。 随着 v1.36 中进入 Beta，ConstrainedImpersonation 已经过测试、具备文档， 并已准备好被依赖身份扮演进行调试、代理或节点级控制器的平台团队更广泛采用。

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

Beta 阶段的 DRA 特性

随着若干核心特性进阶至 Beta 并默认启用， 动态资源分配（DRA）框架 在 Kubernetes v1.36 中达到又一个成熟度里程碑。 通过推进可分区设备 和可消耗容量， 这次转变让 DRA 超越了基础分配，允许对 GPU 等硬件进行更细粒度的共享； 同时，设备污点和容忍 确保专用资源只被合适的工作负载使用。

现在，用户可以通过 ResourceClaim 设备状态 以及在 Pod 调度前确保设备挂接的能力， 受益于更可靠且更可观测的资源生命周期。 通过将这些特性与扩展资源支持集成， Kubernetes 为传统设备插件系统提供了一个稳健、生产就绪的替代方案， 使复杂的 AI 与 HPC 工作负载能够以前所未有的精度和运维安全性管理硬件。

此项工作跨越多个 KEP（包括 #5004、#4817、 #5055、#5075、#4815 和 #5007），由 SIG Scheduling 和 SIG Node 牵头完成。

Kubernetes 组件的 Statusz

在 Kubernetes v1.36 中，面向核心 Kubernetes 组件的 ComponentStatusz 特性门控进阶至 Beta， 提供一个默认启用的 /statusz 端点，用于呈现每个组件的实时构建和版本细节。 这个低开销的 z-page 会公开启动时间、运行时长、 Go 版本、二进制版本、仿真版本和最低兼容版本等信息， 使操作人员和开发者无需深入日志或配置，就能快速准确了解正在运行的内容。

此端点默认提供人类可读的文本视图， 并通过显式内容协商提供一个版本化的结构化 API（config.k8s.io/v1beta1）， 以 JSON、YAML 或 CBOR 形式供程序访问。 访问权限授予 system:monitoring 组， 使其与健康和指标端点上的现有保护保持一致，并避免暴露敏感数据。

进入 Beta 后，ComponentStatusz 在所有核心控制平面组件和节点代理程序上默认启用， 并由单元测试、集成测试和端到端测试提供支撑， 因此可以安全地用于生产环境中的可观测性和调试工作流。

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

Kubernetes 组件的 Flagz

在 Kubernetes v1.36 中，面向核心 Kubernetes 组件的 ComponentFlagz 特性门控进阶至 Beta， 标准化了 /flagz 端点，用于公开每个组件启动时实际生效的命令行标志。 这为集群操作人员和开发者提供了组件配置的实时集群内可见性， 使调试意外行为或验证某个标志发布在重启后是否真正生效变得容易得多。

此端点同时支持人类可读的文本视图和版本化的结构化 API（初始为 config.k8s.io/v1beta1）， 因此你既可以在事故期间用 curl 查看它，也可以在准备好后将其接入自动化工具。 访问权限授予 system:monitoring 组，且敏感值可以被遮蔽， 使配置可见性与健康和状态端点周边的现有安全实践保持一致。

进入 Beta 后，ComponentFlagz 现在默认启用，并已在所有核心控制平面组件和节点代理程序中实现； 单元测试、集成测试和端到端测试为其提供支撑，以确保该端点在生产集群中可靠。

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

混合版本代理（又称未知版本互操作代理）

在 Kubernetes v1.36 中，混合版本代理特性在 v1.28 引入的 Alpha 版本基础上进阶至 Beta， 为混合版本集群提供更安全的控制平面升级。 现在，每个 API 请求都可以路由到为所请求的组、版本和资源提供服务的 apiserver 实例， 从而减少因版本偏差导致的 404 和失败。

此特性依赖对等聚合发现，因此各 apiserver 会共享它们公开哪些资源和版本的信息， 随后在需要时使用这些数据透明地重路由请求。 关于被重路由流量和代理行为的新指标， 可帮助操作人员了解请求被转发的频率以及被转发到哪些对等实例。 这些变更结合起来，使在生产环境中运行高可用的混合版本 API 控制平面变得更容易， 同时支持执行多步骤或部分控制平面升级。

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

基于 cgroups v2 的内存 QoS

Kubernetes 现在在 Linux cgroup v2 节点上通过更智能、分层的内存保护增强内存 QoS， 使内核控制更好地与 Pod 请求和限制对齐， 减少共享同一节点的工作负载之间的干扰和抖动。 这一迭代还改进了 kubelet 对 memory.high 和 memory.min 的设置方式， 增加了指标和防护机制以避免活锁， 并引入配置选项，使集群操作人员可以针对其环境调整内存保护行为。

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

Alpha 阶段的新特性

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

基于自定义指标的 HPA 缩容到零

到目前为止，HorizontalPodAutoscaler（HPA）要求至少保留一个活跃副本， 因为它只能基于运行中 Pod 的指标（如 CPU 或内存）计算扩缩容需求。 Kubernetes v1.36 继续推进 Alpha 阶段的 HPA 缩容到零特性（默认禁用）， 允许工作负载在使用 Object 或 External 指标时专门缩容到零个副本。

现在，用户可以进行实验： 在没有待处理工作时让重型工作负载完全空闲，从而显著降低基础设施成本。 虽然此特性仍受 HPAScaleToZero 特性门控控制， 但它使 HPA 即使在没有运行中 Pod 时也能保持活跃， 并在外部指标（例如队列长度）表明有新任务到达时， 自动将 Deployment 扩容回来。

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

Alpha 阶段的 DRA 特性

过去，动态资源分配（DRA）框架缺少与高级控制器的无缝集成， 并且对设备特定元数据或可用性的可见性有限。 Kubernetes v1.36 引入了一批 Alpha 阶段的 DRA 增强， 包括面向工作负载的原生 ResourceClaim 支持， 以及 DRA 原生资源，用于为 CPU 管理提供 DRA 的灵活性。

现在，用户可以利用 Downward API 将复杂资源属性直接暴露给容器， 并受益于改进后的资源可用性可见性，从而实现更可预测的调度。 这些更新结合对设备属性中列表类型的支持， 将 DRA 从低层原语转变为稳健的系统， 能够处理现代 AI 和高性能计算（HPC）栈的复杂网络与计算需求。

此项工作跨越多个 KEP（包括 #5729、#5304、 #5517、#5677 和 #5491）， 由 SIG Scheduling 和 SIG Node 牵头完成。

Kubernetes 指标的原生直方图支持

随着原生直方图支持在 Alpha 阶段引入， 高分辨率监控在 Kubernetes v1.36 中达到新的里程碑。 传统 Prometheus 直方图依赖静态、预定义的桶， 往往迫使用户在数据精度和内存使用之间取舍； 这项更新允许控制平面导出稀疏直方图， 并基于实时数据动态调整其分辨率。

现在，集群操作人员可以捕获 kube-apiserver 和其他核心组件的精确延迟分布， 而无需承担手动管理桶的开销。 这一架构转变确保 SLI 和 SLO 更可靠， 提供高保真热力图，即使在最难预测的工作负载峰值期间也能保持准确。

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

基于清单的准入控制配置

随着 Alpha 阶段的基于清单的准入控制配置引入， 准入控制器管理在 Kubernetes v1.36 中迈向更加声明式且一致的模型。 长期以来，准入插件需要通过分散的命令行参数或独立且复杂的配置文件进行配置。 这一变更允许管理员直接通过结构化清单定义准入控制的期望状态， 从而应对这一长期挑战。

现在，集群操作人员可以使用与其他 Kubernetes 对象相同的版本化、声明式工作流来管理准入插件设置， 显著降低集群升级期间配置漂移和手动错误的风险。 通过将这些配置集中到统一清单中， kube-apiserver 变得更易于审计和自动化， 为更安全、可复现的集群部署铺平道路。

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

CRI 列表流式传输

随着 CRI 列表流式传输在 Alpha 阶段引入， Kubernetes v1.36 使用了新的内部流式操作。 此增强将 kubelet 与容器运行时之间传统的整体式 List 请求 替换为更高效的服务器端流式 RPC， 以解决大规模节点上常见的内存压力和延迟峰值问题。

现在，kubelet 不再等待包含所有容器或镜像数据的单个巨大响应， 而是可以在结果被流式传输时增量处理。 这一转变显著降低了 kubelet 的峰值内存占用， 并提升了高密度节点上的响应能力， 确保即使每个节点上的容器数量持续增长，集群管理也能保持流畅。

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

其他值得注意的变化

Ingress NGINX 退役

为优先保障生态系统的安全，Kubernetes SIG Network 和安全响应委员会（Security Response Committee） 已于 2026 年 3 月 24 日退役 Ingress NGINX。 自该日期起，不再发布后续版本、不再修复缺陷，也不再更新以修复新发现的安全漏洞。 现有 Ingress NGINX 部署将继续运行，Helm Chart 和容器镜像等安装制品也将继续可用。

完整详情请参阅官方退役公告。

卷的 SELinux 标签提速（GA）

Kubernetes v1.36 将 SELinux 卷挂载改进提升为正式可用。 此变更使用 mount -o context=XYZ 选项替代了递归文件重标记， 在挂载时为整个卷应用正确的 SELinux 标签。 它带来更一致的性能，并减少启用 SELinux 强制模式系统上的 Pod 启动延迟。

该特性在 v1.28 作为 Beta 引入，适用于 ReadWriteOncePod 卷。 在 v1.32，它新增了指标和退出选项（securityContext.seLinuxChangePolicy: Recursive）以帮助发现冲突。 现在在 v1.36，它进入稳定（GA）阶段，并默认适用于所有卷； Pod 或 CSIDriver 可通过 spec.seLinuxMount 显式启用。

不过，我们预计该特性在未来 Kubernetes 版本中可能带来破坏性变更风险， 潜在原因是在同一节点上的特权 Pod 和非特权 Pod 之间共享同一个卷。

开发者有责任为 Pod 设置 seLinuxChangePolicy 字段和 SELinux 卷标签。 无论他们是在编写 Deployment、StatefulSet、DaemonSet， 还是包含 Pod 模板的自定义资源， 对这些设置不够谨慎都可能导致一系列问题， 例如 Pod 共享卷时无法正确启动。

Kubernetes v1.36 是审计集群的理想版本。 要了解更多信息，请查看博客 SELinux Volume Label Changes goes GA (and likely implications in v1.37)。

有关此增强的更多细节，请参阅 KEP-1710：加快递归 SELinux 标签变更。

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

进阶至稳定阶段

这里列出了所有进阶至稳定（也称为正式发布，GA）阶段的特性。 有关包括新特性以及从 Alpha 进阶至 Beta 的完整更新列表，请参阅发布说明。

此版本共有 18 项增强提升至稳定阶段：

弃用、移除与社区更新

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

Service .spec.externalIPs 的弃用

在本次发布中，Service spec 中的 externalIPs 字段被弃用。 这意味着此功能仍然存在，但将在 Kubernetes 的未来版本中不再工作。 如果你当前依赖此字段，应计划迁移。 这个字段多年来一直是已知的安全隐患， 会让集群流量面临中间人攻击风险，如 CVE-2020-8554 所述。 从 Kubernetes v1.36 起，使用它时你会看到弃用警告，并计划在 v1.43 完全移除。

如果你的 Service 仍依赖 externalIPs， 可考虑使用 LoadBalancer 服务处理云托管入口、使用 NodePort 做简单端口暴露， 或使用 Gateway API 以更灵活且更安全的方式处理外部流量。

有关此字段及其弃用的更多细节，请参阅外部 IP， 或阅读 KEP-5707：弃用 service.spec.externalIPs。

移除 gitRepo 卷驱动

gitRepo 卷类型自 v1.11 起已被弃用。 在 Kubernetes v1.36 中，gitRepo 卷插件被永久禁用，且无法重新启用。 此变更可保护集群免受关键安全问题影响， 因为使用 gitRepo 可能让攻击者以 root 身份在节点上运行代码。

尽管 gitRepo 多年来一直处于弃用状态，且已有更好的替代方案被推荐， 但在此前版本中它在技术上仍可使用。 从 v1.36 开始，这条路径将被永久关闭， 因此任何依赖 gitRepo 的现有工作负载都需要迁移到受支持方案， 例如 init 容器或外部 git-sync 风格工具。

有关此移除的更多细节，请参阅 KEP-5040：移除 gitRepo 卷驱动。

发布说明

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

可用性

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

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

发布团队

Kubernetes 的存在离不开社区的支持、投入和辛勤工作。 每个发布团队都由专注的社区志愿者组成， 他们共同构建你所依赖的 Kubernetes 发布版本中的诸多组成部分。 这需要来自社区各个角落的专业能力： 从代码本身到文档与项目管理。

我们感谢整个发布团队 为向社区交付 Kubernetes v1.36 所付出的辛勤时间。 发布团队成员既包括首次参与的 shadow，也包括经过多个发布周期锤炼、再次回归的团队负责人。 我们特别感谢发布负责人 Ryota Sawada： 他带领我们走过一个成功的发布周期， 以亲力亲为的方式解决挑战， 并带来推动社区前行的能量与关怀。

项目活跃度

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

在 v1.36 发布周期（从 2026 年 1 月 12 日到 2026 年 4 月 22 日，共 15 周）期间， Kubernetes 收到了来自多达 106 家公司与 491 名个人的贡献。 在更广泛的云原生生态中，这一数字上升到 370 家公司，共计 2235 名贡献者。

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

数据来源：

活动更新

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

2026 年 4 月

2026 年 5 月

2026 年 6 月

2026 年 7 月

2026 年 9 月

2026 年 10 月

2026 年 11 月

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

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

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

参与其中

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