本文发布时间已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已失效。

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 的繁荣发展依赖于协作,这与曼陀罗创作中的和谐相互呼应。

版本 Logo 由 Mario Jason Braganza 制作(曼陀罗基础艺术,图片提供 - Fibrel Ojalá),象征着 Kubernetes 项目及其所有人员组成的小宇宙。

秉承曼陀罗变革性的象征意义,Kubernetes v1.29 庆祝着我们项目的演进。如同 Kubernetes 宇宙中的繁星,每位贡献者、用户和支持者都照亮了前进的道路。我们共同创造了一个充满无限可能性的宇宙——一次一个版本。

在 Kubernetes v1.29 中升级到稳定的改进

以下是 v1.29 版本发布后升级为稳定的一些精选改进。

ReadWriteOncePod 持久卷访问模式 (SIG Storage)

在 Kubernetes 中,卷访问模式是定义持久存储如何被使用的方式。这些访问模式是持久卷 (PV) 和持久卷声明 (PVC) Spec 的一部分。在使用存储时,有不同的方式来建模该存储如何被使用。例如,像网络文件共享这样的存储系统可以有许多用户同时读取和写入数据。在其他情况下,可能每个人都被允许读取数据,但不被允许写入。对于高度敏感的数据,可能只允许一个用户读取和写入数据,而其他人则不允许。

在 v1.22 之前,Kubernetes 为 PV 和 PVC 提供了三种访问模式

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

ReadWriteOnce 访问模式将卷访问限制为单个节点,这意味着同一节点上的多个 Pod 可以读取和写入同一卷。对于某些应用来说,这可能是一个主要问题,特别是如果它们需要至多一个写入者来保证数据安全。

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

CSI 驱动程序的节点卷扩展 Secret 支持 (SIG Storage)

在 Kubernetes 中,卷扩展操作可能包括在节点上扩展卷,这涉及文件系统大小调整。某些 CSI 驱动程序在节点扩展期间需要 Secret(例如访问 SAN 结构的凭证),用于以下用例

  • 当持久卷表示加密块存储时(例如使用 LUKS),可能需要提供密码才能扩展设备。
  • 对于各种验证,CSI 驱动程序在节点扩展时需要有与后端存储系统通信的凭证。

为满足此要求,Kubernetes v1.25 版本中引入了 CSI Node Expand 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 驱逐的 TaintManagerNodeLifecycleController 解耦,并将它们变成两个独立的控制器:NodeLifecycleController 负责向不健康节点添加污点,TaintManager 负责删除带有 NoExecute 效果污点的节点上的 Pod。

清理旧版 Secret-based ServiceAccount 令牌 (SIG Auth)

Kubernetes 在 1.22 版本切换到使用更安全的 ServiceAccount 令牌,这些令牌具有时间限制并绑定到特定的 Pod。在 1.24 版本停止自动生成旧版 Secret-based ServiceAccount 令牌。然后从 1.27 版本开始,对仍在使用中的剩余自动生成的 Secret-based 令牌添加上次使用日期标签。

在 v1.29 版本中,为减少潜在攻击面,LegacyServiceAccountTokenCleanUp 特性会标记长期未使用(默认为 1 年)的旧版自动生成 Secret-based 令牌为无效,并在标记为无效后长期(默认为再加 1 年)未尝试使用时自动将其删除。KEP-2799

新的 Alpha 特性

使用 matchLabelKeys 定义 Pod 亲和性或反亲和性 (SIG Scheduling)

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

kube-proxy 的 nftables 后端 (SIG Network)

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

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

管理 Service IP 地址范围的 API (SIG Network)

Service 是一种抽象的方式,用于暴露运行在一组 Pods 上的应用。Service 可以有一个集群范围的虚拟 IP 地址,该地址从 kube-apiserver 标志中定义的预定义 CIDR 分配。但是,用户可能希望添加、删除或调整已为 Service 分配的现有 IP 范围,而无需重启 kube-apiserver。

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

为 containerd/kubelet/CRI 添加支持,以按运行时类拉取镜像 (SIG Windows)

Kubernetes v1.29 添加了根据使用它们的 Pod 的 RuntimeClass 拉取容器镜像的支持。此特性在 v1.29 中默认关闭,由一个名为 RuntimeClassInImageCriApi 的特性门控控制。

容器镜像可以是 Manifest 或索引。当要拉取的镜像是索引时(镜像索引包含按平台排序的镜像 Manifest 列表),容器运行时中的平台匹配逻辑用于从索引中拉取适当的镜像 Manifest。默认情况下,平台匹配逻辑选择一个与执行镜像拉取的主机匹配的 Manifest。这对于基于 VM 的容器可能存在限制,用户可能希望拉取一个镜像,并打算将其作为基于 VM 的容器运行,例如 Windows Hyper-V 容器。

按运行时类拉取镜像特性添加了根据指定的运行时类拉取不同镜像的支持。这是通过使用 (imageID, runtimeClass) 元组而不是仅使用 imageNameimageID 来引用镜像实现的。容器运行时可以选择支持此特性。如果不支持,则保留 Kubernetes v1.29 之前 kubelet 的默认行为。

适用于 Windows Pod 的 Pod 资源原地更新 (SIG Windows)

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

Kubernetes v1.29 的升级、废弃和移除

升级到稳定

此处列出了所有升级到稳定(也称为*正式可用*)的特性。有关更新的完整列表,包括新特性以及从 Alpha 升级到 Beta 的特性,请参阅发布说明

此版本总共包含 11 项升级到稳定的增强

废弃和移除

移除树内与云提供商的集成 (SIG Cloud Provider)

Kubernetes v1.29 默认*不带*任何内置云提供商集成运行。如果您之前一直依赖树内云提供商集成(Azure、GCE 或 vSphere),则可以采取以下措施:

  • 启用等效的外部云控制器管理器集成*(推荐)*
  • 通过将相关特性门控设置为 false 来选择重新启用旧有集成;要更改的特性门控是 DisableCloudProvidersDisableKubeletCloudCredentialProviders

启用外部云控制器管理器意味着您必须在集群的控制平面中运行一个合适的云控制器管理器;这还需要为 Kubelet(在每个相关节点上)和整个控制平面(kube-apiserver 和 kube-controller-manager)设置命令行参数 --cloud-provider=external

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

如果您需要其中一个旧版树内提供商的云控制器管理器,请参阅以下链接:

更多详细信息请参阅KEP-2395

移除 v1beta2 流控制 API 组

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

如果您的 Manifest 或客户端软件使用了废弃的 Beta API 组,您应在升级到 v1.29 之前更改它们。有关详细信息和建议,请参阅废弃 API 迁移指南

Node 的 status.nodeInfo.kubeProxyVersion 字段被废弃

Node 对象的 .status.kubeProxyVersion 字段现已废弃,Kubernetes 项目建议在未来版本中移除该字段。废弃的字段不准确,并且历来由 Kubelet 管理 - 而 Kubelet 实际上不知道 kube-proxy 版本,甚至不知道 kube-proxy 是否正在运行。

如果您一直在客户端软件中使用此字段,请停止使用 - 该信息不可靠,并且该字段现已废弃。

旧版 Linux 软件包仓库

请注意,在 2023 年 8 月,旧版软件包仓库(apt.kubernetes.ioyum.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 及各种子项目进展速度相关的有趣数据点。这包括从个人贡献到贡献公司数量的所有内容,展示了投入到发展此生态系统中的努力的深度和广度。

在历时14周(9月6日至12月13日)的 v1.29 发布周期中,我们看到了来自888家公司1422位个人的贡献。

生态系统更新

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

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

加入 Kubernetes v1.29 发布团队成员,参加于2023年12月15日(星期五)太平洋时间上午11点(东部时间下午2点)举行的会议,了解此版本的主要功能、弃用和移除内容,以帮助规划升级。如需更多信息和注册,请访问 CNCF Online Programs 网站上的活动页面

参与其中

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