Kubernetes v1.30: Uwubernetes

编辑： 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 持续发展的一部分。

为了那些构建它的人，为了那些发布它的人，也为了那些让我们的所有集群保持在线的兽迷（furries），我们向您呈现 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 时始终防止未经授权地更改卷模式。作为集群管理员，如果你需要在恢复时允许这种更改，你需要向适当的身份主体（例如：代表存储集成的 ServiceAccounts）授予权限。

有关此功能的更多信息，另请参阅转换快照的卷模式。

Pod 调度就绪（SIG Scheduling）

Pod 调度就绪在本版本中毕业为稳定版，此前在 Kubernetes v1.27 中提升为 Beta 版。

这个现已稳定的功能让 Kubernetes 能够避免尝试调度一个已定义但集群尚未配置好资源以允许将该 Pod 实际绑定到节点的 Pod。这并非唯一的用例；对 Pod 是否可以被允许调度的自定义控制还允许你实现配额机制、安全控制等。

至关重要的是，将这些 Pod 标记为免于调度，可以减少调度器本会做的工作，即不断处理那些无法或不会调度到集群当前节点的 Pod。如果你激活了集群自动扩缩，使用调度门控不仅可以减少调度器的负载，还可以节省成本。没有调度门控，自动扩缩器可能会启动一个本不需要启动的节点。

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

PodTopologySpread 中的最小域（SIG Scheduling）

PodTopologySpread 约束的 minDomains 参数在本版本中毕业为稳定版，它允许你定义最小域数。此功能设计用于与集群自动扩缩器（Cluster Autoscaler）一起使用。

如果你之前尝试使用但没有足够的域存在，Pod 会被标记为不可调度。然后，集群自动扩缩器会在新的域中配置节点，你最终会得到分布在足够多域上的 Pod。

k/k 的 Go 工作空间（SIG Architecture）

Kubernetes 仓库现在使用 Go 工作空间。这应该不会对最终用户产生任何影响，但对下游项目的开发者有影响。切换到工作空间导致了各种 k8s.io/code-generator 工具的标志出现了一些破坏性变化。下游消费者应查看 staging/src/k8s.io/code-generator/kube_codegen.sh 来了解这些变化。

有关更改的完整细节以及引入 Go 工作空间的原因，请阅读在 Kubernetes 中使用 Go 工作空间。

在 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。

只要你启用了该特性门控，Kubernetes 就会为 CustomResourceDefinition 实现*验证棘轮机制*。API 服务器愿意接受更新后无效的资源更新，前提是资源中每个验证失败的部分在更新操作中都没有被更改。换句话说，任何仍然无效的资源无效部分必须是之前就已经错误的。你不能使用此机制将一个有效的资源更新为无效。

此功能允许 CRD 的作者在某些条件下自信地向 OpenAPIV3 模式添加新的验证。用户可以安全地更新到新模式，而无需提升对象的版本或破坏工作流程。

上下文日志（SIG Instrumentation）

上下文日志记录在本版本中进入 Beta 阶段，使开发人员和运维人员能够通过 WithValues 和 WithName 将可定制、可关联的上下文细节（如服务名称和事务 ID）注入到日志中。此增强功能简化了跨分布式系统日志数据的关联和分析，显著提高了故障排查的效率。通过提供对 Kubernetes 环境运行情况的更清晰洞察，上下文日志记录确保了运维挑战更易于管理，标志着 Kubernetes 可观测性的显著进步。

让 Kubernetes 了解 LoadBalancer 行为（SIG Network）

LoadBalancerIPMode 特性门控现在是 Beta 版，并且默认启用。此功能允许你为类型为 LoadBalancer 的 Service 设置 .status.loadBalancer.ingress.ipMode。.status.loadBalancer.ingress.ipMode 指定了负载均衡器 IP 的行为方式。它只能在 .status.loadBalancer.ingress.ip 字段也被指定时指定。有关指定负载均衡器状态的 IPMode 的更多详细信息。

结构化身份验证配置（SIG Auth）

结构化身份验证配置在本版本中毕业为 Beta 版。

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

结构化授权配置（SIG Auth）

结构化授权配置在本版本中毕业为 Beta 版。

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

新的 Alpha 特性

加速递归 SELinux 标签更改（SIG Storage）

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

Kubernetes v1.27 将此功能作为 Beta 毕业，但仅限于 ReadWriteOncePod 卷。相应的特性门控是 SELinuxMountReadWriteOncePod。在 v1.30 中，它仍然默认启用并保持 Beta 状态。

Kubernetes v1.30 将 SELinux 挂载选项的支持扩展到所有卷，作为 Alpha 功能，并使用一个独立的特性门控：SELinuxMount。当多个具有不同 SELinux 标签的 Pod 共享同一个卷时，此特性门控会引入行为上的改变。详情请见KEP。

我们强烈建议在启用 SELinux 的 Kubernetes 上运行的用户测试此功能，并在 KEP 问题中提供任何反馈。

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

此功能对 Windows 节点或不支持 SELinux 的 Linux 节点没有影响。

递归只读（RRO）挂载（SIG Node）

本版本中引入的递归只读（RRO）挂载（Alpha）为你的数据提供了新的安全层。此功能让你能够将卷及其子挂载设置为只读，防止意外修改。想象一下，部署一个数据完整性至关重要的关键应用——RRO 挂载确保你的数据保持不变，通过额外的保障措施加固了你的集群安全。这在严格控制的环境中尤其重要，即使是最微小的变化也可能产生重大影响。

Job 成功/完成策略（SIG Apps）

从 Kubernetes v1.30 开始，索引式 Job 支持 .spec.successPolicy 来定义何时可以根据成功的 Pod 宣布 Job 成功。这允许你定义两种类型的标准：

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

在 Job 满足成功策略后，Job 控制器会终止 lingering 的 Pod。

服务的流量分配（SIG Network）

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

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

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

更多详情请见流量分配。

存储版本迁移（SIG API Machinery）

Kubernetes v1.30 引入了一个新的内置 API，用于*StorageVersionMigration*。Kubernetes 依赖于 API 数据的持续重写，以支持一些与静态存储相关的维护活动。两个突出的例子是存储资源的带版本模式（即，给定资源的优选存储模式从 v1 变为 v2）和静态加密（即，根据数据应如何加密的变化重写过时数据）。

StorageVersionMigration 是一个 Alpha API，之前在树外可用。

更多详情请见存储版本迁移。

Kubernetes v1.30 的毕业、弃用和移除

毕业为稳定版

这里列出了所有毕业为稳定版（也称为*正式发布*）的功能。有关包括新功能和从 Alpha 到 Beta 的毕业在内的完整更新列表，请参阅发布说明。

此版本共包含 17 项提升为稳定版的增强功能：

• 基于容器资源的 Pod 自动扩缩
• 从 KCCM 的服务控制器中移除瞬时节点断言
• k/k 的 Go 工作空间
• 减少基于 Secret 的服务帐户令牌
• 用于准入控制的 CEL
• 基于 CEL 的准入 Webhook 匹配条件
• Pod 调度就绪
• PodTopologySpread 中的最小域
• 防止在卷恢复期间未经授权的卷模式转换
• API Server 跟踪
• 云双栈 --node-ip 处理
• AppArmor 支持
• kubelet 重启后稳健的 VolumeManager 重建
• kubectl delete: 添加交互式（-i）标志
• 指标基数强制执行
• 为 Pod 添加了字段 status.hostIPs
• 聚合发现

弃用和移除

移除了自 v1.27 以来已弃用的 SecurityContextDeny 准入插件

（SIG Auth、SIG Security 和 SIG Testing）随着 SecurityContextDeny 准入插件的移除，推荐使用自 v1.25 起可用的 Pod Security Admission 插件。

发布说明

在我们的发布说明中查看 Kubernetes v1.30 发布的完整详情。

可用性

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

发布团队

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

我们衷心感谢整个发布团队为向我们的社区交付 Kubernetes v1.30 版本所付出的辛勤工作。发布团队的成员范围从首次参与的影子成员到经验丰富的回归团队负责人，他们的经验是在多个发布周期中锤炼出来的。特别感谢我们的发布负责人 Kat Cosgrove，感谢她在一个成功的发布周期中对我们的支持，为我们发声，确保我们都能以最佳方式做出贡献，并挑战我们改进发布流程。

项目速度

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

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

活动更新

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

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

请于 2024 年 5 月 23 日（星期四）太平洋时间上午 9 点加入 Kubernetes v1.30 发布团队成员，了解此版本的主要功能，以及弃用和移除的内容，以帮助规划升级。更多信息和注册，请访问 CNCF 在线项目网站上的活动页面。

参与其中

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

• 在 𝕏 上关注我们 @Kubernetesio 获取最新更新
• 在 Discuss 上加入社区讨论
• 在 Slack 上加入社区
• 在 Stack Overflow 上提问（或回答问题）
• 分享你的 Kubernetes 故事
• 在博客上阅读更多关于 Kubernetes 的动态
• 了解更多关于 Kubernetes 发布团队的信息

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

• ←上一篇
• 下一篇→