我们很高兴地宣布发布 Kubernetes v1.30: Uwubernetes，这是迄今为止最可爱的版本！
与之前的版本一样，Kubernetes v1.30 的发布引入了新的稳定（Stable）功能、测试（Beta）功能和预览（Alpha）功能。通过持续发布高质量版本，我们展示了我们强大的开发周期能力以及来自社区的热情支持。
这个版本包含了 45 个增强功能，其中有 17 个已升级为稳定版，18 个进入了测试版，还有 10 个被提升至预览版。
发布主题和标志
1.Kubernetes v1.30: Uwubernetes
Kubernetes v1.30 让你的集群更可爱！
Kubernetes 是由来自世界各地、各行各业的数千人共同构建和发布的。大多数贡献者并没有为此获得报酬；我们的构建动力源于乐趣、问题解决、学习以及对社区的热爱。我们中的许多人在这里找到了家、朋友和事业。发布团队很荣幸能够参与 Kubernetes 持续发展的过程。
对于那些为它做出贡献的人，对于那些发布它的人，以及对于那些保持我们所有集群在线的人，我们呈现 Kubernetes v1.30: Uwubernetes，这是迄今为止最可爱的版本。这个名称是“kubernetes”和“UwU”（一种表示幸福或可爱的表情符号）的结合。我们在这里找到了快乐，并将外部生活的快乐带到这里，使这个社区变得如此独特、美妙和充满激情。我们非常高兴能与你分享我们的工作。
2.在 Kubernetes v1.30 中升级为稳定版的改进功能
以下是在 v1.30 版本发布后现在已稳定的一些改进功能的选择。
3.kubelet 重启后稳健的 VolumeManager 重建（SIG Storage）
这是卷管理器的重构，允许 kubelet 在启动过程中填充关于现有卷如何挂载的额外信息。总体而言，这使得在 kubelet 重新启动或机器重启后的卷清理更加稳健。
对于用户或集群管理员而言，并没有任何变化。我们使用功能流程和功能开关 NewVolumeManagerReconstruction，以便在出现问题时能够回退到之前的行为。现在该功能已经稳定，功能开关已被锁定，无法禁用。
4.防止在卷还原过程中未经授权的卷模式转换（SIG Storage）
在 Kubernetes 1.30，控制平面始终会在将快照还原为持久卷时阻止未经授权的卷模式更改。作为集群管理员，如果你需要在还原时允许该类更改，你将需要授予适当身份主体（例如：代表存储集成的服务账号）的权限。
警告：在升级之前，请采取必要的操作。在 external-provisioner v4.0.0 和 external-snapshotter v7.0.0 中，默认启用了 prevent-volume-mode-conversion 功能标志。如果通过 VolumeSnapshot 创建 PVC 时进行卷模式更改，将被拒绝。除非按照 ?external-provisioner 4.0.0 和 ?external-snapshotter v7.0.0 中的“紧急升级注意事项”部分中的步骤进行操作。
有关此功能的更多信息，请阅读有关?转换快照卷模式的说明。
5.Pod 调度可用性（SIG Scheduling）
Pod 调度可用性在 Kubernetes v1.27 中升级为测试版，并在此版本中成为稳定版。
这个现在稳定的功能使得 Kubernetes 可以避免在集群尚未准备好将 Pod 绑定到节点的资源时尝试调度已定义的 Pod。这不仅仅是一个用例；你还可以使用自定义控制来实现配额机制、安全控制等，以决定是否允许调度 Pod。
将这些 Pod 标记为免于调度可以减少调度器的工作量，避免其在当前集群节点上无法调度的 Pod 上进行调度。如果你的集群启用了?自动缩放，使用调度门不仅可以减轻调度器的负担，还可以节省成本。没有调度门，自动缩放器可能会启动不需要启动的节点。
在 Kubernetes v1.30 中，通过指定（或删除）Pod 的.spec.schedulingGates，你可以控制何时可以考虑将 Pod 调度。这个稳定的功能现已正式成为 Kubernetes API 的一部分。
6.PodTopologySpread 中的最小域数（SIG Scheduling）
PodTopologySpread 的 minDomains 参数在此版本中升级为稳定版，允许你定义最小的域数。此功能设计用于与集群自动缩放器一起使用。
如果你之前尝试使用该功能，但没有足够的域存在，那么 Pod 将被标记为无法调度。然后，集群自动缩放器将在新的域中提供节点，并最终使 Pod 在足够的域中进行分布。
7.k/k 中的 Go 工作区（SIG Architecture)）
Kubernetes 仓库现在采用了 Go 工作区。对最终用户而言，这不会产生任何影响，但对于下游项目的开发人员来说有一定影响。切换到工作区会导致一些 ?k8s.io/code-generator 工具的标志发生变化。下游使用者可以查看 ?staging/src/k8s.io/code-generator/kube_codegen.sh 文件以了解这些变化。
8.Kubernetes v1.30 中升级到测试版的改进
这些是在 v1.30 发布后成为测试版的一些改进功能的选择。
9.节点日志查询（Windows SIG Scheduling）
为了帮助调试节点上的问题，Kubernetes v1.27 引入了一个功能，允许获取运行在节点上的服务的日志。要使用此功能，请确保已启用节点上的 NodeLogQuery 功能门，并将 kubelet 配置选项 enableSystemLogHandler 和 enableSystemLogQuery 都设置为 true。
在 1.30 版本之后，现在是测试版(不过，您仍然需要启用该特性才能使用它)。
在 Linux 上，假设是可以通过 journald 获取服务日志。在 Windows 上，假设是可以在应用程序日志提供程序中获取服务日志。你还可以通过读取 /var/log/（Linux）或 C:\var\log\（Windows）中的文件来获取日志。有关更多信息，请参阅?日志查询文档。
10.CRD 验证棘轮（SIG API Machinery）
为了使用此功能，你需要启用 CRDValidationRatcheting 功能门，然后该行为将应用于集群中的所有 CustomResourceDefinitions。
一旦启用了功能门，Kubernetes 将对 CustomResourceDefinitions 实施验证棘轮。API 服务器将接受对已更新但不再有效的资源的更新，前提是更新操作未更改未通过验证的资源的任何部分。换句话说，任何仍然无效的资源的无效部分必须已经是错误的。你不能使用此机制将有效的资源更新为无效的资源。
此功能允许 CRD 的作者在特定条件下自信地向 OpenAPIV3 模式添加新的验证。用户可以安全地更新到新的模式，而无需增加对象的版本或破坏工作流程。
11.上下文日志记录（SIG Instrumentation）
在这个版本中，上下文日志记录升级为测试版，为开发人员和运维人员提供了将可定制、可关联的上下文详细信息（如服务名称和事务 ID）注入日志的能力，通过 WithValues 和 WithName 方法实现。这一改进简化了跨分布式系统的日志数据关联和分析，显著提高了故障排除的效率。通过更清晰地了解你的 Kubernetes 环境的工作原理，上下文日志记录确保操作挑战更易管理，标志着 Kubernetes 可观察性的重要进展。
12.使 Kubernetes 了解负载均衡行为（SIG Network）
LoadBalancerIPMode 功能标志现已升级为测试版，并且默认启用。这个功能允许你为类型为 LoadBalancer 的服务设置 .status.loadBalancer.ingress.ipMode 属性，以指定负载均衡器 IP 的行为方式。只有在同时指定了 .status.loadBalancer.ingress.ip 字段时，才能指定 .ipMode。有关指定负载均衡器状态的 IPMode 的更多详细信息，请参?阅相关文档。
新的 alpha 功能
加速递归 SELinux 标签更改（SIG Storage） 从 v1.27 版本开始，Kubernetes 已经包含了一个优化功能，可以在卷的内容上设置 SELinux 标签，只需恒定的时间。Kubernetes 通过一个挂载选项实现了这个加速。较慢的旧行为要求容器运行时递归遍历整个卷，并为每个文件和目录单独应用 SELinux 标签；这在具有大量文件和目录的卷中尤为明显。
Kubernetes 1.27 将这个功能升级为测试版，但仅限于 ReadWriteOncePod 卷。相应的功能门是 SELinuxMountReadWriteOncePod。它仍然默认启用，并将在 1.30 中保持测试版。
Kubernetes 1.30 将扩展对 SELinux 挂载选项的支持到所有卷，并将其设为 alpha 版本，使用单独的功能门 SELinuxMount。当具有不同 SELinux 标签的多个 Pod 共享同一个卷时，此功能门引入了行为上的变化。详细信息请参阅 ?KEP。
要在所有卷上测试此功能，必须同时启用 SELinuxMountReadWriteOncePod 和 SELinuxMount 两个功能门。
此功能对于 Windows 节点或没有 SELinux 支持的 Linux 节点没有影响。
1.递归只读（RRO）挂载（SIG Node）
在此版本中，引入了递归只读（RRO）挂载的 alpha 版本，为你的数据提供了一个新的安全层。此功能允许你将卷及其子挂载设置为只读，以防止意外修改。想象一下部署关键应用程序的情况，其中数据完整性至关重要——RRO Mounts 可以确保你的数据保持不变，通过额外的保护措施加强了集群的安全性。在严格受控的环境中，即使是微小的更改也可能产生重大影响，因此这一点尤为重要。
2.作业成功/完成策略（SIG Apps）
从 Kubernetes v1.30 开始，索引作业支持 .spec.successPolicy 属性，以根据成功的 Pod 来定义何时声明作业成功。这允许你定义两种类型的标准：
- succeededIndexes 指示当这些索引成功时，作业可以被声明为成功，即使其他索引失败。
- succeededCount 指示当成功索引的数量达到此标准时，作业可以被声明为成功。在作业满足成功策略后，作业控制器会终止悬挂的 Pods。
3.服务流量分配（SIG Network）
Kubernetes v1.30 引入了服务的流量分配功能（spec.trafficDistribution），目前处于 alpha 版本。这个新功能允许你定义流量路由到服务端点的偏好。虽然?流量策略主要关注语义保证，但流量分配允许你表达偏好，例如将流量路由到更接近客户端拓扑的端点。这有助于优化性能、成本或可靠性。要使用此功能，请启用集群和所有节点上的 ServiceTrafficDistribution 功能门。在 Kubernetes v1.30 中，支持以下字段值：
PreferClose：表示偏好将流量路由到与客户端拓扑更接近的端点。"拓扑更接近"的具体定义可能因实现而异，可能包括同一节点、机架、区域甚至地理位置内的端点。设置此值即赋予实现在不同权衡之间进行选择的权力，例如优化接近性而不是均匀分布负载。如果不接受这种权衡，请不要设置此值。
如果未设置该字段，实现（如 kube-proxy）将应用其默认的路由策略。
Kubernetes v1.30 的升级、弃用和移除
升级至稳定版 以下是升级至稳定版（也称为正式发布版）的所有功能列表。有关包括新功能和从 alpha 到 beta 的升级的完整更新列表，请查阅发布说明。
此版本包含了共 17 个功能的升级至稳定版：
- 基于容器资源的 Pod 自动伸缩：https://kep.k8s.io/1610
- 删除云控制器管理器（KCCM）中的临时节点谓词：https://kep.k8s.io/3458
- k/k 采用 Go 的 workspace 架构：https://kep.k8s.io/4402
- 减少基于 Secret 的 ServiceAccount 令牌：https://kep.k8s.io/2799
- 用于准入控制的 CEL：https://kep.k8s.io/3488
- 基于 CEL 的准入控制的匹配条件：https://kep.k8s.io/3716
- Pod 调度准备就绪：https://kep.k8s.io/3521
- PodTopologySpread 中的最小域：https://kep.k8s.io/3022
- 阻止在卷恢复期间发生未授权的卷模式转换：https://kep.k8s.io/3141
- API Server 链路追踪：https://kep.k8s.io/647
- 云上双栈 - -- node - ip 的处理：https://kep.k8s.io/3705
- AppArmor 支持：https://kep.k8s.io/24
- kubelet 重启后稳定重建 VolumeManager：https://kep.k8s.io/3756
- kubectl 交互式删除：https://kep.k8s.io/3895
- 指标基准配置：https://kep.k8s.io/2305
- 为 Pod 添加 status.hostIPs 字段：https://kep.k8s.io/2681
- 聚合资源 API 发现：https://kep.k8s.io/3352
弃用和移除：
- 自 v1.27 版本起，已移除对 SecurityContextDeny 准入插件的支持，并标记为弃用。（SIG Auth、SIG Security 和 SIG Testing）
- 随着 SecurityContextDeny 准入插件的移除，建议使用自 v1.25 版本起可用的 Pod Security Admission 插件。
发布说明
请查看我们的?发布说明，了解 Kubernetes 1.30 版本的完整详情。
可用性
Kubernetes 1.30 可在?GitHub上下载。要开始使用 Kubernetes，请参考交?互式教程或使用?minikube在本地运行 Kubernetes 集群。你还可以使用?kubeadm轻松安装 1.30 版本。
发布团队
Kubernetes 的存在离不开社区的支持、承诺和辛勤工作。每个发布团队都由专注的社区志愿者组成，他们共同努力构建你所依赖的 Kubernetes 版本的众多部分。这需要来自社区各个角落的人们的专业技能，从代码本身到文档和项目管理。
我们要感谢整个发布团队为将 Kubernetes v1.30 版本交付给我们的社区所做的辛勤工作。发布团队的成员由经历过多个发布周期的首次参与者到经验丰富的团队负责人组成。我们特别要感谢我们的发布负责人 Kat Cosgrove，他在成功的发布周期中给予我们支持、代表我们发声，并确保我们以最佳方式做出贡献，并推动我们改进发布流程。
项目速度
CNCF K8s DevStats 项目总结了与 Kubernetes 及其子项目的开发速度有关的许多有趣数据。这包括个人贡献和参与贡献的公司数量等信息，展示了推进这个生态系统所付出的努力的广泛和深度。
在为期 14 周的 v1.30 发布周期（2024 年 1 月 8 日至 4 月 17 日）中，我们收到了来自?863 家公司和?1391 位个人的贡献。
参考文章
- Kubernetes 增强特性：https://kep.k8s.io/
- Kubernetes 1.30 发布团队：https://github.com/kubernetes/sig-release/blob/master/releases/release-1.30
- Kubernetes 1.30 变更日志：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md
- Kubernetes 1.30 主题讨论：kubernetes/sig-release#2424
