Kubernetes v1.32 抢先看
随着 Kubernetes v1.32 发布日期的临近,项目也在发展和成熟。为了项目的整体健康,一些特性可能会被废弃、移除或被更好的特性取代。
这篇博客概述了 Kubernetes v1.32 版本的一些计划变更,发布团队认为你应该了解这些变更,以便持续维护你的 Kubernetes 环境并及时了解最新变化。以下信息基于 v1.32 版本的当前状态,在实际发布日期之前可能会发生变化。
Kubernetes API 移除和废弃流程
Kubernetes 项目拥有成熟的特性废弃策略。该策略规定,只有当某个稳定 API 有更新的稳定版本可用时,才能废弃该稳定 API,并且 API 在每个稳定性级别都有最短生命周期。已标记为在未来 Kubernetes 版本中移除的废弃 API 在移除之前(自废弃之日起至少一年)将继续可用。使用它会显示警告。已移除的 API 在当前版本中不再可用,因此你必须迁移到使用替代版本。
正式可用 (GA) 或稳定 API 版本可以标记为废弃,但在 Kubernetes 的一个主版本内不得移除。
Beta 或预发布 API 版本在废弃后必须支持 3 个版本。
Alpha 或实验性 API 版本可以在任何版本中移除,无需事先通知;如果同一特性已有不同的实现,则此过程可视为撤回。
无论 API 是因为特性从 Beta 升级到 Stable 而被移除,还是因为该 API 未成功,所有移除都遵守此废弃策略。当 API 被移除时,迁移选项会在废弃指南中进行沟通。
关于旧 DRA 实现撤回的说明
增强功能 #3063 在 Kubernetes 1.26 中引入了动态资源分配 (DRA)。
然而,在 Kubernetes v1.32 中,这种 DRA 方法将发生重大变化。与原始实现相关的代码将被移除,将 KEP #4381 作为“新”的基础功能。
更改现有方法的决定源于它与集群自动扩缩容不兼容,因为资源可用性不透明,从而使 Cluster Autoscaler 和控制器都难以做出决策。新添加的结构化参数模型替代了该功能。
此次移除将使 Kubernetes 能够更可预测地处理新的硬件需求和资源申请,绕开与 kube-apiserver 之间反复进行 API 调用的复杂性。
另请参阅增强功能问题 #3063 以了解更多信息。
API 移除
Kubernetes v1.32 只计划移除一个 API
- FlowSchema 和 PriorityLevelConfiguration 的
flowcontrol.apiserver.k8s.io/v1beta3
API 版本已被移除。为此做准备,你可以编辑现有的清单并重写客户端软件以使用自 v1.29 起可用的flowcontrol.apiserver.k8s.io/v1 API
版本。所有现有的持久化对象都可以通过新的 API 访问。flowcontrol.apiserver.k8s.io/v1beta3
的显著变化包括 PriorityLevelConfiguration 的spec.limited.nominalConcurrencyShares
字段在未指定时仅默认为 30,且显式值 0 不会更改为 30。
更多信息请参阅 API 废弃指南。
Kubernetes v1.32 先睹为快
以下增强功能列表可能包含在 v1.32 版本中。这并非承诺,发布内容可能会发生变化。
更多 DRA 增强功能!
在此版本中,与之前版本一样,Kubernetes 项目继续提出动态资源分配 (DRA) 的多项增强功能,DRA 是 Kubernetes 资源管理系统的关键组成部分。这些增强功能旨在提高需要专用硬件(例如 GPU、FPGA 和网络适配器)的工作负载的资源分配灵活性和效率。此版本引入了改进,包括在 Pod 状态中添加资源健康状况,如 KEP #4680 所述。
在 Pod 状态中添加资源健康状况
很难知道 Pod 使用的设备何时出现故障或暂时不健康。KEP #4680 建议通过 Pod status
暴露设备健康状况,从而简化 Pod 崩溃的故障排除。
Windows 反击!
KEP #4802 增加了对 Kubernetes 集群中 Windows 节点优雅关机的支持。在此版本之前,Kubernetes 为 Linux 节点提供了优雅节点关机功能,但缺乏对 Windows 的等效支持。此增强功能使 Windows 节点上的 kubelet 能够正确处理系统关机事件。这样做可确保在 Windows 节点上运行的 Pod 优雅终止,从而允许在不中断的情况下重新调度工作负载。这一改进增强了包含 Windows 节点的集群的可靠性和稳定性,尤其是在计划维护或任何系统更新期间。
允许环境变量中使用特殊字符
随着此增强功能升级到 Beta,Kubernetes 现在允许几乎所有可打印的 ASCII 字符(“=”除外)用作环境变量名称。这一更改解决了以前对变量命名的限制,通过适应各种应用需求促进了 Kubernetes 的广泛采用。默认情况下,通过 RelaxedEnvironmentVariableValidation
特性门启用宽松验证,确保用户可以轻松使用环境变量而无需严格约束,从而增强了对需要特殊字符配置的应用(例如 .NET Core)的开发人员的灵活性。
让 Kubernetes 感知 LoadBalancer 的行为
KEP #1860 升级到 GA,为 type: LoadBalancer
的 Service 引入了 ipMode
字段,该字段可以设置为 "VIP"
或 "Proxy"
。此增强功能旨在改善云提供商负载均衡器与 kube-proxy 的交互方式,并且对最终用户来说是透明的更改。使用 "VIP"
时保留了 kube-proxy 的现有行为,即 kube-proxy 处理负载均衡。使用 "Proxy"
会导致流量直接发送到负载均衡器,从而使云提供商能够更好地控制是否依赖 kube-proxy;这意味着对于某些云提供商,你的负载均衡器性能可能会有所提高。
重试为资源生成名称
此增强功能改进了 Kubernetes 资源在使用 generateName
字段创建时如何处理名称冲突。以前,如果发生名称冲突,API 服务器会返回 409 HTTP Conflict 错误,客户端必须手动重试请求。通过此更新,API 服务器在发生冲突时会自动重试生成新名称最多七次。这显著减少了冲突的可能性,确保顺利生成多达 100 万个名称,冲突概率小于 0.1%,为大规模工作负载提供了更大的弹性。
想了解更多?
新特性和废弃也会在 Kubernetes 版本说明中公布。我们将作为此版本 CHANGELOG 的一部分,正式宣布 Kubernetes v1.32 中的新内容。
你可以在以下版本的发布说明中查看变更公告: