Kubernetes v1.31: Elli

编辑: Matteo Bianchi, Yigit Demirbas, Abigail McCarthy, Edith Puclla, Rashan Smith

Kubernetes v1.31:Elli 宣布发布!

与之前的版本类似,Kubernetes v1.31 的发布中引入了新的稳定版、Beta 版和 Alpha 特性功能。 持续提供高质量的版本彰显了我们开发周期的强劲实力以及社区的大力支持。 此版本包含 45 项增强功能。 在这些增强功能中,11 项已升级到稳定版,22 项正在进入 Beta 版,12 项已升级到 Alpha 版。

Kubernetes v1.31 的发布主题是 "Elli"。

Kubernetes v1.31 的 Elli 是一只可爱欢快的小狗,戴着一顶漂亮的水手帽,这是对庞大而多样化的 Kubernetes 贡献者家族的一个俏皮致意。

Kubernetes v1.31 标志着该项目成功庆祝其诞生十周年后的首次发布。 自诞生以来,Kubernetes 已经走过了漫长的道路,并且每次发布都在朝着令人兴奋的新方向前进。 十年后,回顾无数 Kubernetes 贡献者为实现这一目标所付出的努力、奉献、技能、智慧和辛勤工作,令人敬畏。

还有,尽管运营项目需要付出巨大的努力,仍然有大量的人不断以热情、微笑和自豪感出现,为社区做出贡献并成为其中的一员。 我们从新老贡献者那里看到的这种"精神"是一个充满活力的社区的标志,我们可以称之为"欢乐"的社区。

Kubernetes v1.31 的 Elli 就是为了庆祝这种美好的精神!让我们为 Kubernetes 的下一个十年干杯!

晋级为稳定版的功能亮点

以下是 v1.31 发布后晋级为稳定版的部分改进。

AppArmor 支持现已稳定

Kubernetes 对 AppArmor 的支持现已正式发布。通过在容器的 securityContext 中设置 appArmorProfile.type 字段,可以使用 AppArmor 保护您的容器。 请注意,在 Kubernetes v1.30 之前,AppArmor 是通过注解控制的;从 v1.30 开始,它是通过字段控制的。 建议您停止使用注解,开始使用 appArmorProfile.type 字段。

要了解更多信息,请阅读 AppArmor 教程。 这项工作是作为 KEP #24 的一部分由 SIG Node 完成的。

改进 kube-proxy 的入站连接可靠性

kube-proxy 改进的入站连接可靠性在 v1.31 中已稳定。 Kubernetes 中负载均衡器的一个常见问题是为避免流量丢失而在不同组件之间进行同步的机制。 此特性在 kube-proxy 中实现了一种机制,用于负载均衡器对 type: LoadBalancerexternalTrafficPolicy: Cluster 服务所公开的、进入终止进程的 Node 进行连接排空,并为云提供商和 Kubernetes 负载均衡器实现建立了一些最佳实践。

要使用此特性,kube-proxy 需要在集群上作为默认服务代理运行,并且负载均衡器需要支持连接排空。 使用此特性不需要进行特定的更改,它自 v1.30 以来在 kube-proxy 中默认启用,并在 v1.31 中晋级为稳定版。

有关此特性的更多详细信息,请访问虚拟 IP 和服务代理文档页面

这项工作是作为 KEP #3836 的一部分由 SIG Network 完成的。

持久卷最近阶段转换时间

持久卷最近阶段转换时间功能在 v1.31 中晋级为正式版(GA)。 此特性添加了一个 PersistentVolumeStatus 字段,用于保存 PersistentVolume 最近转换到不同阶段的时间戳。 启用此特性后,每个 PersistentVolume 对象将有一个新字段 .status.lastTransitionTime 保存卷最近转换阶段的时间戳。 这种变化并不是立即的;新字段将在 PersistentVolume 更新并在升级到 Kubernetes v1.31 后首次在各阶段(PendingBoundReleased)之间转换时填充。 这允许您测量 PersistentVolume 从 Pending 移动到 Bound 之间的时间。这对于提供指标和 SLO 也很有用。

有关此特性的更多详细信息,请访问 PersistentVolume 文档页面

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

晋级为 Beta 版的功能亮点

以下是 v1.31 发布后晋级为 Beta 版的部分改进。

kube-proxy 的 nftables 后端

nftables 后端在 v1.31 中晋级为 Beta 版,由 NFTablesProxyMode 特性门控控制,现在默认启用。

nftables API 是 iptables API 的继任者,旨在提供比 iptables 更好的性能和可扩展性。 nftables 代理模式能够比 iptables 模式更快、更高效地处理服务端点的变化,并且在内核中也能更高效地处理数据包(尽管这只有在拥有数万个服务的集群中才会显著)。

截至 Kubernetes v1.31,nftables 模式仍相对较新,可能与某些网络插件不兼容;请查阅您的网络插件文档。 此代理模式仅在 Linux 节点上可用,并且需要内核 5.13 或更高版本。 在迁移之前,请注意某些功能,特别是与 NodePort 服务相关的功能,在 nftables 模式下的实现方式与 iptables 模式不完全相同。 查看迁移指南以了解是否需要覆盖默认配置。

这项工作是作为 KEP #3866 的一部分由 SIG Network 完成的。

PersistentVolumes 回收策略的变更

始终遵循 PersistentVolume 回收策略这一特性在 Kubernetes v1.31 中晋级为 Beta 版。 这项增强确保即使在所关联的 PersistentVolumeClaim (PVC) 被删除后,PersistentVolume (PV) 回收策略也会被遵循,从而防止卷的泄漏。

在此特性之前,与 PV 相关联的回收策略可能在特定条件下被忽视,这取决于 PV 或 PVC 是否先被删除。 因此,即使回收策略设置为 "Delete",外部基础设施中相应的存储资源也可能不会被删除。 这导致了潜在的不一致性和资源泄漏。

随着这项功能的引入,Kubernetes 现在保证 "Delete" 回收策略将被执行,确保底层存储对象从后端基础设施中删除,无论 PV 和 PVC 的删除顺序如何。

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

绑定服务账户令牌的改进

ServiceAccountTokenNodeBinding 功能在 v1.31 中晋级为 Beta 版。 此特性允许请求仅绑定到节点而不是 Pod 的令牌,在令牌中包含节点信息的声明,并在使用令牌时验证节点的存在。 有关更多信息,请阅读绑定服务账户令牌文档

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

多个 Service CIDR

支持具有多个服务 CIDR 的集群在 v1.31 中晋级为 Beta 版(默认禁用)。

Kubernetes 集群中有多个组件消耗 IP 地址: Node、Pod 和 Service。 Node 和 Pod 的 IP 范围可以动态更改,因为它们分别取决于基础设施或网络插件。 然而,Service IP 范围是在集群创建期间作为 kube-apiserver 中的硬编码标志定义的。 IP 耗尽一直是长期存在或大型集群的问题,因为管理员需要扩展、缩小甚至完全替换分配的服务 CIDR 范围。 这些操作从未得到原生支持,并且是通过复杂和精细的维护操作执行的,经常导致集群无法正常服务。 这个新特性允许用户和集群管理员以零中断时间动态修改服务 CIDR 范围。

有关此特性的更多详细信息,请访问虚拟 IP 和服务代理文档页面。

这项工作是作为 KEP #1880 的一部分由 SIG Network 完成的。

Service 的流量分配

Service 的流量分配在 v1.31 中晋级为 Beta 版,并默认启用。

为实现 Service 联网的最佳用户体验和流量工程能力,经过多次迭代后,SIG Networking 在服务规约中实现了 trafficDistribution 字段,作为底层实现在做出路由决策时考虑的指导原则。

有关此特性的更多详细信息,请阅读 1.30 发布博客 或访问 Service 文档页面。

这项工作是作为 KEP #4444 的一部分由 SIG Network 完成的。

Kubernetes VolumeAttributesClass ModifyVolume

VolumeAttributesClass API 在 v1.31 中晋级为 Beta 版。 VolumeAttributesClass 提供了一个通用的、Kubernetes 原生的 API,用于修改动态卷参数,如所提供的 IO 能力。 这允许工作负载在线垂直扩展其卷,以平衡成本和性能(如果提供商支持)。 该功能自 Kubernetes 1.29 以来一直处于 Alpha 状态。

这项工作是作为 KEP #3751 的一部分完成的,由 SIG Storage 领导。

Alpha 版的新功能

以下是 v1.31 发布后晋级为 Alpha 版的部分改进。

用于更好管理加速器和其他硬件的新 DRA API

Kubernetes v1.31 带来了更新的动态资源分配(DRA)API 和设计。 此次更新的主要焦点是结构化参数,因为它们使资源信息和请求对 Kubernetes 和客户端透明,并能够实现集群自动扩缩容等功能。 kubelet 中的 DRA 支持已更新,使得 kubelet 和控制平面之间的版本偏差成为可能。通过结构化参数,调度器在调度 Pod 时分配 ResourceClaims。 通过现在称为"经典 DRA"的方式,仍然支持由 DRA 驱动程序控制器进行分配。

从 Kubernetes v1.31 开始,经典 DRA 有一个单独的特性门控名为 DRAControlPlaneController,您需要显式启用它。 通过这样的控制平面控制器,DRA 驱动程序可以实现尚未通过结构化参数支持的分配策略。

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

对镜像卷的支持

Kubernetes 社区正在朝着在未来满足更多人工智能(AI)和机器学习(ML)用例的方向发展。

满足这些用例的要求之一是直接将开放容器倡议(OCI)兼容的镜像和工件(称为 OCI 对象)作为原生卷源支持。 这允许用户专注于 OCI 标准,并使他们能够使用 OCI 注册表存储和分发任何内容。

鉴于此,v1.31 添加了一个新的 Alpha 特性,允许在 Pod 中使用 OCI 镜像作为卷。 此特性允许用户在 pod 中指定镜像引用作为卷,同时在容器内重用它作为卷挂载。您需要启用 ImageVolume 特性门控才能尝试此特性。

这项工作是作为 KEP #4639 的一部分由 SIG NodeSIG Storage 完成的。

通过 Pod 状态暴露设备健康信息

通过 Pod 状态暴露设备健康信息作为新的 Alpha 特性添加到 v1.31 中,默认被禁用。

在 Kubernetes v1.31 之前,了解 Pod 是否与故障设备关联的方法是使用 PodResources API

通过启用此特性,字段 allocatedResourcesStatus 将添加到每个容器状态中,在每个 Pod 的 .status 内。 allocatedResourcesStatus 字段报告分配给容器的各个设备的健康信息。

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

基于选择算符的细粒度鉴权

此特性允许 Webhook 鉴权组件和未来(但目前尚未设计)的树内鉴权组件允许 listwatch 请求, 前提是这些请求使用标签和/或字段选择算符。 例如,现在鉴权组件可以表达:此用户不能列出所有 Pod,但可以列举所有 .spec.nodeName 匹配某个特定值的 Pod。 或者允许用户监视命名空间中所有标记为 confidential: true 的 Secret。 结合 CRD 字段选择器(在 v1.31 中也晋级为 Beta 版),可以编写更安全的节点级别扩展。

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

对匿名 API 访问的限制

通过启用特性门控 AnonymousAuthConfigurableEndpoints,用户现在可以使用身份认证配置文件来配置可以通过匿名请求访问的端点。 这允许用户保护自己免受 RBAC 错误配置的影响;错误的配置可能会给匿名用户提供对集群的更多访问权限。

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

1.31 中的晋级、弃用和移除

晋级为稳定版

以下列出了所有晋级为稳定版(也称为 正式可用 )的功能。有关包括新功能和从 Alpha 晋级到 Beta 的完整列表,请参阅发行说明。

此版本包括总共 11 项晋级为稳定版的增强:

弃用和移除

随着 Kubernetes 的发展和成熟,某些特性可能会被弃用、移除或替换为更好的特性,以确保项目的整体健康。 有关此过程的更多详细信息,请参阅 Kubernetes 弃用和移除策略

Cgroup v1 进入维护模式

随着 Kubernetes 继续发展并适应容器编排不断变化的格局,社区决定在 v1.31 中将 cgroup v1 支持移入维护模式。 这一转变与行业中普遍向 cgroup v2 迁移的趋势一致, 提供了改进的功能、可扩展性和更一致的接口。 Kubernetes 维护模式意味着不会向 cgroup v1 支持添加新功能。 社区仍将提供关键的安全修复,但是,错误修复现在是尽力而为。 这意味着如果可行,可能会修复重大错误,但某些问题可能保持未解决状态。

建议您尽快开始切换到使用 cgroup v2。 这种转变取决于您的架构,包括确保底层操作系统和容器运行时支持 cgroup v2,以及测试工作负载以验证工作负载和应用程序在 cgroup v2 下是否正常运行。

如果遇到任何问题,请通过提交 issue 进行报告。

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

关于 SHA-1 签名支持的说明

go1.18(2022 年 3 月发布)中,crypto/x509 库开始拒绝使用 SHA-1 哈希函数签名的证书。 虽然 SHA-1 已被确定为不安全,并且公共信任的证书颁发机构自 2015 年以来就不再颁发 SHA-1 证书, 但在 Kubernetes 语境中可能仍然存在用户提供的证书通过私有机构使用 SHA-1 哈希函数签名的情况, 这些证书用于聚合 API 服务器或 Webhook。 如果您依赖基于 SHA-1 的证书,必须通过在环境变量中设置 GODEBUG=x509sha1=1 来明确选择重新启用其支持。

鉴于 Go 的 GODEBUG 兼容性策略x509sha1 GODEBUG 和对 SHA-1 证书的支持将在 go1.24 中完全消失, 而 go1.24 将在 2025 年上半年发布。 如果您依赖 SHA-1 证书,请开始迁移离开它们。

请查看 Kubernetes issue #125689 以了解有关 SHA-1 支持消失的时间线、Kubernetes 发布计划何时采用 go1.24, 以及如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。

弃用 Node 节点的 status.nodeInfo.kubeProxyVersion 字段 (KEP 4004)

节点的 .status.nodeInfo.kubeProxyVersion 字段在 Kubernetes v1.31 中已被弃用, 并将在以后的版本中删除。 它被弃用是因为这个字段的值不准确(现在也不准确)。 这个字段是由 kubelet 设置的,而 kubelet 没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。

DisableNodeKubeProxyVersion 特性门控将在 v1.31 中默认设置为 true,kubelet 将不再尝试为其关联的节点设置 .status.kubeProxyVersion 字段。

移除所有树内云提供商集成

正如之前的文章中强调的那样,作为 v1.31 发布的一部分,最后剩余的树内云平台集成支持已被移除。 这并不意味着您不能与云平台集成,但是您现在必须使用推荐的方法使用外部集成。一些集成是 Kubernetes 项目的一部分,而其他则是第三方软件。

这一里程碑标志着所有云提供商集成从 Kubernetes 核心外部化过程的完成(KEP-2395),这个过程始于 Kubernetes v1.26。 这一变化有助于 Kubernetes 更接近成为一个真正供应商中立的平台。

有关云提供商集成的更多详细信息,请阅读我们的 v1.29 云提供商集成功能博客。 有关树内代码移除的额外背景,我们邀请您查看(v1.29 弃用博客)。

后者的博客还包含了需要迁移到 v1.29 及更高版本的用户的有用信息。

移除树内供应商特性门控

在 Kubernetes v1.31 中,以下 Alpha 特性门控 InTreePluginAWSUnregisterInTreePluginAzureDiskUnregisterInTreePluginAzureFileUnregisterInTreePluginGCEUnregisterInTreePluginOpenStackUnregisterInTreePluginvSphereUnregister 已被移除。 这些特性门控的引入是为了便于测试从代码库中移除树内卷插件的场景,而无需实际移除它们。 由于 Kubernetes 1.30 已弃用这些树内卷插件,这些特性门控变得多余,不再有用。 唯一仍然存在的 CSI 迁移门控是 InTreePluginPortworxUnregister,它将保持 Alpha 状态, 直到 Portworx 的 CSI 迁移完成,其树内卷插件准备好被移除。

移除 kubelet 的 --keep-terminated-pod-volumes 命令行标志

作为 v1.31 版本的一部分,已移除 kubelet 标志 --keep-terminated-pod-volumes。该标志于 2017 年被弃用。

您可以在拉取请求 #122082 中找到更多详细信息。

移除 CephFS 卷插件

本次发布中移除了 CephFS 卷插件cephfs 卷类型变为不可用。

建议您改用 CephFS CSI 驱动 作为第三方存储驱动程序。 如果您在将集群版本升级到 v1.31 之前使用了 CephFS 卷插件,则必须重新部署应用程序以使用新的驱动程序。

CephFS 卷插件在 v1.28 中正式标记为废弃。

移除 Ceph RBD 卷插件

v1.31 版本移除了 Ceph RBD volume plugin 及其 CSI 迁移支持,使 rbd 卷类型变为不可用。

建议您在集群中改用 RBD CSI driver。 如果您在将集群版本升级到 v1.31 之前使用了 Ceph RBD 卷插件,则必须重新部署应用程序以使用新的驱动程序。

Ceph RBD 卷插件在 v1.28 中正式标记为废弃。

废弃 kube-scheduler 中的非 CSI 卷限制插件

v1.31 版本将废弃所有非 CSI 卷限制调度器插件,并将从默认插件中移除一些已废弃的插件,包括:

  • AzureDiskLimits
  • CinderLimits
  • EBSLimits
  • GCEPDLimits

建议您改用 NodeVolumeLimits 插件,因为自从这些卷类型迁移到 CSI 后,该插件可以处理与已移除插件相同的功能。 如果您在调度器配置中明确使用了已废弃的插件,请将它们替换为 NodeVolumeLimits 插件。 AzureDiskLimitsCinderLimitsEBSLimitsGCEPDLimits 插件将在未来的版本中被移除。

这些插件自 Kubernetes v1.14 以来已被废弃,将从默认调度器插件列表中移除。

发布说明和所需的升级操作

请在我们的发布说明中查看 Kubernetes v1.31 版本的完整详细信息。

启用 SchedulerQueueingHints 时,调度器现在使用 QueueingHint

社区为调度器添加了支持,以便在启用 SchedulerQueueingHints 功能门控时,开始使用为 Pod/Updated 事件注册的 QueueingHint,以确定对先前不可调度的 Pod 的更新是否使其变得可调度。 以前,当不可调度的 Pod 被更新时,调度器总是将 Pod 放回队列(activeQ / backoffQ)。 然而,并非所有对 Pod 的更新都会使 Pod 变得可调度,特别是考虑到现在许多调度约束是不可变更的。 在新的行为下,一旦不可调度的 Pod 被更新,调度队列会通过 QueueingHint 检查该更新是否可能使 Pod 变得可调度, 并且只有当至少一个 QueueingHint 返回 Queue 时,才将它们重新排队到 activeQbackoffQ

自定义调度器插件开发者需要采取的操作: 如果插件的拒绝可以通过更新未调度的 Pod 本身来解决,那么插件必须为 Pod/Update 事件实现 QueueingHint。 例如:假设您开发了一个自定义插件,该插件拒绝具有 schedulable=false 标签的 Pod。 鉴于带有 schedulable=false 标签的 Pod 在移除该标签后将变得可调度,这个插件将为 Pod/Update 事件实现 QueueingHint,当在未调度的 Pod 中进行此类标签更改时返回 Queue。 您可以在 pull request #122234 中找到更多详细信息。

移除 kubelet --keep-terminated-pod-volumes 命令行标志

作为 v1.31 版本的一部分,已移除 kubelet 标志 --keep-terminated-pod-volumes。该标志于 2017 年被弃用。 您可以在拉取请求 #122082 中找到更多详细信息。

可用性

Kubernetes v1.31 可在 GitHubKubernetes 下载页面上下载。

要开始使用 Kubernetes,请查看这些交互式教程或使用 minikube 运行本地 Kubernetes 集群。您还可以使用 kubeadm 轻松安装 v1.31。

发布团队

Kubernetes 的实现离不开社区的支持、投入和辛勤工作。 每个发布团队由致力于构建 Kubernetes 发布版本各个部分的专门社区志愿者组成。 这需要来自我们社区各个角落的人员的专业技能,从代码本身到文档和项目管理。

我们要感谢整个发布团队为向我们的社区交付 Kubernetes v1.31 版本所付出的时间和努力。 发布团队的成员从首次参与的影子成员到经历多个发布周期的回归团队负责人不等。 特别感谢我们的发布负责人 Angelos Kolaitis,他支持我们完成了一个成功的发布周期,为我们发声,确保我们都能以最佳方式贡献,并挑战我们改进发布过程。

项目速度

CNCF K8s DevStats 项目汇总了许多与 Kubernetes 及各个子项目速度相关的有趣数据点。 这包括从个人贡献到贡献公司数量的所有内容,展示了进化这个生态系统所投入的深度和广度。

在为期 14 周的 v1.31 发布周期(5 月 7 日至 8 月 13 日)中,我们看到来自 113 家不同公司和 528 个个人对 Kubernetes 的贡献。

在整个云原生生态系统中,我们有 379 家公司,共计 2268 名贡献者 - 这意味着相比上一个发布周期,个人贡献者数量惊人地增加了 63%!

数据来源:

贡献指的是当某人进行提交、代码审查、评论、创建问题或 PR、审查 PR(包括博客和文档)或对问题和 PR 进行评论。

如果您有兴趣贡献,请访问此页面开始。

查看 DevStats 以了解更多关于 Kubernetes 项目和社区整体速度的信息。

活动更新

探索 2024 年 8 月至 11 月即将举行的 Kubernetes 和云原生活动,包括 KubeCon、KCD 和其他全球知名会议。保持了解并参与 Kubernetes 社区。

2024 年 8 月

2024 年 9 月

2024 年 10 月

2024 年 11 月

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

加入 Kubernetes v1.31 发布团队成员,于 2024 年 9 月 12 日星期四太平洋时间上午 10 点了解此版本的主要特性,以及废弃和移除的内容,以帮助规划升级。 有关更多信息和注册,请访问 CNCF 在线项目网站上的活动页面

参与其中

参与 Kubernetes 的最简单方式是加入与您兴趣相符的众多特殊兴趣小组(SIG)之一。 您有什么想向 Kubernetes 社区广播的内容吗? 在我们的每周社区会议上分享您的声音,并通过以下渠道。 感谢您持续的反馈和支持。