Kubernetes v1.36「Haru」正式发布：春归万物生，稳中见功夫

四月的北半球，春山欲醒，樱意未阑。Kubernetes 社区也在这个时节，如约交付了 2026 年的首个正式版本——v1.36。

2026 年 4 月 22 日，Kubernetes v1.36 正式发布。这一版的代号取自日语「ハル（Haru）」——意为「春」。在上一版「Timbernetes（世界树）」为 2025 年画下句点之后，Haru 以一个新季节的姿态，开启了 2026 年的第一次更新。

本次发布周期的 Release Lead 由来自日本社区的 Ryota Sawada 担任，这也是代号选取日语的一个温柔注脚。春天在日本文化里意味着万物复苏、花木抽枝，落在 Kubernetes 身上，则呈现出另一种姿态——没有颠覆性的新范式，也没有惊雷般的架构变革，而是把过去几年埋下的种子一一催开，让多年沉淀的能力终于抽出第一片新叶。

一句话概括 v1.36 的气质：春归万物生，稳中见功夫。

版本概览:71 项增强，18 项 GA

先看一组数字。v1.36 共带来 71 项增强，其中 18 项毕业至 Stable(GA)，26 项进入 Beta，和过去几个版本相比，v1.36 的关键词不是「扩张」，而是「收口」——一批在 Alpha 阶段跋涉了三四年的老功能，这次终于熬出头。对运维团队来说，这种版本比新增一堆实验性特性更有价值：你可以少用几个第三方工具，少维护几套自研组件，平台本身正在替你兜底。

GA 亮点：四年磨一剑的三项能力

1. Pod User Namespaces 正式 GA —— 一粒种子，埋了四年

这可能是整个 v1.36 最值得讲清楚的特性。

它从 Kubernetes v1.25(2022 年 8 月)进入 Alpha，四年之后终于在 v1.36 毕业到 GA。四年时间，社区反复打磨内核、运行时、kubelet 的协作链路，才把它送到今天这个位置。

它解决了什么问题？每个 Pod 拥有独立的用户 ID 命名空间。容器里看起来是 root(UID 0)的进程，在宿主机层面只是一个无特权用户。即使攻击者突破了容器边界，在宿主节点上也几乎什么都做不了。

启用方式也足够克制:

spec:
  hostUsers: false
  containers:
  - name: app
    image: my-app

过去要做到这种级别的隔离，要么依赖 gVisor、Kata Containers 这类第三方运行时，要么接受更弱的隔离保证。现在，它是 Kubernetes 原生、稳定、生产就绪的一部分。 对多租户平台、金融、政企、合规场景来说，这是一次值得认真评估的能力升级。

2. Mutating Admission Policies GA —— 告别 Webhook Server

写过 Mutating Webhook 的工程师都明白那种痛:

维护一个 TLS 加密的 HTTP Server、管理证书、担心 Webhook 延迟、处理崩溃可能阻塞整个 API Server 的故障模式——只是为了给 Pod 注入几个标签或者设置默认资源限制,实在不划算。

v1.36 将 MutatingAdmissionPolicy 推至 GA 并默认开启，变更逻辑可以用原生 Kubernetes 对象直接表达，不再需要外部 Webhook 服务。

这意味着可以把变更逻辑声明为 K8s 资源，纳入 GitOps 管理，彻底摆脱 Webhook Server 依赖。对平台团队——尤其是小团队——这就是运维负担的一次结构性降低。

3. OCI VolumeSource GA —— 让镜像仓库也成为"存储"

AI/ML 场景下，如何把模型权重、配置、数据集优雅地送进 Pod，一直是个老问题。

过去你的选项有:把主镜像撑大、写一个 init 容器去拉、或者和 ConfigMap 的体积限制死磕。

OCI VolumeSource 把任意 OCI 镜像当作卷来引用。Kubernetes 会像拉取容器镜像一样把它拉下来并挂载到 Pod 里。

打包、分发、缓存、版本管理——全部复用现有的镜像仓库基础设施，和应用镜像完全解耦。对 AI 模型文件、大型配置包、二进制工具的分发，这几乎是"开箱即用"的新范式。

4. 其他关键 GA 特性

  • Volume Group Snapshots GA：支持对一组卷做崩溃一致性(crash-consistent)快照，并恢复为新的卷集合，有状态工作负载的灾备场景可以少写很多脚本;
  • ServiceAccount Token 外部签名 GA(KEP-740)：kube-apiserver 可以把 token 签发委托给外部 KMS 或 HSM。对 PCI-DSS、FedRAMP、SOC 2 等合规场景而言，这是 Kubernetes 原生兼容合规框架的一条清晰路径;
  • Fine-grained Kubelet API Authorization GA：节点级安全能力显著增强，在"最小权限"架构上向前迈了一大步;
  • SELinux 递归重打标签加速 GA(KEP-1710)：这个从 v1.27(2023 年 4 月)就进入 Beta 的特性终于稳定，挂卷容器的启动速度会有可感知的提升;
  • Kubelet PodResources API 对 DRA 的支持 GA：平台运维可以拿到 Pod 级别的 DRA 资源指标，精确到 GPU、加速器粒度，计费、性能调优、故障定位都会更顺手。

Beta 阶段:异构算力与网络安全同步推进

DRA 继续"抽枝":从整机调度走向精细分配

动态资源分配(DRA)是近两个版本演进最快的模块，v1.36 再推两项关键增强:

  • DRA 可分片设备(KEP-4815)进入 Beta：允许将单个硬件加速器切分成多个逻辑单元，在多个工作负载之间共享。对 GPU 这类昂贵资源尤其重要——独占式分配常常造成严重的利用率浪费，按需切分可以让同一块卡服务多个工作负载，同时保持隔离与控制；
  • DRA 设备污点与容忍(KEP-5055)进入 Beta：默认开启，允许管理员将某些设备标记为不可用或仅允许特定工作负载使用。

两者合起来，Kubernetes 在异构算力管理上已经具备了相当完整的语义表达能力。

IP/CIDR 校验收紧(KEP-4858)

非规范 IP 格式(如 010.000.001.005 或 ::ffff:10.0.1.5)以及模糊的 CIDR 值(如在期望 192.168.1.0/24 的上下文中出现 192.168.1.5/24),将不再被核心 Kubernetes 对象接受。

这个变更背后是 CVE-2021-29923 级别的安全隐患——历史上这些非规范格式在不同实现之间存在解释歧义，曾被用作攻击面。升级前请仔细排查 YAML、Helm Chart 和 Operator 中可能存在的非规范 IP 表达。

其他值得关注的 Beta 特性

  • Pod 级原地伸缩(In-Place Pod Level Resize)进入 Beta:支持 Pod 级别(而非仅容器级别)的 CPU/内存在线伸缩，面向 cgroup v2 环境，对多容器 Pod、HPC、AI/ML 等 Guaranteed QoS 场景意义重大;
  • DRA Device Binding Conditions(KEP-5007)进入 Beta 并默认开启。

Alpha 实验:来年之春的种子

这些特性默认关闭，属于"先记下来、适时关注"的名单:

  • Workload-Aware Scheduling(工作负载感知调度):面向 AI/ML 分布式训练等场景的调度优化;
  • HPA 外部指标获取失败回退(#5679):当外部指标 API(如云厂商队列、Datadog)抖动时，HPA 能采取合理的降级策略，避免灾难性伸缩决策;
  • HPA 仅统计目标控制器管理的 Pod 的指标:避免 selector 匹配到"无关" Pod 污染伸缩判断;
  • PVC 增加 UnusedSince 字段:记录上一次被使用的时间戳，为存储资源的生命周期治理提供依据。

移除与弃用:升级前务必清点

这一节建议认真读——涉及到升级能否平稳落地。

  • gitRepo 卷插件被移除(KEP-5040):根因是容器内以 root 身份执行代码的严重安全隐患。仍在使用的，升级前必须迁移;
  • kube-proxy 的 IPVS 模式被移除(v1.35 已弃用):继续使用的场景需切换到 iptables 或 nftables 模式;
  • Service 的 externalIPs 字段从 v1.36 开始显示弃用警告,计划在 v1.43 彻底移除:这是沉疴已久的安全隐患(CVE-2020-8554)，可能被用于中间人攻击;
  • kubeadm 移除了对 flex-volumes 的内置支持:SIG Storage 从 v1.22 起就建议迁移。

还有一个与 v1.36 同期、但独立于版本之外需要单独提醒的大事件:

Ingress-NGINX 已于 2026 年 3 月 24 日由 Kubernetes SIG Network 和 Security Response Committee 正式退役。自该日期起,不再发布任何新版本、Bug 修复或安全漏洞更新。

已有部署仍然可以运行，但从长期运维视角看，这是一个非常明确的信号——评估 Gateway API 等替代方案，需要提上日程了。

如何理解 v1.36?

如果说 v1.34「Of Wind & Will」是一次关于"意志"的推进，v1.35「Timbernetes(世界树)」是一次关于"根系"的扩展，那么 v1.36「Haru」就是一次关于"新芽"的收束——

它不喧嚣，却足够扎实。

安全(User Namespaces、Kubelet API Authorization、外部 Token 签名、IP/CIDR 校验收紧)、AI/ML 基础设施(DRA 分片、PodResources for DRA、OCI Volume)、平台化能力(Mutating Admission Policies)这三条主线上的多年积累，在这一版集中兑现。对在生产环境维护 Kubernetes 的团队而言，v1.36 不是一个可以忽略的小版本，而是值得认真排期的那种发布。

KubeSphere 与 Kubernetes v1.36

作为一款以 Kubernetes 为内核的企业级容器管理平台，KubeSphere 始终与上游 Kubernetes 社区保持同步演进。

KubeSphere 团队已第一时间启动针对 Kubernetes v1.36 的兼容性验证、关键特性评估与升级路径设计，重点关注生产环境中广泛使用的核心能力与潜在破坏性变更——包括但不限于 gitRepo 卷插件移除、IPVS 模式退场、externalIPs 字段弃用、Ingress-NGINX 退役后的替代策略，以及 DRA、Mutating Admission Policies 等关键能力在多租户平台语义下的适配效果，确保平台在稳定性、安全性与可运维性方面保持一贯水准。

后续，KubeSphere 将在充分验证社区特性成熟度与企业使用场景的基础上，逐步引入并完整支持 Kubernetes v1.36，让用户在享受上游新能力的同时，不必承担版本早期的不确定性成本。

总结

春天是一个关于"等待与兑现"的季节。四年前埋下的 User Namespaces，三年前萌发的 Mutating Admission Policies，都在这一版里抽出了新芽。

而 KubeSphere 想做的，是让这份春意在你的生产集群中，也能如期绽放。有任何升级疑问或特性落地咨询，欢迎在公众号后台留言，或到 KubeSphere 社区与我们交流。

春山可望，稳中有为。愿每一次 kubectl apply，都平安顺利。 🌱

参考链接

posted @ 2026-04-23 14:59  kubesphere  阅读(50)  评论(0)    收藏  举报