正文：Kubernetes v1.36：ハル（Haru）

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

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

此版本包含 70 项增强功能。在这些增强功能中，18 项已升级为稳定版，25 项进入 Beta 版，25 项已升级为 Alpha 版。

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

发布主题与标志

我们以 Kubernetes v1.36 开启 2026 年，这一版本在季节更迭、山间光影变换之时到来。ハル（Haru）在日语中是一个承载多重含义的发音；其中我们最珍视的包括 春（spring）、晴れ（hare，晴朗天空）和 遥か（haruka，遥远的、远方的）。一个季节，一片天空，一道地平线。你将在下文中看到这三者。

该标志由 avocadoneko / Natsuho Ide 创作，灵感来自 Katsushika Hokusai 的《富嶽三十六景》（Thirty-six Views of Mount Fuji，Fugaku Sanjūrokkei），正是这一系列让世界认识了《神奈川冲浪里》（The Great Wave off Kanagawa）。我们的 v1.36 标志重新演绎了该系列中最著名的版画之一《凱風快晴》（Fine Wind, Clear Morning，Gaifū Kaisei），又名《赤富士》（Red Fuji，Aka Fuji）：夏日黎明中被照成红色的山峰，在漫长融雪之后已无积雪。三十六景这个数字与 v1.36 相得益彰，也提醒我们，即便 Hokusai 也没有止步于此。1 守望这一景象的是 Kubernetes 舵轮，它与山峰一同置于天空之中。

在 Fuji 脚下坐着 Stella（左）和 Nacho（右），两只猫的项圈上戴着 Kubernetes 头盔，象征着 komainu 的角色——守护日本神社的一对狮犬守卫。之所以成对，是因为没有什么是独自守护的。Stella 和 Nacho 代表着一支规模大得多的“爪子”队伍：SIG 和工作组、维护者和评审者、文档、博客和翻译背后的人们、发布团队、迈出第一步的首次贡献者，以及一季又一季回归的长期贡献者。Kubernetes v1.36 一如既往，由众人共同托举。

标志中掠过 Red Fuji 的书法是「晴れに翔け」（hare ni kake），意为“飞向晴空”。它是一副对联的上半句，整副对联太长，无法完整放在山上：

晴れに翔け、未来よ明け hare ni kake, asu yo ake “飞向晴空；奔向明日的日出。”2

这正是我们对本次发布所承载的愿望：飞向晴空，为了这次发布本身，为了这个项目，也为了所有共同交付它的人。Red Fuji 上破晓的晨光并非终点，而是一段通途：这次发布将我们带向下一次，而下一次又通向再下一次，直至远超任何单一视野所能容纳的地平线。

1. 该系列大受欢迎，以至于 Hokusai 又增加了十幅版画，使总数达到四十六幅。2. 未来在最广泛的意义上指“未来”，不仅仅是明天，而是所有尚未到来的事物。它通常读作 mirai；在这里采用非正式读法 asu。

重点更新聚焦

Kubernetes v1.36 带来了大量新功能和改进。以下是发布团队希望重点介绍的几项精选更新！

稳定版：细粒度 API 授权

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

KubeletFineGrainedAuthz 功能门控作为可选择启用的 alpha 功能在 Kubernetes v1.32 中引入，随后在 v1.33 中毕业至 beta（默认启用）。现在，该功能已正式可用。此功能支持对 kubelet 的 HTTPS API 进行更精确、最小权限的访问控制，取代了在常见监控和可观测性用例中授予过于宽泛的 nodes/proxy 权限的需求。

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

Beta：资源健康状态

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

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

这项工作是作为 SIG Node 牵头的 KEP #4680 的一部分完成的。

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

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

这项工作通过多个 KEP 完成（包括 #4671、#5547、#5832、#5732 和 #5710），由 SIG Scheduling 和 SIG Apps 主导。

升级为稳定版的功能

以下精选列出了在 v1.36 发布后现已达到稳定状态的一些改进。

卷组快照

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

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

可变卷挂载限制

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

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

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

用于 ServiceAccount 令牌外部签名的 API

在 Kubernetes v1.36 中，服务账号的外部 ServiceAccount 令牌签名器功能晋升为稳定版，使得可以将令牌签名卸载到外部系统，同时仍能与 Kubernetes API 清晰集成。集群现在可以依赖外部 JWT 签名器来签发符合标准服务账号令牌格式的投射服务账号令牌，并在需要时支持延长过期时间。这对于已经依赖外部身份或密钥管理系统的集群尤其有用，使 Kubernetes 能够在不在控制平面内部重复进行密钥管理的情况下完成集成。

kube-apiserver 已连接为可从外部签名器发现公钥、缓存这些公钥，并验证并非由其自身签名的令牌，因此现有的身份认证和授权流程会继续按预期工作。在 alpha 和 beta 阶段，外部签名器插件的 API 和配置、路径验证以及 OIDC 发现都得到了强化，以安全处理真实部署和轮换模式。

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

这项工作是由 SIG Auth 牵头的 KEP #740 的一部分。

DRA 功能升级为稳定版

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

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

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

变更准入策略

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

现在，集群运维人员可以修改传入请求，而无需承担管理自定义准入 webhook 所带来的延迟和运维复杂性。通过将变更逻辑移入声明式、版本化的策略中，组织可以实现更可预测的集群行为、降低网络开销，并在长期 API 稳定性的充分保证下建立更强化的安全模型。

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

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

随着声明式验证（通过 validation-gen）在 Kubernetes v1.36 中升至 Stable，自定义资源的开发效率达到了新的水平。这一里程碑让开发者能够直接在 Go 结构体标签中使用通用表达式语言（CEL）定义复杂的验证逻辑，从而取代手动编写复杂 OpenAPI 架构这一繁琐且往往容易出错的任务。

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

这项工作是由 SIG API Machinery 牵头的 KEP #5073 的一部分。

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

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

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

这项工作是由 SIG API Machinery 牵头的 KEP #5589 的一部分。

节点日志查询

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

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

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

在 Pod 中支持 User Namespaces

随着对 User Namespaces 的支持升级为 Stable，Kubernetes v1.36 在容器隔离和节点安全方面达到了一个重要的成熟里程碑。这项期待已久的功能通过允许将容器的 root 用户映射为宿主机上的非特权用户，提供了关键的纵深防御层，确保即使某个进程逃逸出容器，也不会对底层节点拥有管理权限。

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

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

基于 cgroupv2 支持 PSI

随着 Pressure Stall Information（PSI）指标导出在 Kubernetes v1.36 中毕业为稳定版，节点资源管理和可观测性变得更加精确。此功能使 kubelet 能够报告 CPU、内存和 I/O 的“压力”指标，与传统利用率指标相比，能够更细粒度地反映资源争用情况。

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

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

卷来源：OCI 工件和/或镜像

随着 OCI 卷来源支持在 Kubernetes v1.36 中升级为稳定版，容器数据的分发变得更加灵活。该功能不再局限于从外部存储提供商或配置映射挂载卷的传统要求，而是允许 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 阶段，加强了验证，以捕获此前可能漏过的格式错误的地址和前缀。这有助于防止一些细微的配置错误，例如 Services、Pods、NetworkPolicies 或其他资源引用无效 IP；否则，这些错误可能导致令人困惑的运行时行为或安全意外。

控制器已更新，会对其写回对象中的 IP 进行规范化，并在遇到已存储的不良值时发出警告，从而使集群能够逐步收敛到干净、一致的数据。随着进入 beta 阶段，StrictIPCIDRValidation 已准备好更广泛地使用，为操作人员在网络和策略随时间演进时，围绕 IP 相关配置提供更可靠的防护。

这项工作是 SIG Network 牵头的 KEP #4858 的一部分。

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

用于自定义 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 的一部分完成的。

受限模拟

在 Kubernetes v1.36 中，用于用户模拟的 ConstrainedImpersonation 功能升至 beta 阶段，将一个历来“全有或全无”的机制收紧为真正能够遵循最小权限原则的机制。启用此功能后，模拟者必须拥有两组不同的权限：一组用于模拟给定身份，另一组用于代表该身份执行特定操作。这可以防止支持工具、控制器或节点代理通过模拟获得比其自身被允许范围更广的访问权限，即使其模拟 RBAC 配置有误也是如此。现有的 impersonate 规则会继续生效，但 API 服务器会优先采用新的受约束检查，从而使过渡成为渐进式过程，而不是一次性切换。随着在 v1.36 中进入 beta 阶段，ConstrainedImpersonation 已经过测试、形成文档，并已准备好被依赖模拟的平台开户团队更广泛采用。

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

DRA 功能进入 beta 阶段

动态资源分配（DRA）框架在 Kubernetes v1.36 中达到了又一个成熟度里程碑，多项核心功能升级为 beta 并默认启用。这一转变使 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 默认在所有核心控制平面组件和节点代理中启用，并由单元测试、集成测试和端到端测试提供支持，因此可在生产环境中安全用于可观测性和调试工作流。

这项工作作为由 SIG Instrumentation 牵头的 KEP #4827 的一部分完成。

Kubernetes 组件的 Flagz

在 Kubernetes v1.36 中，核心 Kubernetes 组件的 ComponentFlagz 特性门控升级为 beta 版，标准化了一个 /flagz 端点，用于公开每个组件启动时实际生效的命令行标志。这让集群运维人员和开发者能够在集群内实时查看组件配置，从而更轻松地调试意外行为，或验证某个标志在重启后是否确实已完成推出并生效。

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

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

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

混合版本代理（也称为未知版本互操作性代理）

在 Kubernetes v1.36 中，混合版本代理功能从 v1.28 中引入的 alpha 阶段升级为 beta 阶段，为混合版本集群提供更安全的控制平面升级。现在，每个 API 请求都可以被路由到提供所请求的组、版本和资源的 apiserver 实例，从而减少由于版本偏差导致的 404 和失败。

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

这项工作是作为由 SIG API Machinery 牵头的 KEP #4020 的一部分完成的

使用 cgroups v2 实现内存 QoS

Kubernetes 现在在 Linux cgroup v2 节点上增强了内存 QoS，通过更智能的分层内存保护，使内核控制更好地与 pod 请求和限制保持一致，从而减少共享同一节点的工作负载之间的相互干扰和抖动。本次迭代还改进了 kubelet 对 memory.high 和 memory.min 的配置方式，增加了指标和保护措施以避免活锁，并引入了配置选项，使集群运营者能够根据其环境调整内存保护行为。

这项工作是作为由 SIG Node 牵头的 KEP #2570 的一部分完成的

Alpha 中的新功能

以下是 v1.36 发布后现已进入 Alpha 阶段的一些改进精选。

针对自定义指标的 HPA 缩容至零

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

现在，用户可以尝试在没有待处理工作时完全闲置繁重工作负载，从而显著降低基础设施成本。虽然该功能仍处于 HPAScaleToZero 特性门控之后，但它使 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）栈的复杂网络和计算需求。

这项工作是在多个 KEP 中完成的（包括 #5729、#5304、#5517、#5677 和 #5491），由 SIG Scheduling 和 SIG Node 牵头。

Kubernetes 指标的原生直方图支持

随着 Alpha 阶段原生直方图支持的引入，高分辨率监控在 Kubernetes v1.36 中达到了一个新的里程碑。传统的 Prometheus 直方图依赖静态的预定义桶，往往迫使用户在数据准确性和内存使用之间作出权衡；而此次更新允许控制平面导出稀疏直方图，这些直方图会根据实时数据动态调整其分辨率。

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

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

基于清单的准入控制配置

在 Kubernetes v1.36 中，随着基于清单的准入控制配置以 Alpha 形式引入，准入控制器的管理正转向一种更声明式且一致的模型。此更改解决了长期以来通过各不相同的命令行标志或单独且复杂的配置文件来配置准入插件所面临的挑战，允许管理员通过结构化清单直接定义准入控制的期望状态。

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

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

CRI 列表流式传输

随着 CRI 列表流式传输以 Alpha 版本引入，Kubernetes v1.36 使用了新的内部流式操作。该增强功能通过用更高效的服务器端流式 RPC 替代 kubelet 与容器运行时之间传统的整体式 List 请求，解决了大规模节点上经常出现的内存压力和延迟峰值问题。

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

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

其他值得注意的变化

Ingress NGINX 退役

为了优先保障生态系统的安全性，Kubernetes SIG Network 和 Security Response Committee 已于 2026 年 3 月 24 日停用 Ingress NGINX。自该日期起，不再发布任何版本、不再修复错误，也不再提供用于解决任何已发现安全漏洞的更新。现有的 Ingress NGINX 部署将继续运行，Helm charts 和容器镜像等安装构件也将继续可用。

完整详情请参阅官方停用公告。

更快的卷 SELinux 标记（GA）

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

此功能在 v1.28 中作为针对 ReadWriteOncePod 卷的 beta 功能引入。在 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：加速递归 SELinux 标签变更。

v1.36 中的升级、弃用和移除

升级至稳定版

此处列出了所有已升级至稳定版（也称为正式可用）的功能。有关包括新功能以及从 alpha 升级到 beta 在内的完整更新列表，请参阅发行说明。

此版本共有 18 项增强功能晋升为稳定版：

• 在 Pod 中支持用户命名空间
• 用于 Service Account 令牌外部签名的 API
• 加速递归式 SELinux 标签变更
• Portworx 文件内置插件到 CSI 驱动的迁移
• 细粒度 Kubelet API 授权
• 变更型准入策略
• 节点日志查询
• 卷组快照
• 可变的 CSINode 可分配属性
• DRA：设备请求中的优先级备选项
• 支持基于 cgroupv2 的 PSI
• 添加 ProcMount 选项
• DRA：扩展 PodResources，以包含来自动态资源分配的资源
• VolumeSource：OCI Artifact 和/或 Image
• 在 CPU Manager 中拆分 L3 缓存拓扑感知
• DRA：ResourceClaims 和 ResourceClaimTemplates 的 AdminAccess
• 移除 Kubernetes API 类型对 gogo protobuf 的依赖
• CSI 驱动程序通过 secrets 字段选择启用服务账号令牌

弃用项移除与社区更新

随着 Kubernetes 的发展和成熟，一些功能可能会被弃用、移除，或被更好的功能取代，以提升项目的整体健康状况。有关此过程的更多详细信息，请参阅 Kubernetes 弃用和移除政策。Kubernetes v1.36 包含几项弃用。

弃用 Service .spec.externalIPs

在此版本中，Service spec 中的 externalIPs 字段已被弃用。这意味着该功能仍然存在，但将在未来某个 Kubernetes 版本中不再工作。如果你目前依赖该字段，应计划进行迁移。多年来，该字段一直是一个已知的安全难题，会使针对集群流量的中间人攻击成为可能，如 CVE-2020-8554 中所记录。从 Kubernetes v1.36 起，使用该字段时你将看到弃用警告，并计划在 v1.43 中完全移除。

如果你的 Services 仍然依赖 externalIPs，请考虑使用 LoadBalancer services 进行云托管入口，使用 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 containers 或外部 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 做出贡献的公司
• 整体生态系统贡献

活动更新

探索即将举行的 Kubernetes 和云原生活动，包括 KubeCon + CloudNativeCon、KCD 以及全球其他重要会议。及时了解信息，并参与 Kubernetes 社区！

2026 年 4 月

• KCD - Kubernetes Community Days：瓜达拉哈拉：2026 年 4 月 18 日 | 墨西哥瓜达拉哈拉

2026年5月

• KCD - Kubernetes Community Days：多伦多：2026年5月13日 | 加拿大多伦多
• KCD - Kubernetes Community Days：得克萨斯：2026年5月15日 | 美国奥斯汀
• KCD - Kubernetes Community Days：伊斯坦布尔：2026年5月15日 | 土耳其伊斯坦布尔
• KCD - Kubernetes Community Days：赫尔辛基：2026年5月20日 | 芬兰赫尔辛基
• KCD - Kubernetes Community Days：捷克和斯洛伐克：2026年5月21日 | 捷克布拉格

2026年6月

• KCD - Kubernetes Community Days：纽约：2026年6月10日 | 美国纽约
• KCD - Kubernetes 社区日：吉隆坡：2026 年 6 月 27 日 | 马来西亚吉隆坡
• KubeCon + CloudNativeCon India 2026：2026 年 6 月 18-19 日 | 印度孟买

2026 年 7 月

• KubeCon + CloudNativeCon Japan 2026：2026 年 7 月 29-30 日 | 日本横滨

2026年9月

• KCD - Kubernetes Community Days：旧金山湾区：2026年9月1日 | 美国山景城
• KubeCon + CloudNativeCon China 2026：2026年9月8日至9日 | 中国上海

2026年10月

• KCD - Kubernetes Community Days：英国：2026年10月19日 | 英国爱丁堡

2026年11月

• KCD - Kubernetes Community Days：波尔图：2026年11月19日 | 葡萄牙波尔图
• KubeCon + CloudNativeCon North America 2026：2026年11月9日至12日 | 美国盐湖城

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

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

欢迎于 2026 年 5 月 20 日星期三 16:00（UTC）加入 Kubernetes v1.36 发布团队成员，了解此版本的发布亮点。欲了解更多信息并注册，请访问 CNCF Online Programs 网站上的活动页面。

参与其中

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

• 在 Bluesky 上关注我们 @kubernetes.io，获取最新动态
• 在 Discuss 上加入社区讨论
• 在 Slack 上加入社区
• 在 Stack Overflow 上发布问题（或回答问题）
• 分享你的 Kubernetes 故事
• 在博客上阅读更多关于 Kubernetes 动态的内容
• 进一步了解 Kubernetes 发布团队

• ← 上一页
• 下一页 →