Kubernetes v1.31：Elli

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

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

宣布 Kubernetes v1.31 版本：Elli！

与之前的版本类似，Kubernetes v1.31 的发布引入了新的稳定版、测试版和 alpha 版功能。高质量版本的持续交付突显了我们开发周期的实力以及我们社区的蓬勃支持。此版本包含 45 项增强功能。在这些增强功能中，11 个已升级为稳定版，22 个已进入测试版，12 个已升级为 alpha 版。

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

Kubernetes v1.31 的 Elli 是一只可爱而快乐的狗狗，拥有一颗金子般的心和一顶漂亮的船长帽，它俏皮地向 Kubernetes 贡献者的庞大而多样化的家庭致敬。

Kubernetes v1.31 标志着该项目成功庆祝 成立 10 周年 后的第一个版本。自成立以来，Kubernetes 已经走了很长一段路，并且随着每个版本的发布，它仍然朝着令人兴奋的新方向发展。经过 10 年的发展，令人敬畏的是，无数 Kubernetes 贡献者为实现这一目标所付出的努力、奉献精神、技能、才智和辛勤工作。

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

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

升级到稳定版的功能亮点

以下是 v1.31 版本发布后现在处于稳定状态的一些改进的精选。

AppArmor 支持现在稳定

Kubernetes 对 AppArmor 的支持现在已 GA。通过在容器的 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: LoadBalancer 和 externalTrafficPolicy: Cluster 服务公开的终止节点执行连接耗尽，并为云提供商和 Kubernetes 负载均衡器实施建立一些最佳实践。

要使用此功能，kube-proxy 需要作为集群上的默认服务代理运行，并且负载均衡器需要支持连接耗尽。使用此功能不需要进行任何特定更改，它自 v1.30 起已在 kube-proxy 中默认启用，并在 v1.31 中升级为稳定版。

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

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

持久卷上次阶段转换时间

持久卷上次阶段转换时间功能在 v1.31 中升级到 GA。此功能添加了一个 PersistentVolumeStatus 字段，其中保存了持久卷上次转换到不同阶段的时间戳。启用此功能后，每个持久卷对象都将有一个新字段 .status.lastTransitionTime，其中保存了卷上次转换阶段的时间戳。此更改不是立即的；每当持久卷更新并且在升级到 Kubernetes v1.31 后首次在各个阶段（Pending、Bound 或 Released）之间转换时，新字段将被填充。这允许您测量持久卷从 Pending 移动到 Bound 之间的时间。这对于提供指标和 SLO 也很有用。

有关此功能的更多详细信息，请访问 PersistentVolume 文档页面。

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

升级到测试版的功能亮点

以下是 v1.31 版本发布后现在处于测试状态的一些改进的精选。

kube-proxy 的 nftables 后端

nftables 后端在 v1.31 中移动到测试版，位于现在默认启用的 NFTablesProxyMode 功能门之后。

nftables API 是 iptables API 的后继产品，旨在提供比 iptables 更好的性能和可扩展性。nftables 代理模式能够比 iptables 模式更快、更有效地处理对服务端点的更改，并且还能够更有效地处理内核中的数据包（尽管这只有在具有数万个服务的集群中才变得明显）。

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

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

持久卷的回收策略更改

Always Honor 持久卷回收策略功能已在 Kubernetes v1.31 中升级到测试版。此增强功能确保即使在删除关联的持久卷声明 (PVC) 后，也尊重持久卷 (PV) 回收策略，从而防止卷泄漏。

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

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

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

绑定的服务帐户令牌改进

ServiceAccountTokenNodeBinding 功能在 v1.31 中升级到测试版。此功能允许请求仅绑定到节点的令牌，而不是绑定到 pod 的令牌，该令牌在令牌中的声明中包含节点信息，并在使用令牌时验证节点的存在。有关更多信息，请阅读 绑定的服务帐户令牌文档。

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

多个 Service CIDR

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

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

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

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

服务的流量分配

服务的流量分配在 v1.31 中进入 Beta 阶段，并且默认启用。

在多次迭代以寻找服务网络的最佳用户体验和流量工程功能之后，SIG Network 在服务规范中实现了 trafficDistribution 字段，该字段作为底层实现进行路由决策时需要考虑的指导原则。

有关此功能的更多详细信息，请阅读 1.30 版本博客 或访问 服务 文档页面。

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

Kubernetes VolumeAttributesClass 修改卷

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) 用例的方向发展。

满足这些用例的要求之一是直接支持与 Open Container Initiative (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 字段将添加到每个容器状态的 .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 完成。

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 时是否正常运行。

请通过提交 问题 来报告您遇到的任何问题。

这项工作是 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 证书使用情况的更多详细信息。

弃用节点的 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 项目的一部分，另一些是第三方软件。

这个里程碑标志着所有云提供商从 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 版本的一部分已被删除。

您可以在 pull request #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/更新事件注册的 QueueingHint，以确定对先前无法调度的 Pod 的更新是否使其可调度。当启用特性门控 SchedulerQueueingHints 时，新支持处于活动状态。

以前，当无法调度的 Pod 被更新时，调度器总是将 Pod 放回队列（activeQ / backoffQ）。但是，并非所有对 Pod 的更新都会使 Pod 可调度，尤其是在考虑到现在许多调度约束都是不可变的。在新行为下，一旦更新了无法调度的 Pod，调度队列会使用 QueueingHint(s) 检查更新是否可能使 Pod 可调度，并且仅当至少一个 QueueingHint 返回 Queue 时才将它们重新排队到 activeQ 或 backoffQ。

自定义调度器插件开发人员所需的操作：如果从插件的拒绝可以通过更新未调度的 Pod 本身来解决，则插件必须为 Pod/Update 事件实现 QueueingHint。示例：假设您开发一个自定义插件，该插件拒绝具有 schedulable=false 标签的 Pod。如果删除了 schedulable=false 标签，则具有 schedulable=false 标签的 Pod 将是可调度的，此插件将为 Pod/Update 事件实现 QueueingHint，该事件在未调度的 Pod 中进行此类标签更改时返回 Queue。您可以在 pull request #122234 中找到更多详细信息。

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

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

您可以在 pull request #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 发布周期（5 月 7 日至 8 月 13 日，历时 14 周）中，我们看到了来自 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 社区广播的内容？请在我们的每周社区会议以及以下渠道中分享您的声音。感谢您持续的反馈和支持。