Kubernetes v1.31：Elli

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

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

宣布发布 Kubernetes v1.31：Elli！

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

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

Kubernetes v1.31 的 Elli 是一只可爱快乐的狗狗，拥有一颗金子般的心和一顶漂亮的水手帽， playfully 向庞大而多元的 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 是通过 annotations 控制的；从 v1.30 开始，它使用字段进行控制。建议您从使用 annotations 迁移，并开始使用 appArmorProfile.type 字段。

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

kube-proxy 的 Ingress 连接可靠性改进

kube-proxy 的 Ingress 连接可靠性改进在 v1.31 中已稳定。Kubernetes 中负载均衡器的常见问题之一是相关不同组件之间的同步，以避免流量丢失。此功能在 kube-proxy 中实现了一种机制，使负载均衡器能够对类型为 type: LoadBalancer 且 externalTrafficPolicy: Cluster 的 Service 所暴露的正在终止的节点进行连接排水，并为云提供商和 Kubernetes 负载均衡器实现建立一些最佳实践。

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

有关此功能的更多详细信息，请访问Virtual IPs 和 Service Proxies 文档页面。

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

Persistent Volume 最后阶段转换时间

Persistent Volume 最后阶段转换时间功能在 v1.31 中迁移到正式发布 (GA)。此功能添加了一个 PersistentVolumeStatus 字段，其中包含 PersistentVolume 最后一次转换到不同阶段的时间戳。启用此功能后，每个 PersistentVolume 对象将有一个新的字段 .status.lastTransitionTime，其中包含卷最后一次转换阶段的时间戳。此更改并非立即生效；新字段将在 PersistentVolume 更新且在升级到 Kubernetes v1.31 后首次在阶段之间转换（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 模式能够更快、更有效地处理服务端点的更改，并且还能更有效地处理内核中的数据包（尽管这只有在拥有数万个服务的集群中才会变得明显）。

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

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

PersistentVolumes 的回收策略更改

Always Honor PersistentVolume Reclaim Policy 功能在 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

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

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

有关此功能的更多详细信息，请访问Virtual IPs 和 Service Proxies 文档页面。

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

Service 流量分配

Service 流量分配在 v1.31 中迁移到 Beta 阶段，并默认启用。

在多次迭代寻找 Service 网络最佳用户体验和流量工程能力后，SIG Network 在 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 时分配 ResourceClaims。通过现在称为“经典 DRA”的方式，DRA 驱动程序控制器仍支持分配。

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

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

支持镜像卷

Kubernetes 社区正在努力在未来实现更多人工智能 (AI) 和机器学习 (ML) 用例。

实现这些用例的需求之一是直接将 Open Container Initiative (OCI) 兼容的镜像和 artifacts（称为 OCI 对象）作为原生卷源支持。这使得用户能够专注于 OCI 标准，并使他们能够使用 OCI registry 存储和分发任何内容。

因此，v1.31 添加了一项新的 Alpha 功能，允许在 Pod 中使用 OCI 镜像作为卷。此功能允许用户在 Pod 中将镜像引用指定为卷，并在容器内将其作为卷挂载重复使用。您需要启用 ImageVolume 功能门才能尝试此功能。

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

通过 Pod status 暴露设备健康信息

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

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

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

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

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

此功能允许 webhook authorizer 和未来（但目前尚未设计）的 in-tree authorizer 允许 **list** 和 **watch** 请求，前提是这些请求使用标签或字段选择器。例如，现在 authorizer 可以表达：此用户不能列出所有 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 的广泛迁移保持一致，cgroup v2 提供了改进的功能、可伸缩性和更一致的接口。Kubernetes 的维护模式意味着 cgroup v1 支持将不会添加新功能。关键安全漏洞修复仍会提供，但 Bug 修复现在采取尽力而为的方式，这意味着主要 Bug 如果可行可能会被修复，但某些问题可能仍未解决。

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

如果您遇到任何问题，请通过提交一个 issue 来报告。

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

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

在 go1.18（于 2022 年 3 月发布）中，crypto/x509 库开始拒绝使用 SHA-1 散列函数签名的证书。虽然 SHA-1 已被证实不安全，并且公开信任的证书颁发机构自 2015 年以来不再颁发 SHA-1 证书，但在 Kubernetes 的上下文中，仍可能存在用户通过私有机构提供使用 SHA-1 散列函数签名的证书，并将其用于 Aggregated API Server 或 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 版本或其是否运行的可靠信息。

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

移除所有树内（in-tree）云提供商集成

如之前一篇文章所述，剩余的最后一个树内（in-tree）云提供商集成支持已作为 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 版本的一部分被移除。

您可以在 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/Updated 事件注册的 QueueingHint，以确定对先前不可调度的 Pod 进行的更新是否使其变为可调度。当特性门控 SchedulerQueueingHints 被启用时，此新支持会生效。

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

**自定义调度器插件开发者所需操作**：如果其拒绝原因可以通过更新未调度的 Pod 本身来解决，则插件必须为 Pod/Update 事件实现 QueueingHint。例如：假设您开发了一个自定义插件，该插件拒绝带有 schedulable=false 标签的 Pod。鉴于带有 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 及各个子项目速度相关的许多有趣数据点。这包括从个人贡献到贡献公司数量的所有信息，说明了投入到这个生态系统演进中的努力的深度和广度。

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

在整个云原生生态系统中，共有 379 家公司和 2268 位总贡献者 - 这意味着与上一个发布周期相比，个人贡献者数量惊人地增长了 63%！

数据来源

贡献是指有人进行提交、代码评审、评论、创建 Issue 或 PR、评审 PR（包括博客和文档）或评论 Issue 和 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 社区传达的吗？在我们的每周社区会议和以下渠道中分享您的声音。感谢您一直以来的反馈和支持。