中文内容
Kubernetes v1.36 预览
Kubernetes v1.36 将于 2026 年 4 月底发布。此版本将包括移除和弃用内容,并包含数量可观的增强功能。以下是我们在本周期中最期待的一些功能!
请注意,此信息反映的是 v1.36 开发的当前状态,在发布前可能会发生变化。
Kubernetes API 的移除和弃用流程
Kubernetes 项目为功能制定了有据可查的弃用政策。该政策规定,只有在同一 API 的更新稳定版本可用时,才可以弃用稳定 API,并且 API 在每个稳定性级别都有最低生命周期。已弃用的 API 已被标记为将在未来的 Kubernetes 版本中移除。在移除之前(至少自弃用起一年)它将继续运行,但使用时会显示警告。已移除的 API 在当前版本中不再可用,此时你必须迁移到使用替代项。
- 正式发布(GA)或稳定的 API 版本可以被标记为已弃用,但不得在 Kubernetes 的一个主版本内被移除。
- Beta 或预发布 API 版本在弃用后必须继续支持 3 个版本。
- Alpha 或实验性 API 版本可以在任何版本中移除,而无需事先发布弃用通知;如果同一功能的不同实现已经就位,此过程可能会变为撤回。
无论某个 API 被移除是因为某项功能从 beta 升级为稳定版,还是因为该 API 本身未能取得成功,所有移除都遵循此弃用政策。每当某个 API 被移除时,迁移选项都会在弃用指南中进行说明。
这一原则付诸实践的一个近期示例是 ingress-nginx 项目的退役,该事项由 SIG-Security 于 2026 年 3 月 24 日宣布。随着项目的维护职责逐步转移,社区已被鼓励评估符合当前安全和维护最佳实践的替代 ingress 控制器。这一过渡体现了支撑 Kubernetes 本身的同样生命周期纪律,确保持续演进而不会造成突然中断。
Ingress NGINX 退役
为优先保障生态系统的安全性,Kubernetes SIG Network 和 Security Response Committee 已于 2026 年 3 月 24 日将 Ingress NGINX 退役。自该日起,不再发布任何版本,不再进行错误修复,也不再发布用于解决所发现安全漏洞的更新。现有的 Ingress NGINX 部署将继续运行,Helm charts 和容器镜像等安装制品将继续可用。
完整详情请参阅官方退役公告。
Kubernetes v1.36 中的弃用和移除
Service 中 .spec.externalIPs 的弃用
Service spec 中的 externalIPs 字段正在被弃用,这意味着你很快将失去一种将任意 externalIPs 路由到你的 Services 的快捷方式。多年来,该字段一直是一个众所周知的安全隐患,会使针对集群流量的中间人攻击成为可能,正如 CVE-2020-8554 中所记录的那样。从 Kubernetes v1.36 开始及以后版本,使用该字段时你将看到弃用警告,并计划在 v1.43 中完全移除。
如果你的 Services 仍然依赖 externalIPs,请考虑使用 LoadBalancer services 来实现云托管入口,使用 NodePort 来进行简单的端口暴露,或使用 Gateway API 以更灵活、更安全的方式处理外部流量。
有关此增强功能的更多详细信息,请参阅 KEP-5707:弃用 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
Kubernetes v1.36 的重点增强功能
以下增强功能列表预计将包含在即将发布的 v1.36 版本中。这并非承诺,发布内容可能会发生变化。
更快的卷 SELinux 标记(GA)
Kubernetes v1.36 使 SELinux 卷挂载改进正式可用。此更改用 mount -o context=XYZ 选项取代了递归文件重新标记,在挂载时将正确的 SELinux 标签应用于整个卷。它带来了更一致的性能,并减少了在强制执行 SELinux 的系统上的 Pod 启动延迟。
该功能在 v1.28 中作为 ReadWriteOncePod 卷的 beta 版本引入。在 v1.32 中,它增加了指标和一个选择退出选项(securityContext.seLinuxChangePolicy: Recursive),以帮助发现冲突。现在在 v1.36 中,它达到稳定状态并默认适用于所有卷,Pod 或 CSIDriver 可通过 spec.SELinuxMount 选择启用。
然而,我们预计该功能会因特权 Pod 和非特权 Pod 可能混用,而在未来的 Kubernetes 版本中产生破坏性变更的风险。正确设置 Pod 上的 seLinuxChangePolicy 字段和 SELinux 卷标签,是 Pod 作者开发者的责任;无论他们是在编写 Deployment、StatefulSet、DaemonSet,还是包含 Pod 模板的自定义资源,都负有这一责任。在 Pod 共享卷时,如果对这些设置不够谨慎,可能会导致一系列问题。
有关此增强功能的更多详细信息,请参阅 KEP-1710:加速递归 SELinux 标签变更
ServiceAccount 令牌的外部签名
作为一项 beta 功能,Kubernetes 已经支持 ServiceAccount 令牌的外部签名。这使集群能够与外部密钥管理系统或签名服务集成,而不是仅依赖内部管理的密钥。
通过此增强功能,kube-apiserver 可以将令牌签名委托给外部系统,例如云密钥管理服务或硬件安全模块。这提高了安全性,并简化了依赖集中式签名基础设施的集群的密钥管理服务。我们预计这将在 Kubernetes v1.36 中升级为稳定版(GA)。
有关此增强功能的更多详细信息,请参阅 KEP-740:Support external signing of service account tokens
DRA 驱动程序对设备污点和容忍的支持
Kubernetes v1.33 引入了对通过动态资源分配(DRA)管理的物理设备的污点和容忍支持。通常,任何设备都可用于调度。不过,此增强功能允许 DRA 驱动程序将设备标记为带有污点,从而确保这些设备不会被用于调度目的。或者,集群管理员可以创建 DeviceTaintRule,将符合特定选择条件(例如某个驱动程序的所有设备)的设备标记为带有污点。这改进了调度控制,并有助于确保专用硬件资源仅由明确请求它们的工作负载使用。
在 Kubernetes v1.36 中,该功能在完成更全面的测试后升级为 beta 版,使其默认可用,无需功能标志,并开放给用户反馈。
要了解污点和容忍,请参阅污点和容忍。有关此增强功能的更多详细信息,请参阅 KEP-5055:DRA:设备污点和容忍。
DRA 对可分区设备的支持
Kubernetes v1.36 扩展了 Dynamic Resource Allocation(DRA),引入了对可分区设备的支持,允许将单个硬件加速器拆分为多个可在工作负载之间共享的逻辑单元。这对于 GPU 等高成本资源尤其有用,因为将整个设备专用于单个工作负载可能会导致利用率不足。
通过此增强功能,平台团队可以只为每个工作负载分配设备所需的部分,而不是将其全部预留,从而提高整体集群效率。这使得在同一硬件上运行多个工作负载变得更容易,同时保持隔离和控制,帮助组织从其基础设施中获得更多价值。
要了解有关此增强功能的更多信息,请参阅 KEP-4815:DRA 可分区设备
想了解更多?
Kubernetes 发行说明中也会公布新功能和弃用项。我们将在 Kubernetes v1.36 的 CHANGELOG 中正式公布该版本的新内容。
Kubernetes v1.36 计划于 2026 年 4 月 22 日(星期三)发布。敬请关注更新!
你还可以在以下版本的发布说明中查看变更公告:
- 正文:Kubernetes v1.35
- 正文:Kubernetes v1.34
- 正文:Kubernetes v1.33
- 正文:Kubernetes v1.32
- 正文:Kubernetes v1.31
- 正文:Kubernetes v1.30
参与其中
参与 Kubernetes 最简单的方式,是加入众多与你兴趣相符的特别兴趣小组(SIG)之一。有什么想向 Kubernetes 社区传播的信息吗?欢迎在我们的每周社区会议上发声,并通过以下渠道分享你的声音。感谢你持续提供反馈和支持。
- 在 Bluesky 上关注我们 @kubernetes.io,获取最新动态
- 在 Discuss 上加入社区讨论
- 在 Slack 上加入社区
- 在 Server Fault 或 Stack Overflow 上发布问题(或回答问题)
- 分享你的 Kubernetes 故事
- 在博客上阅读更多有关 Kubernetes 最新动态的内容
- 进一步了解 Kubernetes Release Team
- ← 上一页
- 下一页 →