Kubernetes v1.32 预览
随着 Kubernetes v1.32 发布日期的临近,该项目也在不断发展和成熟。为了项目的整体健康,某些功能可能会被弃用、删除或替换为更好的功能。
这篇博客概述了 Kubernetes v1.32 版本中计划的一些变更,发布团队认为您应该了解这些变更,以便持续维护您的 Kubernetes 环境并及时了解最新变更。下面列出的信息基于 v1.32 发布的当前状态,可能会在实际发布日期之前发生变化。
Kubernetes API 删除和弃用流程
Kubernetes 项目有一个文档完善的功能弃用政策。该政策规定,只有当有更新的、稳定的 API 版本可用时,稳定的 API 才能被弃用,并且 API 对于每个稳定性级别都有最低的生命周期。已弃用的 API 已被标记为在未来的 Kubernetes 版本中删除,将在删除之前继续工作(至少从弃用开始一年)。使用它将导致显示警告。已删除的 API 在当前版本中不再可用,因此您必须迁移以使用替换 API。
通用可用 (GA) 或稳定的 API 版本可能会被标记为已弃用,但在 Kubernetes 的主要版本中不得删除。
Beta 或预发布 API 版本在弃用后必须支持 3 个版本。
Alpha 或实验性 API 版本可以在任何版本中删除,无需事先发出弃用通知;在同一功能已存在不同实现的情况下,此过程可以成为撤回。
无论 API 是由于功能从 Beta 升级到稳定版而被删除,还是由于该 API 未成功而被删除,所有删除都符合此弃用政策。每当 API 被删除时,都会在弃用指南中传达迁移选项。
关于旧 DRA 实现撤回的说明
#3063 增强功能在 Kubernetes 1.26 中引入了动态资源分配 (DRA)。
但是,在 Kubernetes v1.32 中,这种 DRA 方法将发生重大变化。与原始实现相关的代码将被删除,留下 KEP #4381 作为“新”的基础功能。
更改现有方法的决定源于其与集群自动缩放的不兼容性,因为资源可用性是不透明的,这使集群自动缩放器和控制器的决策变得复杂。新添加的结构化参数模型取代了该功能。
此删除将使 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
中的显著变化包括 PriorityLevelConfigurationspec.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 了解负载均衡器的行为
KEP #1860 升级到 GA,为 type: LoadBalancer
的 Service 引入了 ipMode
字段,该字段可以设置为 "VIP"
或 "Proxy"
。此增强功能旨在改进云提供商的负载均衡器与 kube-proxy 的交互方式,并且是对最终用户透明的更改。使用 "VIP"
时,保留了 kube-proxy 的现有行为,其中 kube-proxy 处理负载均衡。使用 "Proxy"
会将流量直接发送到负载均衡器,从而使云提供商可以更好地控制对 kube-proxy 的依赖性;这意味着,对于某些云提供商,您可能会看到负载均衡器的性能有所提高。
重试生成资源的名称
此增强功能改进了如何处理使用 generateName
字段创建的 Kubernetes 资源的名称冲突。以前,如果发生名称冲突,API 服务器会返回 409 HTTP 冲突错误,客户端必须手动重试请求。通过此更新,如果发生冲突,API 服务器会自动重试生成新名称最多七次。这大大减少了冲突的机会,确保可以平稳生成多达 100 万个名称,冲突概率小于 0.1%,从而为大规模工作负载提供更高的弹性。
想了解更多?
新功能和弃用也会在 Kubernetes 发行说明中公布。我们将作为此版本变更日志的一部分,正式公布Kubernetes v1.32 中的新增内容。
您可以在以下版本的发行说明中查看更改公告