Kubernetes v1.36：Haru

原文链接: https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/

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

与之前的版本类似，Kubernetes v1.36 的发布引入了新的稳定版、Beta 版和 Alpha 版功能。持续交付高质量版本彰显了我们开发周期的稳健性以及社区的大力支持。

此版本包含 70 项增强功能。其中，18 项升级为稳定版（Stable），25 项进入 Beta 版，25 项升级为 Alpha 版。

此版本还包含一些弃用和移除内容；请务必阅读相关说明。

发布主题与 Logo

我们以 Kubernetes v1.36 开启 2026 年，这个版本随着季节更替、山间光影流转而到来。ハル（Haru）在日语中承载着多重含义；其中与我们最亲近的是 春（春天）、晴れ（hare，晴朗的天空）和 遥か（haruka，遥远的、远方的）。一个季节、一片天空、一个地平线。在接下来的内容中，你将找到这三者。

该标志由 avocadoneko / Natsuho Ide 创作，灵感来源于 葛饰北斋 的《富岳三十六景》（Fugaku Sanjūrokkei），正是同一系列诞生了闻名世界的《神奈川冲浪里》。我们的 v1.36 标志重新诠释了该系列中最著名的版画之一《凯风快晴》（Gaifū Kaisei），也被称为赤富士（Aka Fuji）：夏日的黎明中，山体被映照成红色，经过漫长的融雪后裸露无雪。三十六景这个数字与 v1.36 相伴显得恰如其分，也提醒我们北斋并未止步于此。¹ 守护着这幅景象的是 Kubernetes 舵轮，它与富士山一同镶嵌在天空中。

富士山脚下坐着 Stella（左）和 Nacho（右），两只戴着 Kubernetes 舵轮项圈的猫，它们扮演着 狛犬 的角色——守护日本神社的成对狮犬守护者。成对，因为没有任何事物是独自守护的。Stella 和 Nacho 代表着一群更庞大的爪印：SIG 和工作组、维护者和审阅者、文档、博客和翻译背后的人们、发布团队、迈出第一步的首次贡献者，以及一季又一季回归的终身贡献者。Kubernetes v1.36 一如既往，由众多双手共同托举。

标志中赤富士上刷写的书法是“晴れに翔け”（hare ni kake），“翱翔于晴空”。这是一副对联的上半句，因太长而无法完全放在山上：

晴れに翔け、未来よ明け

hare ni kake, asu yo ake

“翱翔于晴空；向着明天的日出。”²

这是我们为这个版本承载的愿望：翱翔于晴空，为了版本本身，为了项目，也为了所有共同交付它的人。赤富士上破晓的黎明并非终点，而是一个通道：这个版本将我们带向下一个，而下一个又带向再下一个，向着任何单一视角都无法容纳的遥远地平线前进。

¹ 该系列大受欢迎，北斋又增加了十幅版画，总数达到四十六幅。
² 未来（mirai）在最广泛的意义上意味着“未来”，不仅仅是明天，而是所有尚未到来的一切。通常读作 mirai；此处采用非正式读法 asu。

关键更新聚焦

Kubernetes v1.36 充满了新功能和改进。以下是发布团队希望重点介绍的一些精选更新！

稳定版：细粒度 API 授权

代表 Kubernetes SIG Auth 和 SIG Node，我们很高兴地宣布，细粒度的 kubelet API 授权在 Kubernetes v1.36 中已毕业至通用可用性（GA）！

KubeletFineGrainedAuthz 特性门控在 Kubernetes v1.32 中作为可选加入的 alpha 特性引入，随后在 v1.33 中升级为 beta（默认启用）。现在，该特性已普遍可用。此特性实现了对 kubelet 的 HTTPS API 更精确、最小权限的访问控制，取代了为常见监控和可观测性用例授予过于宽泛的 nodes/proxy 权限的需求。

这项工作由 SIG Auth 和 SIG Node 领导的 KEP #2862 的一部分完成。

Beta：资源健康状态

在 v1.34 版本之前，Kubernetes 缺乏一种原生方式来报告已分配设备的健康状况，这使得诊断由硬件故障引起的 Pod 崩溃变得困难。基于 v1.31 中最初专注于设备插件的 alpha 版本，Kubernetes v1.36 通过将每个 Pod 的 .status 中的 allocatedResourcesStatus 字段提升至 beta 来扩展此功能。该字段为所有专用硬件提供了统一的健康报告机制。

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

这项工作由 SIG Node 领导的 KEP #4680 的一部分完成。

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

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

Kubernetes v1.35 已通过要求在任何 Pod 绑定到节点之前，必须有最低数量的 Pod 可调度，从而支持组调度（gang scheduling）。v1.36 更进一步，引入了新的 PodGroup 调度周期，该周期以原子方式评估整个组：要么组内所有 Pod 一起绑定，要么一个都不绑定。

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

升级为稳定版的特性

以下是 v1.36 发布后现已稳定的一些改进精选。

卷组快照（Volume group snapshots）

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

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

可变卷挂载限制（Mutable volume attach limits）

在 Kubernetes v1.36 中，可变的 CSINode 可分配资源 特性升级为稳定版。此增强允许容器存储接口（Container Storage Interface，CSI）驱动动态更新节点可处理的卷的最大数量报告。

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

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

用于 ServiceAccount 令牌外部签名的 API

在 Kubernetes v1.36 中，用于服务账户的外部 ServiceAccount 令牌签名器 特性升级为稳定版，使得可以将令牌签名卸载到外部系统，同时仍与 Kubernetes API 干净集成。集群现在可以依赖外部 JWT 签名器来签发遵循标准服务账户令牌格式的投射服务账户令牌，包括在需要时支持延长过期时间。这对于已经依赖外部身份或密钥管理系统的集群尤其有用，允许 Kubernetes 集成而无需在控制平面内重复管理密钥。

kube-apiserver 被配置为从外部签名器发现公钥、缓存它们，并验证并非自身签发的令牌，因此现有的身份验证和授权流程继续按预期工作。在 Alpha 和 Beta 阶段，外部签名器插件、路径验证和 OIDC 发现的 API 和配置已得到强化，以安全地处理实际部署和轮换模式。

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

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

DRA 特性升级为稳定版

动态资源分配（Dynamic Resource Allocation，DRA）生态系统的一部分在 Kubernetes v1.36 中达到完整的生产成熟度，关键治理和选择特性升级为稳定版。DRA 管理员访问 过渡到 GA 为集群管理员提供了一个永久、安全的框架，用于全局访问和管理硬件资源，而优先级列表 的稳定化确保了资源选择逻辑在所有集群环境中保持一致且可预测。

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

这项工作作为 KEP #5018 和 #4816 的一部分完成，由 SIG Auth 和 SIG Scheduling 领导。

Mutating admission policies（变更准入策略）

在 Kubernetes v1.36 中，声明式集群管理达到了新的复杂程度，MutatingAdmissionPolicies 毕业为 Stable（稳定版）。这一里程碑提供了一种原生、高性能的替代方案，取代了传统的 Webhook，允许管理员直接在 API 服务器中使用 Common Expression Language（CEL，通用表达式语言）定义资源变更，从而完全替代了许多常见用例中对外部基础设施的需求。

现在，集群操作员可以修改传入请求，而无需承担管理自定义准入 Webhook 所带来的延迟和操作复杂性。通过将变更逻辑移至声明式、版本化的策略中，组织可以实现更可预测的集群行为、减少网络开销，并强化安全模型，同时享有长期 API 稳定性的全面保障。

这项工作作为 KEP #3962 的一部分完成，由 SIG API Machinery 领导。

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

在 Kubernetes v1.36 中，自定义资源的开发达到了新的效率水平，声明式验证（使用 validation-gen）毕业为 Stable（稳定版）。这一里程碑取代了手动编写复杂 OpenAPI 模式这一容易出错的任务，允许开发人员直接在 Go 结构体标签中使用 Common Expression Language（CEL）定义复杂的验证逻辑。

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

这项工作作为 KEP #5073 的一部分完成，由 SIG API Machinery 领导。

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

在 Kubernetes v1.36 中，Kubernetes 代码库的安全性和长期可维护性迈出了重要一步，完成了 gogoprotobuf 的移除。这一举措消除了对未维护的 gogoprotobuf 库的重大依赖，该库已成为潜在安全漏洞的来源，并阻碍了采用现代 Go 语言特性。

由于迁移到标准 Protobuf 生成会对 Kubernetes API 类型带来兼容性风险，项目选择在 k8s.io/code-generator 中分叉并内部化所需的生成逻辑。这种方法成功地从 Kubernetes 依赖图中消除了未维护的运行时依赖，同时保留了现有的 API 行为和序列化兼容性。对于 Kubernetes API Go 类型的消费者来说，这一变更减少了技术债务，并防止了因使用标准 protobuf 库而导致的意外误用。

这项工作作为 KEP #5589 的一部分完成，由 SIG API Machinery 领导。

Node log query（节点日志查询）

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

在 Kubernetes 1.36 中，此功能在生产工作负载上经过彻底的性能验证后达到 GA（正式发布），默认通过 NodeLogQuery 特性门控在 kubelet 上启用。此外，还必须启用 enableSystemLogQuery kubelet 配置选项。

这项工作作为 KEP #2258 的一部分完成，由 SIG Windows 领导。

Support User Namespaces in pods（在 Pod 中支持用户命名空间）

容器隔离与节点安全在 Kubernetes v1.36 中达到了一个重要的成熟里程碑：用户命名空间（User Namespaces）支持正式毕业为稳定版（Stable）。这一期待已久的功能通过将容器的 root 用户映射到主机上的非特权用户，提供了关键的纵深防御层，确保即使进程逃逸出容器，也无法对底层节点拥有管理权限。

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

这项工作由 SIG Node 主导，作为 KEP #127 的一部分完成。

基于 cgroupv2 的 PSI 支持

Kubernetes v1.36 中，节点资源管理和可观测性变得更加精确，因为压力失速信息（Pressure Stall Information, PSI）指标的导出已毕业为稳定版。该功能使 kubelet 能够报告 CPU、内存和 I/O 的“压力”指标，相比传统的利用率指标，提供了更细粒度的资源争用视图。

集群运维人员和自动扩缩器可以使用这些指标来区分系统是单纯繁忙还是因资源耗尽而主动停滞。通过利用这些信号，用户可以更精确地调整 Pod 资源请求，提高垂直自动扩缩的可靠性，并在噪声邻居效应导致应用性能下降或节点不稳定之前检测到它。

这项工作由 SIG Node 主导，作为 KEP #4205 的一部分完成。

卷源：OCI 制品和/或镜像

Kubernetes v1.36 中，容器数据的分发变得更加灵活，因为 OCI 卷源 支持已毕业为稳定版。该功能超越了传统从外部存储提供商或 ConfigMap 挂载卷的需求，允许 kubelet 直接从任何符合 OCI 标准的仓库（例如容器镜像或制品仓库）拉取并挂载内容。

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

这项工作由 SIG Node 主导，作为 KEP #4639 的一部分完成。

Beta 阶段的新功能

以下是 v1.36 发布后进入 Beta 阶段的部分改进。

控制器陈旧性缓解

Kubernetes 控制器中的陈旧性是一个影响许多控制器的问题，可能会微妙地影响控制器行为。通常直到为时已晚——当生产环境中的控制器已经执行了错误操作时——才会发现陈旧性是由于控制器作者做出的某些底层假设而成为问题。这可能导致在缓存陈旧期间控制器协调时出现冲突更新或数据损坏。

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

这项工作由 SIG API Machinery 主导，作为 KEP #5647 的一部分完成。

IP/CIDR 验证改进

在 Kubernetes v1.36 中，针对 API IP 和 CIDR 字段的 StrictIPCIDRValidation 功能已进入 Beta 阶段，它加强了验证，能够捕获之前漏过的格式错误的地址和前缀。这有助于防止微妙的配置错误，例如 Service、Pod、NetworkPolicy 或其他资源引用了无效 IP，否则可能导致令人困惑的运行时行为或安全意外。

控制器已更新，能够规范化它们写回对象中的 IP，并在遇到已存储的错误值时发出警告，从而使集群能够逐步收敛到干净、一致的数据。随着 Beta 阶段的到来，StrictIPCIDRValidation 已准备好更广泛地使用，为运维人员在随着时间推移演进网络和策略时提供更可靠的 IP 相关配置护栏。

这项工作由 SIG Network 主导，作为 KEP #4858 的一部分完成。

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

用于自定义 kubectl 用户偏好的 .kuberc 特性

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

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

这项工作由 SIG CLI 主导，在 SIG Auth 的协助下，作为 KEP #3104 的一部分完成。

Job 暂停时可变的容器资源

在 Kubernetes v1.36 中，MutablePodResourcesForSuspendedJobs 特性升级为 beta 并默认启用。此更新放宽了 Job 的验证规则，允许在 Job 暂停时更新容器的 CPU、内存、GPU 以及扩展资源的请求和限制。

此功能允许队列控制器和操作员根据实时集群条件调整批处理工作负载的需求。例如，排队系统可以暂停传入的 Job，调整其资源需求以匹配可用容量或配额，然后取消暂停。该特性严格限制仅对暂停的 Job（或暂停时其 Pod 已被终止的 Job）进行可变性操作，以防止对正在运行的 Pod 造成破坏性更改。

这项工作由 SIG Apps 主导，作为 KEP #5440 的一部分完成。

受限的模拟（Impersonation）

在 Kubernetes v1.36 中，用于用户模拟的 ConstrainedImpersonation 特性升级为 beta，将历史上全有或全无的机制收紧为能够真正遵循最小权限原则的机制。启用此特性后，模拟者必须拥有两组不同的权限：一组用于模拟给定身份，另一组用于代表该身份执行特定操作。这可以防止支持工具、控制器或节点代理利用模拟获得比自身允许范围更广的访问权限，即使其模拟 RBAC 配置错误。现有的模拟规则仍然有效，但 API 服务器会优先执行新的受限检查，从而实现渐进式过渡，而非一次性切换。随着 v1.36 中 beta 版本的发布，ConstrainedImpersonation 已经过测试、文档化，并可供依赖模拟进行调试、代理或节点级控制的平台团队广泛采用。

这项工作由 SIG Auth 主导，作为 KEP #5284 的一部分完成。

DRA 特性进入 beta 阶段

动态资源分配（DRA） 框架在 Kubernetes v1.36 中达到了另一个成熟里程碑，多项核心特性升级为 beta 并默认启用。这一转变通过升级可分区设备和可消耗容量，使 DRA 超越了基本分配，允许对 GPU 等硬件进行更细粒度的共享，同时设备污点和容忍度确保专用资源仅由适当的工作负载使用。

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

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

Kubernetes 组件的 Statusz

（注：原文中此部分仅有一个标题，无正文内容。翻译时保留标题格式，并可根据上下文补充说明，但严格遵循原文，仅翻译标题。）

Kubernetes 组件的 Statusz

在 Kubernetes v1.36 中，核心 Kubernetes 组件的 ComponentStatusz 特性门控（feature gate）升级至 Beta 阶段，提供了一个默认启用的 /statusz 端点，用于展示每个组件的实时构建和版本详细信息。这个低开销的 z-page 会暴露诸如启动时间、运行时长、Go 版本、二进制版本、模拟版本（emulation version）以及最低兼容版本等信息，使运维人员和开发者无需翻阅日志或配置文件，即可快速了解当前运行的具体内容。

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

随着 Beta 阶段的到来，ComponentStatusz 在所有核心控制平面组件和节点代理（node agents）上默认启用，并配有单元测试、集成测试和端到端测试，确保其可在生产环境中安全地用于可观测性和调试工作流。

这项工作由 SIG Instrumentation 主导，作为 KEP #4827 的一部分完成。

Kubernetes 组件的 Flagz

在 Kubernetes v1.36 中，核心 Kubernetes 组件的 ComponentFlagz 特性门控升级至 Beta 阶段，标准化了一个 /flagz 端点，用于暴露每个组件启动时所使用的有效命令行标志（command-line flags）。这为集群运维人员和开发者提供了组件配置的实时、集群内可见性，使得调试意外行为或验证标志（flag）在重启后是否实际生效变得更加容易。

该端点同时支持人类可读的文本视图和版本化的结构化 API（初始版本为 config.k8s.io/v1beta1），因此你既可以在事件发生时通过 curl 命令查看，也可以在准备就绪后将其接入自动化工具。访问权限授予 system:monitoring 组，敏感值可以被编辑（redacted），从而使配置洞察与健康端点和状态端点现有的安全实践保持一致。

随着 Beta 阶段的到来，ComponentFlagz 现已默认启用，并在所有核心控制平面组件和节点代理上实现，配有单元测试、集成测试和端到端测试，以确保该端点在生产集群中可靠运行。

这项工作由 SIG Instrumentation 主导，作为 KEP #4828 的一部分完成。

混合版本代理（Mixed version proxy，又称 unknown version interoperability proxy）

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

该特性依赖于对等聚合发现（peer-aggregated discovery），因此 API 服务器之间会共享它们所暴露的资源与版本信息，并在需要时利用这些数据透明地重新路由请求。新增的关于重路由流量和代理行为的指标，帮助运维人员了解请求被转发的频率以及转发到了哪些对等节点。这些改进共同使得在生产环境中运行高可用、混合版本的 API 控制平面更加容易，同时能够执行多步骤或部分控制平面升级。

这项工作由 SIG API Machinery 主导，作为 KEP #4020 的一部分完成。

基于 cgroups v2 的内存 QoS（Memory QoS）

Kubernetes 现在通过更智能、分层的内存保护机制，增强了 Linux cgroup v2 节点上的内存 QoS，使内核控制与 Pod 请求和限制更好地对齐，从而减少共享同一节点的工作负载之间的干扰和抖动（thrashing）。本次迭代还优化了 kubelet 对 memory.high 和 memory.min 的编程方式，增加了指标和安全措施以避免活锁（livelocks），并引入了配置选项，使集群运维人员能够根据自身环境调整内存保护行为。

这项工作由 SIG Node 主导，作为 KEP #2570 的一部分完成。

Alpha 阶段的新特性

以下是 v1.36 发布后进入 Alpha 阶段的部分改进。

自定义指标的 HPA 缩容至零

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

现在，用户可以通过在无待处理任务时完全闲置繁重工作负载，大幅降低基础设施成本。该功能仍处于 HPAScaleToZero 特性门控（feature gate）之后，但它允许 HPA 在运行 Pod 数量为零时保持活跃，一旦外部指标（如队列长度）指示有新任务到达，即可自动将部署重新扩容。

这项工作由 SIG Autoscaling 主导，作为 KEP #2021 的一部分完成。

DRA 特性进入 Alpha 阶段

历史上，动态资源分配（Dynamic Resource Allocation，DRA）框架缺乏与高层控制器的无缝集成，并且对设备特定元数据或可用性的可见性有限。Kubernetes v1.36 引入了一系列 Alpha 阶段的 DRA 增强功能，包括对工作负载的原生 ResourceClaim 支持，以及 DRA 原生资源，为 CPU 管理提供 DRA 的灵活性。

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

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

Kubernetes 指标的原生直方图支持

Kubernetes v1.36 引入了 Alpha 阶段的原生直方图支持，标志着高分辨率监控达到了一个新的里程碑。传统的 Prometheus 直方图依赖静态、预定义的桶（bucket），往往需要在数据精度和内存使用之间做出妥协，而此次更新允许控制平面导出稀疏直方图，这些直方图能够根据实时数据动态调整分辨率。

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

这项工作由 SIG Instrumentation 主导，作为 KEP #5808 的一部分完成。

基于清单的准入控制配置

Kubernetes v1.36 引入了 Alpha 阶段的基于清单的准入控制（manifest-based admission control）配置，使准入控制器的管理迈向更声明式、更一致的模型。这一变化解决了长期以来通过分散的命令行标志或单独的复杂配置文件来配置准入插件的挑战，允许管理员直接通过结构化清单定义准入控制的期望状态。

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

这项工作由 SIG API Machinery 主导，作为 KEP #5793 的一部分完成。

CRI 列表流式传输

Kubernetes v1.36 引入了 Alpha 阶段的CRI 列表流式传输（CRI list streaming），采用了新的内部流式传输操作。这一增强功能通过将 kubelet 与容器运行时之间传统的、单一的 List 请求替换为更高效的服务器端流式 RPC，解决了大规模节点上常见的内存压力和延迟峰值问题。

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

这项工作由 SIG Node 主导，作为 KEP #5825 的一部分完成。

其他值得注意的变化

Ingress NGINX 退役

为了优先保障生态系统的安全，Kubernetes SIG Network 和安全响应委员会（Security Response Committee）已于 2026 年 3 月 24 日将 Ingress NGINX 退役。自该日期起，不再发布任何新版本、错误修复或安全漏洞更新。现有的 Ingress NGINX 部署将继续运行，安装工件（如 Helm chart 和容器镜像）仍将可用。

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

更快的 SELinux 卷标签设置（正式发布）

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

该功能在 v1.28 中作为测试版（beta）引入，适用于 ReadWriteOncePod 卷。在 v1.32 中，它增加了指标和退出选项（securityContext.seLinuxChangePolicy: Recursive），以帮助捕获冲突。现在在 v1.36 中，它达到稳定版（Stable），并默认应用于所有卷，Pod 或 CSIDriver 可通过 spec.seLinuxMount 选择加入。

然而，我们预计此功能可能会在未来的 Kubernetes 版本中带来破坏性变更的风险，尤其是在同一节点上特权 Pod 与非特权 Pod 共享一个卷的情况下。

开发人员有责任在 Pod 上设置 seLinuxChangePolicy 字段和 SELinux 卷标签。无论他们编写的是 Deployment、StatefulSet、DaemonSet 还是包含 Pod 模板的自定义资源，对这些设置掉以轻心都可能导致一系列问题，例如当 Pod 共享卷时 Pod 无法正常启动。

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

有关此增强功能的更多详细信息，请参阅 KEP-1710: Speed up recursive SELinux label change。

v1.36 中的毕业、弃用和移除

毕业至稳定版

以下列出了所有毕业至稳定版（即通用可用性）的功能。有关包括新功能以及从 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 以更灵活、更安全的方式处理外部流量。

有关此字段及其弃用的更多详细信息，请参阅 External IPs 或阅读 KEP-5707: Deprecate service.spec.externalIPs。

移除 gitRepo 卷驱动

gitRepo 卷类型自 v1.11 起已被弃用。对于 Kubernetes v1.36，gitRepo 卷插件被永久禁用且无法重新启用。这项变更可以保护集群免受一个严重安全问题的威胁，在该问题中，使用 gitRepo 可能让攻击者在节点上以 root 身份运行代码。

尽管 gitRepo 已被弃用多年，且社区早已推荐了更好的替代方案，但在之前的版本中技术层面仍有可能使用它。从 v1.36 开始，这条路被彻底关闭，因此任何依赖 gitRepo 的现有工作负载都需要迁移到受支持的方法，例如 init 容器或外部的 git-sync 风格工具。

关于此次移除的更多详情，请参考 KEP-5040: Remove gitRepo volume driver

发布说明

请在我们的 release notes 中查看 Kubernetes v1.36 版本的完整详情。

可用性

Kubernetes v1.36 可在 GitHub 或 Kubernetes 下载页面 上下载。

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

发布团队

Kubernetes 的成就离不开社区的支持、奉献和辛勤工作。每个发布团队都由热心的社区志愿者组成，他们共同努力构建构成您所依赖的 Kubernetes 发布版本的众多组件。这需要社区各个角落的人们具备专业技能，从代码本身到其文档和项目管理。

我们要感谢整个 发布团队 为向社区交付 Kubernetes v1.36 版本所付出的无数小时辛勤工作。发布团队的成员既有首次参与的影子成员，也有经过多个发布周期锤炼、经验丰富的回归团队负责人。特别感谢我们的发布负责人 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 进行评论。如果您有兴趣贡献，请访问我们的贡献者网站上的 开始使用 页面。

本数据来源：

活动更新

探索即将举行的 Kubernetes 和云原生活动，包括 KubeCon + CloudNativeCon、KCD 以及世界范围内的其他重要会议。保持关注并参与 Kubernetes 社区！

2026 年 4 月

2026 年 5 月

2026年6月

2026年7月

2026年9月

2026年10月

2026年11月

你可以在此处找到最新活动详情。

即将发布的版本网络研讨会

欢迎加入 Kubernetes v1.36 版本团队的成员，参加2026年5月20日星期三下午4:00（UTC），了解此版本的重点内容。更多信息和注册，请访问 CNCF 在线项目网站的活动页面。

参与其中

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

标签

实时焦点

“2025 上海开源创新菁英奖”评选通知
2024年度上海开源创新卓越成果奖评选结果公告
上海开源信息技术协会第二届会员大会暨第二届理事会第一次会议顺利召开
协会秘书处赴上海浦东国际金融学会交流学习