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

Kubernetes v1.29: Mandala

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

编辑：Carol Valencia、Kristin Martin、Abigail McCarthy、James Quigley

我们宣布 Kubernetes v1.29：曼荼罗（宇宙）的发布，这是 2023 年的最后一个版本！

与之前的版本类似，Kubernetes v1.29 的发布引入了新的稳定、Beta 和 Alpha 特性。高质量版本的持续交付凸显了我们开发周期的实力以及社区充满活力的支持。

此版本包含 49 项增强功能。其中 11 项已进阶至稳定版，19 项进入 Beta 版，19 项已进阶至 Alpha 版。

Kubernetes v1.29：曼荼罗（宇宙） ✨🌌

与 Kubernetes v1.29 一起踏上宇宙之旅！

这个版本的灵感来自美丽的艺术形式——曼荼罗，它是完美宇宙的象征。我们由大约 40 名发布团队成员组成的紧密团结的宇宙，在数百名社区贡献者的支持下，不懈地努力，将挑战转化为全球数百万人的喜悦。

曼荼罗主题反映了我们社区的互联性——一幅由爱好者和专家共同编织的充满活力的织锦。每一位贡献者都是至关重要的一部分，贡献着他们独特的能量，就像曼荼罗艺术中多样化的图案一样。Kubernetes 的发展依赖于协作，这与曼荼罗创作中的和谐相呼应。

该版本的徽标由 Mario Jason Braganza 制作（基础曼荼罗艺术由 Fibrel Ojalá 提供），象征着 Kubernetes 项目及其所有成员所构成的小宇宙。

本着曼荼罗变革象征主义的精神，Kubernetes v1.29 庆祝我们项目的演进。就像 Kubernetes 宇宙中的星星一样，每一位贡献者、用户和支持者都照亮了前行的道路。我们一起创造一个充满可能性的宇宙——一次一个版本。

Kubernetes v1.29 中进阶至稳定的改进

以下是 v1.29 发布后现已稳定的一些改进的精选。

ReadWriteOncePod 持久卷访问模式（SIG Storage）

在 Kubernetes 中，卷访问模式是你定义如何使用持久存储的方式。这些访问模式是 PersistentVolumes (PVs) 和 PersistentVolumeClaims (PVCs) 规约的一部分。在使用存储时，有不同的方式来建模存储的使用方式。例如，像网络文件共享这样的存储系统可以有许多用户同时读取和写入数据。在其他情况下，也许允许所有人读取数据但不允许写入。对于高度敏感的数据，也许只允许一个用户读取和写入数据，而其他人则不行。

在 v1.22 之前，Kubernetes 为 PVs 和 PVCs 提供了三种访问模式

  • ReadWriteOnce – 卷可以被单个节点以读写方式挂载
  • ReadOnlyMany – 卷可以被多个节点以只读方式挂载
  • ReadWriteMany – 卷可以被多个节点以读写方式挂载

ReadWriteOnce 访问模式将卷的访问限制在单个节点上，这意味着同一节点上的多个 Pod 可以读写同一个卷。这对于某些应用程序来说可能是一个主要问题，特别是如果它们为了数据安全保证而要求最多只有一个写入者。

为了解决这个问题，v1.22 中为 CSI 卷引入了第四种访问模式 ReadWriteOncePod 作为 Alpha 特性。如果你创建一个使用 ReadWriteOncePod 访问模式的 PVC 的 Pod，Kubernetes 会确保该 Pod 是整个集群中唯一可以读取或写入该 PVC 的 Pod。在 v1.29 中，此特性已正式发布。

CSI 驱动程序支持节点卷扩展 Secret（SIG Storage）

在 Kubernetes 中，卷扩展操作可能包括在节点上扩展卷，这涉及到文件系统的大小调整。一些 CSI 驱动程序在节点扩展期间需要 Secret（例如用于访问 SAN 网络的凭据），以用于以下用例：

  • 当 PersistentVolume 代表加密的块存储时，例如使用 LUKS，你可能需要提供一个密码来扩展设备。
  • 为了进行各种验证，CSI 驱动程序需要在节点扩展时拥有与后端存储系统通信的凭据。

为了满足这一要求，Kubernetes v1.25 中引入了 CSI 节点扩展 Secret 特性。这允许 CSI 驱动程序在 NodeExpandVolumeRequest 中发送一个可选的 Secret 字段，以便可以使用底层存储系统执行节点卷扩展操作。在 Kubernetes v1.29 中，此特性已正式发布。

KMS v2 静态加密正式发布（SIG Auth）

在保护 Kubernetes 集群时，首先要考虑的事情之一是加密持久化的 API 静态数据。KMS 为提供商提供了一个接口，以利用存储在外部密钥服务中的密钥来执行此加密。随着 Kubernetes v1.29 的发布，KMS v2 已成为一个稳定的特性，在性能、密钥轮换、健康检查与状态以及可观察性方面带来了众多改进。这些增强功能为用户提供了一个可靠的解决方案，用于加密其 Kubernetes 集群中的所有资源。你可以在 KEP-3299 中阅读更多相关信息。

建议使用 KMS v2。KMS v1 的特性门控默认是禁用的。你将必须选择性启用才能继续使用它。

Kubernetes v1.29 中进阶至 Beta 的改进

以下是 v1.29 发布后现已进入 Beta 的一些改进的精选。

调度程序的吞吐量是我们永恒的挑战。这个 QueueingHint 特性为优化重新排队的效率带来了新的可能性，这可以显著减少无用的调度重试。

节点生命周期与污点管理分离（SIG Scheduling）

如标题所述，这是为了将执行基于污点的 Pod 驱逐的 `TaintManager` 从 `NodeLifecycleController` 中解耦出来，使它们成为两个独立的控制器：`NodeLifecycleController` 用于向不健康的节点添加污点，而 `TaintManager` 用于在带有 NoExecute 效果的污点节点上执行 Pod 删除。

清理遗留的基于 Secret 的 ServiceAccount 令牌（SIG Auth）

Kubernetes 在 1.22 版本中切换到使用更安全的服务账户令牌，这些令牌是时间限制的并绑定到特定的 Pod。在 1.24 版本中停止自动生成遗留的基于 Secret 的服务账户令牌。然后在 1.27 版本中开始为仍在使用的剩余自动生成的基于 Secret 的令牌标记其最后使用日期。

在 v1.29 中，为了减少潜在的攻击面，LegacyServiceAccountTokenCleanUp 特性将长时间未使用（默认为 1 年）的遗留自动生成的基于 Secret 的令牌标记为无效，并在被标记为无效后长时间未尝试使用（默认为额外的 1 年）时自动删除它们。KEP-2799

新的 Alpha 特性

使用 `matchLabelKeys` 定义 Pod 亲和性或反亲和性（SIG Scheduling）

PodAffinity/PodAntiAffinity 中将引入一项 Alpha 增强功能。它将提高滚动更新期间计算的准确性。

kube-proxy 的 nftables 后端（SIG Network）

目前在 Linux 上的默认 kube-proxy 实现是基于 iptables 的。这是 Linux 内核中多年来首选的数据包过滤和处理系统（从 2001 年的 2.4 内核开始）。然而，iptables 无法解决的问题导致了其后继者 nftables 的开发。iptables 的开发已基本停止，新特性和性能改进主要都集中在 nftables 上。

此特性为 kube-proxy 添加了一个基于 nftables 的新后端，因为一些 Linux 发行版已经开始弃用和移除 iptables，并且 nftables 声称解决了 iptables 的主要性能问题。

用于管理 Service IP 地址范围的 API（SIG Network）

Service 是一种抽象的方式，用于暴露在一组 Pod 上运行的应用程序。Service 可以有一个集群范围的虚拟 IP 地址，该地址从 kube-apiserver 标志中定义的预定义 CIDR 中分配。然而，用户可能希望在不重启 kube-apiserver 的情况下添加、删除或调整分配给 Service 的现有 IP 范围。

此特性实现了一个新的分配器逻辑，它使用两个新的 API 对象：ServiceCIDR 和 IPAddress，允许用户通过创建新的 ServiceCIDR 动态增加可用的 Service IP 数量。这有助于解决 IP 耗尽或 IP 重新编号等问题。

为 containerd/kubelet/CRI 添加支持，以支持按运行时类别拉取镜像（SIG Windows）

Kubernetes v1.29 添加了基于使用容器镜像的 Pod 的 RuntimeClass 来拉取容器镜像的支持。此特性在 v1.29 中默认关闭，受名为 `RuntimeClassInImageCriApi` 的特性门控控制。

容器镜像可以是清单或索引。当被拉取的镜像是索引时（镜像索引有一个按平台排序的镜像清单列表），容器运行时中的平台匹配逻辑用于从索引中拉取合适的镜像清单。默认情况下，平台匹配逻辑会选择一个与执行镜像拉取的主机匹配的清单。这对于基于虚拟机的容器来说可能有限制，因为用户可能会拉取一个镜像，意图将其作为基于虚拟机的容器运行，例如 Windows Hyper-V 容器。

按运行时类别拉取镜像的特性增加了根据指定的运行时类别拉取不同镜像的支持。这是通过使用一个（`imageID`, `runtimeClass`）元组来引用镜像，而不是仅仅使用 `imageName` 或 `imageID`。容器运行时可以选择添加对此特性的支持。如果它们不支持，将保留 Kubernetes v1.29 之前存在的 kubelet 默认行为。

Windows Pods 资源的原地更新（SIG Windows）

作为一项 Alpha 特性，Kubernetes Pods 的 `resources` 可以是可变的，允许用户更改 Pod 的*期望*资源请求和限制，而无需重启 Pod。在 v1.29 中，此特性现在支持 Windows 容器。

Kubernetes v1.29 的进阶、弃用和移除

进阶至稳定

这列出了所有进阶至稳定（也称为*正式发布*）的特性。有关包括新特性和从 Alpha 到 Beta 的进阶在内的完整更新列表，请参阅发布说明。

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

弃用和移除

移除与云提供商的树内集成（SIG Cloud Provider）

Kubernetes v1.29 默认*不带*任何内置的云提供商集成来运行。如果你之前一直依赖树内的云提供商集成（Azure、GCE 或 vSphere），那么你可以选择：

  • 启用一个等效的外部云控制器管理器集成*（推荐）*
  • 通过将相关的特性门控设置为 `false` 来重新选择使用遗留集成；需要更改的特性门控是 `DisableCloudProviders` 和 `DisableKubeletCloudCredentialProviders`

启用外部云控制器管理器意味着你必须在集群的控制平面内运行一个合适的云控制器管理器；它还要求为 kubelet（在每个相关节点上）和整个控制平面（kube-apiserver 和 kube-controller-manager）设置命令行参数 `--cloud-provider=external`。

有关如何启用和运行外部云控制器管理器的更多信息，请阅读云控制器管理器管理和迁移副本控制平面以使用云控制器管理器。

如果你需要一个用于遗留树内提供商之一的云控制器管理器，请参阅以下链接

更多细节请见 KEP-2395。

移除 `v1beta2` 流控制 API 组

已弃用的 FlowSchema 和 PriorityLevelConfiguration 的 *flowcontrol.apiserver.k8s.io/v1beta2* API 版本在 Kubernetes v1.29 中不再提供服务。

如果你的清单或客户端软件使用已弃用的 Beta API 组，你应该在升级到 v1.29 之前进行更改。有关详细信息和建议，请参阅已弃用 API 迁移指南。

弃用 Node 的 `status.nodeInfo.kubeProxyVersion` 字段

Node 对象的 `.status.kubeProxyVersion` 字段现已弃用，Kubernetes 项目提议在未来的版本中移除该字段。这个已弃用的字段不准确，历史上由 kubelet 管理——而 kubelet 实际上并不知道 kube-proxy 的版本，甚至不知道 kube-proxy 是否在运行。

如果你一直在客户端软件中使用此字段，请停止使用——该信息不可靠，且该字段现已弃用。

遗留的 Linux 软件包仓库

请注意，在 2023 年 8 月，遗留的软件包仓库（`apt.kubernetes.io` 和 `yum.kubernetes.io`）被正式弃用，Kubernetes 项目宣布了社区拥有的 Debian 和 RPM 软件包仓库的正式发布，可在 `https://pkgs.k8s.io` 访问。

这些遗留仓库已于 2023 年 9 月被冻结，并将在 2024 年 1 月完全消失。如果你目前依赖它们，你**必须**进行迁移。

此弃用与 v1.29 版本没有直接关系。有关更多详细信息，包括这些更改可能如何影响你以及如果你受到影响该怎么做，请阅读遗留软件包仓库弃用公告。

发布说明

在我们的发布说明中查看 Kubernetes v1.29 发布的全部细节。

可用性

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

发布团队

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

我们想感谢整个发布团队，他们为我们的社区辛勤工作了数小时，以交付 Kubernetes v1.29 版本。特别感谢我们的发布负责人 Priyanka Saggu，感谢她在一个成功的发布周期中支持和指导我们，确保我们所有人都能以最好的方式做出贡献，并挑战我们改进发布流程。

项目速度

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

在 v1.29 发布周期中，该周期持续了 14 周（9 月 6 日至 12 月 13 日），我们看到了来自 888 家公司和 1422 位个人的贡献。

生态系统更新

  • KubeCon + CloudNativeCon Europe 2024 将于 2024 年 3 月 19 日至 22 日在法国巴黎举行！你可以在活动网站上找到有关会议和注册的更多信息。

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

请于 2023 年 12 月 15 日星期五太平洋时间上午 11 点（东部时间下午 2 点）加入 Kubernetes v1.29 发布团队成员，了解此版本的主要特性，以及弃用和移除的内容，以帮助规划升级。有关更多信息和注册，请访问 CNCF 在线计划网站上的活动页面。

参与其中

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