本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.31: Elli

作者：Kubernetes v1.31 发布团队 |

编辑：Matteo Bianchi、Yigit Demirbas、Abigail McCarthy、Edith Puclla、Rashan Smith

宣布 Kubernetes v1.31 版本发布：Elli！

与之前的版本类似，Kubernetes v1.31 引入了新的 Stable、Beta 和 Alpha 特性。高质量版本的持续交付凸显了我们开发周期的实力以及我们社区的活跃支持。此版本包含 45 项增强功能。其中，11 项已进阶至 Stable，22 项进入 Beta，12 项进阶至 Alpha。

Kubernetes v1.31 版本的发布主题是 “Elli”。

Kubernetes v1.31 的 Elli 是一只可爱快乐的狗，有一颗金子般的心，戴着一顶漂亮的水手帽，这是对 Kubernetes 庞大而多元的贡献者家庭的一个俏皮的致意。

Kubernetes v1.31 标志着该项目成功庆祝其第一个 10 年后的首次发布。自诞生以来，Kubernetes 已经走过了很长的路，并且每个版本仍在朝着令人兴奋的新方向发展。10 年后，回顾无数 Kubernetes 贡献者的努力、奉献、技能、智慧和辛勤工作，他们使这一切成为现实，这令人敬畏。

然而，尽管运行该项目需要巨大的努力，但仍不乏一次又一次地以热情、微笑和为社区做出贡献和成为其中一员的自豪感出现的人。我们从新老贡献者身上看到的这种“精神”是一个充满活力的社区的标志，如果我们愿意的话，可以称之为“快乐”的社区。

Kubernetes v1.31 的 Elli 就是为了庆祝这种美妙的精神！为 Kubernetes 的下一个十年干杯！

进入 Stable 阶段的特性亮点

以下是 v1.31 版本发布后进入 Stable 阶段的一些改进。

AppArmor 支持进入 Stable

Kubernetes 对 AppArmor 的支持现已进入正式发布（GA）阶段。通过在容器的 securityContext 中设置 appArmorProfile.type 字段，使用 AppArmor 保护你的容器。请注意，在 Kubernetes v1.30 之前，AppArmor 是通过注解控制的；从 v1.30 开始，它通过字段进行控制。建议你从使用注解迁移到使用 appArmorProfile.type 字段。

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

提高 kube-proxy 的 Ingress 连接可靠性

Kube-proxy 提高 Ingress 连接可靠性的功能在 v1.31 中进入 Stable 阶段。Kubernetes 中负载均衡器的一个常见问题是不同组件之间的同步，以避免流量中断。该功能在 kube-proxy 中实现了一种机制，供负载均衡器为 type: LoadBalancer 和 externalTrafficPolicy: Cluster 类型的 Service 所暴露的终止节点执行连接排空，并为云提供商和 Kubernetes 负载均衡器实现建立了一些最佳实践。

要使用此功能，kube-proxy 需要作为集群上的默认 Service 代理运行，并且负载均衡器需要支持连接排空。使用此功能无需特殊更改，自 v1.30 起，它在 kube-proxy 中默认启用，并在 v1.31 中进阶至 Stable。

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

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

PersistentVolume 的最后阶段转换时间

PersistentVolume 的最后阶段转换时间功能在 v1.31 中进阶至 GA。此功能添加了一个 PersistentVolumeStatus 字段，用于保存 PersistentVolume 上次转换到不同阶段的时间戳。启用此功能后，每个 PersistentVolume 对象都会有一个新字段 .status.lastTransitionTime，用于保存卷上次转换阶段的时间戳。此更改不是立即生效的；升级到 Kubernetes v1.31 后，当 PersistentVolume 更新并首次在阶段（Pending、Bound 或 Released）之间转换时，将填充新字段。这使你能够测量 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 模式更快、更高效地处理 Service 端点的更改，并且还能在内核中更高效地处理数据包（尽管这只有在具有数万个 Service 的集群中才变得明显）。

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

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

PersistentVolume 回收策略的更改

“始终遵守 PersistentVolume 回收策略”功能已在 Kubernetes v1.31 中进阶至 Beta。此增强功能确保即使在关联的 PersistentVolumeClaim（PVC）被删除后，PersistentVolume（PV）的回收策略也能得到遵守，从而防止卷泄漏。

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

随着此功能的引入，Kubernetes 现在保证“Delete”回收策略将被强制执行，确保从后端基础架构中删除底层存储对象，无论 PV 和 PVC 的删除顺序如何。

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

绑定的 Service Account 令牌改进

ServiceAccountTokenNodeBinding 功能在 v1.31 中进阶至 Beta。此功能允许请求仅绑定到节点而不绑定到 Pod 的令牌，这在令牌的声明中包含节点信息，并在使用令牌时验证节点的存在。有关更多信息，请阅读绑定服务帐户令牌文档。

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

多个 Service CIDR

支持具有多个 Service CIDR 的集群的功能在 v1.31 中进入 Beta 阶段（默认禁用）。

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

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

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

Service 流量分发

Service 的流量分发在 v1.31 中进入 Beta 阶段，并默认启用。

在为 Service 网络寻找最佳用户体验和流量工程能力的多次迭代之后，SIG Networking 在 Service 规范中实现了 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 时分配 ResourceClaim。通过 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 Node 和 SIG Storage 完成。

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

通过 Pod 状态暴露设备健康信息作为 v1.31 中的新 Alpha 功能添加，默认禁用。

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

启用此功能后，allocatedResourcesStatus 字段将添加到每个容器的状态中，位于每个 Pod 的 .status 内。allocatedResourcesStatus 字段报告分配给容器的每个设备的健康信息。

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

基于选择器的更细粒度授权

此功能允许 webhook 授权器和未来的（但目前尚未设计的）树内授权器允许 list 和 watch 请求，前提是这些请求使用标签和/或字段选择器。例如，现在授权器可以表示：此用户不能列出所有 Pod，但可以列出 .spec.nodeName 匹配某个特定值的所有 Pod。或者允许用户监视命名空间中所有未标记为 confidential: true 的 Secret。结合 CRD 字段选择器（也在 v1.31 中进入 Beta），可以编写更安全的每节点扩展。

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

对匿名 API 访问的限制

通过启用特性门控 AnonymousAuthConfigurableEndpoints，用户现在可以使用身份验证配置文件来配置可由匿名请求访问的端点。这允许用户保护自己免受可能给予匿名用户对集群广泛访问权限的 RBAC 错误配置的影响。

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

v1.31 中的进阶、弃用和移除

升级为稳定版

这里列出了所有升级到稳定版（也称为**正式发布**）的功能。有关包括新功能和从 Alpha 升级到 Beta 的完整更新列表，请参阅发布说明。

此版本共包含 11 项进阶至 Stable 的增强功能

弃用和移除

随着 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 中完全取消，该版本将于 2025 年上半年发布。如果你依赖于 SHA-1 证书，请开始迁移。

请参阅 Kubernetes issue #125689，以更好地了解 SHA-1 支持取消的时间表，Kubernetes 版本计划何时采用 go1.24，以及有关如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。

弃用 Node 的 status.nodeInfo.kubeProxyVersion 字段（KEP 4004）

Node 的 .status.nodeInfo.kubeProxyVersion 字段已在 Kubernetes v1.31 中弃用，并将在以后的版本中移除。弃用它的原因是因为此字段的值不准确。此字段由 kubelet 设置，kubelet 并没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。

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

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

正如上一篇文章中所强调的，最后剩余的对云提供商集成的树内支持已作为 v1.31 版本的一部分被移除。这并不意味着你不能与云提供商集成，但是你现在必须使用推荐的方法，即使用外部集成。一些集成是 Kubernetes 项目的一部分，而另一些是第三方软件。

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

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

后一篇博客还为需要迁移到 v1.29 及更高版本的用户提供了有用的信息。

移除树内提供商特性门控

在 Kubernetes v1.31 中，以下 alpha 特性门控 InTreePluginAWSUnregister、InTreePluginAzureDiskUnregister、InTreePluginAzureFileUnregister、InTreePluginGCEUnregister、InTreePluginOpenStackUnregister 和 InTreePluginvSphereUnregister 已被移除。引入这些特性门控是为了方便测试从代码库中移除树内卷插件的场景，而无需实际移除它们。由于 Kubernetes 1.30 已弃用这些树内卷插件，这些特性门控是多余的，不再有任何用途。唯一仍然存在的 CSI 迁移门控是 InTreePluginPortworxUnregister，它将保持在 alpha 阶段，直到 Portworx 的 CSI 迁移完成并且其树内卷插件准备好被移除。

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

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

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

移除 CephFS 卷插件

在此版本中， CephFS 卷插件被移除，cephfs 卷类型变得不可用。

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

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

移除 Ceph RBD 卷插件

v1.31 版本移除了 Ceph RBD 卷插件及其 CSI 迁移支持，使得 rbd 卷类型不可用。

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

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

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

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

  • AzureDiskLimits
  • CinderLimits
  • EBSLimits
  • GCEPDLimits

建议你使用 NodeVolumeLimits 插件，因为它可以处理与已移除插件相同的功能，因为这些卷类型已经迁移到 CSI。如果你在调度器配置中明确使用它们，请将已弃用的插件替换为 NodeVolumeLimits 插件。AzureDiskLimits、CinderLimits、EBSLimits 和 GCEPDLimits 插件将在未来的版本中移除。

这些插件将从默认调度器插件列表中移除，因为它们自 Kubernetes v1.14 以来已被弃用。

发布说明和所需升级操作

请在我们的发布说明中查看 Kubernetes v1.31 发布的全部详细信息。

当启用 SchedulerQueueingHints 时，调度器现在使用 QueueingHint

增加了对调度器的支持，以开始使用为 Pod/Updated 事件注册的 QueueingHint，以确定对先前不可调度 Pod 的更新是否使它们变得可调度。当特性门控 SchedulerQueueingHints 启用时，新支持生效。

以前，当不可调度的 Pod 被更新时，调度器总是将 Pod 放回队列中（activeQ / backoffQ）。然而，并非所有对 Pod 的更新都使 Pod 可调度，特别是考虑到现在许多调度约束是不可变的。在新的行为下，一旦不可调度的 Pod 被更新，调度队列会与 QueueingHint 检查更新是否可能使 Pod 可调度，并且只有当至少一个 QueueingHint 返回 Queue 时，才会将它们重新排队到 activeQ 或 backoffQ。

自定义调度器插件开发者所需的操作：如果插件的拒绝可以通过更新未调度的 Pod 本身来解决，则插件必须为 Pod/Update 事件实现一个 QueueingHint。示例：假设你开发了一个自定义插件，该插件拒绝具有 schedulable=false 标签的 Pod。鉴于具有 schedulable=false 标签的 Pod 如果移除了 schedulable=false 标签，它们将变得可调度，此插件将为 Pod/Update 事件实现 QueueingHint，当在未调度的 Pod 中进行此类标签更改时返回 Queue。你可以在拉取请求 #122234 中找到更多详细信息。

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

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

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

可用性

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

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

发布团队

Kubernetes 的存在离不开其社区的支持、承诺和辛勤工作。每个发布团队都由敬业的社区志愿者组成，他们共同努力，构建构成你所依赖的 Kubernetes 版本的许多部分。这需要我们社区各个角落的人员的专业技能，从代码本身到其文档和项目管理。

我们想感谢整个发布团队，感谢他们为向我们的社区交付 Kubernetes v1.31 版本而付出的辛勤工作。发布团队的成员范围从首次参与的“影子”到经验丰富的团队负责人，他们的经验是在几个发布周期中锻造的。特别感谢我们的发布负责人 Angelos Kolaitis，感谢他在一个成功的发布周期中支持我们，为我们发声，确保我们都能以最佳方式做出贡献，并挑战我们改进发布流程。

项目速度

CNCF K8s DevStats 项目汇总了许多与 Kubernetes 和各种子项目的速度相关的有趣数据点。这包括从个人贡献到做出贡献的公司数量的所有内容，并且是说明这个生态系统演变所付出的努力的深度和广度的例证。

在 v1.31 发布周期中，该周期持续了 14 周（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 月

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

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

参与其中

参与 Kubernetes 的最简单方法是加入众多与你的兴趣相符的特殊兴趣小组（SIG）之一。有什么你想向 Kubernetes 社区广播的吗？在我们每周的社区会议上，以及通过以下渠道分享你的声音。感谢你持续的反馈和支持。