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

Kubernetes v1.30：Uwubernetes

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

编辑： Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko

公布 Kubernetes v1.30 版本：Uwubernetes，最可爱的版本！

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

此版本包含 45 项增强功能。在这些增强功能中，17 项已进阶到稳定版，18 项进入 Beta 版，10 项进阶到 Alpha 版。

Kubernetes v1.30：Uwubernetes

Kubernetes v1.30 让你的集群更可爱！

Kubernetes 由来自世界各地、各行各业的数千人构建和发布。大多数贡献者并非为此获得报酬；我们构建它是为了乐趣、解决问题、学习知识，或是出于对社区纯粹的热爱。我们许多人在此找到了归属、朋友和职业生涯。发布团队很荣幸能参与 Kubernetes 的持续成长。

为了构建它的人们，为了发布它的人们，以及为了那些让我们的集群保持在线的“毛茸茸”们，我们向您呈现 Kubernetes v1.30：Uwubernetes，迄今为止最可爱的版本。这个名字是“kubernetes”和“UwU”的合成词，“UwU”是一个表示快乐或可爱的表情符号。我们在这里找到了快乐，但也带来了我们外部生活中的快乐，这有助于使这个社区变得如此奇特、精彩和受欢迎。我们非常高兴与您分享我们的工作。

UwU ♥️

Kubernetes v1.30 中进阶到稳定的改进

以下是 v1.30 版本发布后已转为稳定的一些改进的精选列表。

kubelet 重启后鲁棒的 VolumeManager 重建 (SIG Storage)

这是一次卷管理器重构，它允许 kubelet 在启动期间填充关于现有卷如何挂载的额外信息。总的来说，这使得 kubelet 重启或机器重启后的卷清理更加鲁棒。

这不会给用户或集群管理员带来任何变化。我们使用了特性流程和特性门控 NewVolumeManagerReconstruction，以便在出现问题时能够回退到之前的行为。现在该特性已稳定，特性门控已被锁定，无法禁用。

在卷恢复期间阻止未经授权的卷模式转换 (SIG Storage)

对于 Kubernetes v1.30，当将快照恢复到 PersistentVolume 时，控制平面总是阻止对卷模式进行未经授权的更改。作为集群管理员，如果你需要在恢复时允许此类更改，则需要授予权限给适当的身份主体（例如：代表存储集成的 ServiceAccount）。

有关此特性的更多信息，另请阅读转换快照的卷模式。

Pod 调度就绪性 (SIG Scheduling)

Pod 调度就绪性 在 Kubernetes v1.27 中被提升为 Beta 版后，在此版本中进阶到稳定版。

这一现在已稳定的特性允许 Kubernetes 避免尝试调度那些已定义但集群尚未配备足够资源来将其实际绑定到节点上的 Pod。这并非唯一的用例；对 Pod 是否允许调度的自定义控制还允许你实现配额机制、安全控制等。

至关重要的是，将这些 Pod 标记为免于调度可以减少调度器本会进行的重复性工作，避免其不断处理那些无法或不会调度到当前集群节点上的 Pod。如果你启用了集群自动伸缩，使用调度门控不仅能减轻调度器的负载，还能节省费用。没有调度门控，自动伸缩器可能错误地启动一个不需要启动的节点。

在 Kubernetes v1.30 中，通过指定（或移除）Pod 的 .spec.schedulingGates，你可以控制 Pod 何时准备好被考虑进行调度。这是一个稳定特性，现已正式成为 Kubernetes Pod API 定义的一部分。

PodTopologySpread 中的最小域 (SIG Scheduling)

PodTopologySpread 约束的 minDomains 参数在此版本中进阶到稳定版，它允许你定义最小域数量。此特性旨在与 Cluster Autoscaler 一起使用。

如果你之前尝试使用，并且已存在的域数量不足，Pod 将被标记为不可调度。Cluster Autoscaler 随后会在新的域中供应节点，最终你的 Pod 将分布在足够多的域中。

k/k 的 Go workspace (SIG Architecture)

Kubernetes 代码库现在使用 Go workspaces。这对最终用户没有任何影响，但会影响下游项目的开发者。切换到 workspaces 导致各种 k8s.io/code-generator 工具的标志发生了一些破坏性更改。下游使用者应查看 staging/src/k8s.io/code-generator/kube_codegen.sh 以了解这些更改。

有关更改的完整详细信息以及引入 Go workspaces 的原因，请阅读在 Kubernetes 中使用 Go workspaces。

Kubernetes v1.30 中进阶到 Beta 的改进

以下是 v1.30 版本发布后已转为 Beta 的一些改进的精选列表。

节点日志查询 (SIG Windows)

为了帮助调试节点上的问题，Kubernetes v1.27 引入了一个特性，允许获取运行在节点上的服务的日志。要使用该特性，请确保该节点的 NodeLogQuery 特性门控已启用，并且 kubelet 配置选项 enableSystemLogHandler 和 enableSystemLogQuery 都设置为 true。

在 v1.30 版本发布后，此特性现已进入 Beta 阶段（不过，你仍然需要启用该特性才能使用它）。

在 Linux 上，假定服务日志通过 journald 可用。在 Windows 上，假定服务日志在应用日志提供程序中可用。日志也可通过读取 /var/log/ (Linux) 或 C:\var\log\ (Windows) 目录下的文件来获取。有关更多信息，请参阅日志查询文档。

CRD 校验棘轮 (SIG API Machinery)

你需要启用 CRDValidationRatcheting 特性门控才能使用此行为，启用后此行为将应用于集群中的所有 CustomResourceDefinition。

只要您启用了 feature gate，Kubernetes 就会为 CustomResourceDefinitions 实现验证棘轮 (validation ratcheting)。API 服务器愿意接受对更新后无效资源的更新，前提是资源中每个验证失败的部分没有被更新操作修改。换句话说，资源中任何仍然无效的部分必须在更新前就已经错误了。您不能使用此机制将一个有效的资源更新为无效。

此特性允许 CRD 的作者在某些条件下自信地向 OpenAPIV3 schema 添加新的验证。用户可以安全地更新到新的 schema，而无需升级对象的版本或中断工作流程。

上下文日志 (Contextual logging) (SIG Instrumentation)

上下文日志 (Contextual Logging) 在此版本中升级到 Beta，使开发人员和运维人员能够通过 WithValues 和 WithName 将可定制、可关联的上下文详细信息（如服务名称和事务 ID）注入到日志中。此增强功能简化了分布式系统中日志数据的关联和分析，显著提高了故障排除的效率。通过更清晰地了解 Kubernetes 环境的运行情况，上下文日志确保运维挑战更易于管理，标志着 Kubernetes 可观测性向前迈出了重要一步。

使 Kubernetes 了解 LoadBalancer 的行为 (SIG Network)

LoadBalancerIPMode feature gate 现在已进入 Beta 阶段，并默认启用。此特性允许您为 type 设置为 LoadBalancer 的 Service 设置 .status.loadBalancer.ingress.ipMode。.status.loadBalancer.ingress.ipMode 指定了负载均衡器 IP 的行为方式。它只能在指定了 .status.loadBalancer.ingress.ip 字段时指定。有关指定负载均衡器状态的 IPMode 的更多详细信息。

结构化认证配置 (Structured Authentication Configuration) (SIG Auth)

结构化认证配置 (Structured Authentication Configuration) 在此版本中升级到 Beta。

Kubernetes 长期以来一直需要一个更灵活、更可扩展的认证系统。目前的系统虽然强大，但在某些场景下存在一些限制，使其难以使用。例如，无法使用多个相同类型的认证器（例如，多个 JWT 认证器），或者无法在不重启 API Server 的情况下更改配置。结构化认证配置特性是解决这些限制并提供一种更灵活、更可扩展的方式来配置 Kubernetes 认证的第一步。有关结构化认证配置的更多详细信息。

结构化授权配置 (Structured Authorization Configuration) (SIG Auth)

结构化授权配置 (Structured Authorization Configuration) 在此版本中升级到 Beta。

Kubernetes 不断发展，以满足系统管理员和开发人员的复杂需求。Kubernetes 确保集群安全性和完整性的一个关键方面是 API Server 授权。直到最近，kube-apiserver 中授权链的配置相对僵化，仅限于一组命令行标志，并且授权链中只允许一个 webhook。这种方法虽然功能可用，但限制了集群管理员定义复杂、细粒度授权策略所需的灵活性。最新的结构化授权配置特性旨在通过引入一种更结构化、更通用的方式来配置授权链，重点支持多个 webhook 并提供显式控制机制，从而彻底改变这一方面。有关结构化授权配置的更多详细信息。

新的 Alpha 特性

加速递归 SELinux 标签更改 (SIG Storage)

从 v1.27 版本开始，Kubernetes 已经包含了一项优化，可以在固定时间内为卷内容设置 SELinux 标签。Kubernetes 使用挂载选项实现了这一加速。较慢的传统行为要求容器运行时递归遍历整个卷，并单独为每个文件和目录应用 SELinux 标签；对于文件和目录数量庞大的卷来说，这一点尤其明显。

Kubernetes v1.27 将此特性升级到 Beta，但将其限制为 ReadWriteOncePod 卷。相应的 feature gate 是 SELinuxMountReadWriteOncePod。它在 v1.30 中仍然默认启用并保持 Beta 状态。

Kubernetes v1.30 将 SELinux 挂载选项的支持扩展到所有卷，作为 Alpha 特性，并引入了一个独立的 feature gate：SELinuxMount。当多个具有不同 SELinux 标签的 Pod 共享同一个卷时，此 feature gate 会引入行为变化。详情请参阅 KEP。

我们强烈鼓励在启用了 SELinux 的环境运行 Kubernetes 的用户测试此特性，并在 KEP issue 上提供反馈。

Feature gate在 v1.30 中的阶段行为变化
SELinuxMountReadWriteOncePodBeta否
SELinuxMountAlpha是

必须同时启用 SELinuxMountReadWriteOncePod 和 SELinuxMount 这两个 feature gate 才能在所有卷上测试此特性。

此特性对 Windows 节点或未启用 SELinux 支持的 Linux 节点无效。

递归只读 (RRO) 挂载 (SIG Node)

在此版本中以 Alpha 特性引入递归只读 (RRO) 挂载，您将发现数据有了新的安全层。此特性允许您将卷及其子挂载点设置为只读，从而防止意外修改。想象一下部署一个数据完整性至关重要的关键应用程序——RRO 挂载确保您的数据不受触动，为集群安全性提供了额外的保障。这在严格受控的环境中尤其重要，即使是微小的变化也可能产生重大影响。

Job 成功/完成策略 (SIG Apps)

从 Kubernetes v1.30 开始，索引 Job 支持 .spec.successPolicy 来定义基于成功 Pods 何时可以将 Job 声明为成功。这允许您定义两种类型的标准：

  • succeededIndexes 表示当这些索引成功时，可以将 Job 声明为成功，即使其他索引失败。
  • succeededCount 表示当成功索引的数量达到此标准时，可以将 Job 声明为成功。

Job 满足成功策略后，Job 控制器将终止剩余的 Pods。

服务的流量分发 (SIG Network)

Kubernetes v1.30 在 Kubernetes Service 中引入了 spec.trafficDistribution 字段，作为 Alpha 特性。这允许您表达流量应如何路由到 Service 端点的偏好。虽然流量策略侧重于严格的语义保证，但流量分发允许您表达偏好（例如路由到拓扑上更近的端点）。这有助于优化性能、成本或可靠性。您可以通过为集群及其所有节点启用 ServiceTrafficDistribution feature gate 来使用此字段。在 Kubernetes v1.30 中，支持以下字段值：

PreferClose：表示优先将流量路由到拓扑上与客户端接近的端点。“拓扑上接近”的解释可能因实现而异，可能包括同一节点、机架、可用区甚至区域内的端点。设置此值允许实现做出不同的权衡，例如优先考虑接近性而非负载的均匀分布。如果此类权衡不可接受，则不应设置此值。

如果未设置该字段，实现（例如 kube-proxy）将应用其默认路由策略。

有关流量分发 (Traffic Distribution) 的更多详细信息。

存储版本迁移 (Storage Version Migration) (SIG API Machinery)

Kubernetes v1.30 引入了一个新的内置 API，用于进行存储版本迁移 (StorageVersionMigration)。Kubernetes 依赖于主动重写 API 数据来支持与静态存储相关的某些维护活动。两个突出的例子是存储资源的带版本 schema（即给定资源的优选存储 schema 从 v1 更改为 v2）和静态加密（即根据数据应如何加密的变化重写旧数据）。

StorageVersionMigration 是一个 Alpha API，之前作为树外 (out of tree) 项目提供。

有关存储版本迁移 (storage version migration) 的更多详细信息。

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

升级到 Stable

此处列出了所有升级到 Stable（也称为通用可用 (general availability)）的特性。有关包括新特性以及从 Alpha 升级到 Beta 的完整更新列表，请参阅发行说明 (release notes)。

此版本共有 17 项增强功能升级到 Stable

废弃和移除

移除自 v1.27 起废弃的 SecurityContextDeny 准入插件。

(SIG Auth, SIG Security 和 SIG Testing) 随着 SecurityContextDeny 准入插件的移除，建议改用自 v1.25 起可用的 Pod Security Admission 插件。

发行说明

请在我们的发行说明 (release notes) 中查看 Kubernetes v1.30 版本的完整详细信息。

可用性

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

发布团队

Kubernetes 的实现离不开其社区的支持、奉献和辛勤工作。每个发布团队都由敬业的社区志愿者组成，他们共同构建您所依赖的 Kubernetes 版本中的众多组成部分。这需要我们社区各领域人员的专业技能，从代码本身到文档和项目管理。

我们谨感谢整个发布团队 (release team) 为向社区交付 Kubernetes v1.30 版本所付出的辛勤工作和时间。发布团队成员的范围从首次参与的影子成员 (shadows) 到拥有多个发布周期经验的回归团队负责人。特别感谢我们的发布负责人 Kat Cosgrove，感谢她支持我们度过一个成功的发布周期，为我们发声，确保我们都能以最好的方式做出贡献，并激励我们改进发布流程。

项目速度

CNCF K8s DevStats 项目汇集了与 Kubernetes 和各种子项目速度相关的许多有趣的数据点。这包括从个人贡献到参与贡献的公司数量的一切信息，是对这个生态系统发展所投入的深度和广度努力的说明。

在持续 14 周的 v1.30 发布周期（1 月 8 日至 4 月 17 日）中，我们看到了来自 863 家公司和 1391 位个人的贡献。

活动更新

  • KubeCon + CloudNativeCon China 2024 将于 2024 年 8 月 21 日至 23 日在中国香港举行！您可以在活动网站上找到有关会议和注册的更多信息。
  • KubeCon + CloudNativeCon North America 2024 将于 2024 年 11 月 12 日至 15 日在美国犹他州盐湖城举行！您可以在活动网站上找到有关会议和注册的更多信息。

即将到来的发布网络研讨会

太平洋时间 (PT) 2024 年 5 月 23 日星期四上午 9 点，与 Kubernetes v1.30 发布团队成员一起了解此版本的主要特性以及废弃和移除的内容，以帮助规划升级。有关更多信息和注册，请访问 CNCF 在线项目网站上的活动页面。

参与其中

参与 Kubernetes 的最简单方法是加入与您兴趣一致的众多特别兴趣小组 (SIG) 之一。有什么想向 Kubernetes 社区宣布的吗？在我们每周的社区会议上以及通过以下渠道表达您的声音。感谢您的持续反馈和支持。

此博客于 2024 年 4 月 19 日更新，以突出显示最初未包含在发布博客中的另外两项更改。