Kubernetes v1.27 发布

作者：Kubernetes v1.27 发布团队^[1]

宣布发布 Kubernetes v1.27，这是 2023 年的第一个版本！

此版本包含 60 个增强功能。其中 18 个增强功能进入 Alpha 阶段，29 个进入 Beta 阶段，13 个进入 Stable 阶段。

版本主题和标志

Kubernetes v1.27：Chill Vibes

Kubernetes v1.27 的主题是 Chill Vibes。

这有点儿傻，但在这个版本中，有一些重要的变化激发了这个主题。在 Kubernetes 版本发布周期中，有几个截止日期需要满足才能保留功能。如果某个功能错过了任何一个截止日期，它可以通过例外流程进行。处理这些例外是版本发布的一个非常正常的部分。但是 v1.27 是第一个版本，任何人都记不起来在增强功能冻结之后我们没有收到任何例外请求。即使在版本发布过程中，事情比我们以往习惯的要平静得多。

我们能够享受到这样一个更加平静的版本发布，有一个特定的原因，那就是人们在幕后投入了大量工作来改善我们如何管理版本发布。这就是这个主题庆祝的内容，人们为社区做出了改进。

特别感谢 Britnee Laverack^[2] 设计了这个标志。Britnee 还设计了 Kubernetes 1.24: Stargazer^[3] 的标志。

新特性（主要主题）

冻结 k8s.gcr.io 镜像仓库

用 GA 了数月的 registry.k8s.io 替换旧的镜像仓库 k8s.gcr.io。Kubernetes 项目创建并运行 registry.k8s.io 镜像仓库，完全由社区控制。这意味着旧的镜像仓库 k8s.gcr.io 将被冻结，将不再发布 Kubernetes 和相关子项目的更多镜像。

这个改变对贡献者意味着什么？

• 如果你是子项目的维护者，你需要更新你的清单和 Helm chart 以使用新的镜像仓库。欲了解更多信息，请查看此项目^[4]。

这个改变对最终用户意味着什么？

• Kubernetes v1.27 发布将不会发布到 k8s.gcr.io 镜像仓库。
• v1.24、v1.25 和 v1.26 的补丁版本将在四月后不再发布到旧的镜像仓库。
• 从 v1.25 开始，将默认镜像仓库设置为 registry.k8s.io。这个值可以在 kubeadm 和 kubelet 中进行重写，但如果将其设置为 k8s.gcr.io，由于新版本不会出现在旧的镜像仓库中，新版本将无法使用旧的镜像仓库。
• 如果你想提高集群的可靠性，并消除对社区拥有的镜像仓库的依赖，或者在限制外部流量的网络中运行 Kubernetes，你应该考虑托管本地镜像仓库镜像。一些云供应商可能会为此提供托管解决方案。

SeccompDefault 升级为稳定版

要使用 seccomp profile defaulting，你必须为要使用它的每个节点启用 –seccomp-default 命令行标志^[5]运行 kubelet。如果启用，kubelet 将默认使用 RuntimeDefault seccomp profile，它由容器运行时定义，而不是使用 Unconfined 模式（seccomp disabled）。默认配置旨在提供一组强大的安全默认值，同时保留工作负载的功能。容器运行时和它们的发布版本之间的默认配置可能不同。

你可以在相关的 Kubernetes Enhancement Proposal (KEP) 中找到有关升级和降级策略的详细信息：Enable seccomp by default^[6]。

可变作业调度指令（Mutable scheduling directives for Jobs）升级为 GA

这个特性在 v1.22 中引入，开始是一个 beta 级别，现在已经稳定了。在大多数情况下，一个并行作业将希望以约束条件运行 pod，比如所有 pod 都在同一个区域，或者只在 GPU 模型 x 或 y 上运行，而不是混合使用。suspend 字段是实现这些语义的第一步。suspend 允许自定义队列控制器决定何时启动作业。但是，一旦作业被取消暂停，自定义队列控制器就无法影响作业的 pod 实际着陆位置。

此功能允许在作业启动前更新作业的调度指令，这使得自定义队列控制器能够影响 pod 的放置位置，同时将实际的 pod-to-node 分配卸载到 kube-scheduler 上。这仅允许在从未取消暂停的挂起作业中更新。可以更新的作业的 pod 模板中的字段是节点亲和性、节点选择器、容忍性、标签、注释和调度门^[7]。在 KEP: Allow updating scheduling directives of jobs^[8] 中找到更多详细信息。

DownwardAPIHugePages 升级为稳定版

在 Kubernetes v1.20 中，downward API^[9] 添加了对 requests.hugepages-和 limits.hugepages-的支持，以保持与其他资源（如 CPU、内存和临时存储）的一致性。此功能在此版本中升级为稳定版本。在 KEP: Downward API HugePages^[10] 中可以找到更多详细信息。

Pod 调度可用性进入 beta 阶段

在创建时，Pod 已准备好进行调度。Kubernetes 调度程序会尽力找到节点以放置所有待定的 Pod。然而，在实际情况中，一些 Pod 可能会长时间处于缺少必要资源（missing-essential-resources）的状态。这些 Pod 实际上会以不必要的方式使调度程序（以及下游集成器，如 Cluster Autoscaler）繁忙。

通过指定/移除 Pod 的 .spec.schedulingGates，可以控制何时将 Pod 视为可调度。

schedulingGates 字段包含一个字符串列表，每个字符串字面量被视为在将 Pod 视为可调度之前必须满足的条件。这个字段只能在创建 Pod 时初始化（由客户端创建或在准入期间改变）。创建后，可以以任意顺序移除每个 schedulingGate，但不允许添加新的 scheduling gate。

通过 Kubernetes API 访问节点日志

此功能可以帮助集群管理员通过允许查询服务日志来调试运行在节点上的服务的问题。要使用此功能，请确保在该节点上启用了 NodeLogQuery 特性门^[11]，而且 kubelet 配置选项 enableSystemLogHandler 和 enableSystemLogQuery 都设置为 true。在 Linux 上，我们假设服务日志可通过 journald 获取。在 Windows 上，我们假设服务日志可在应用程序日志提供程序中获取。在 Linux 和 Windows 上，你还可以分别从 /var/log/ 和 C：\var\log 目录获取日志。

集群管理员可以在整个集群或其子集上尝试此 alpha 版本特性。

ReadWriteOncePod 持久卷访问模式进入 beta 阶段

Kubernetes v1.22 引入了一种名为 ReadWriteOncePod 的持久卷^[12]（PV）和持久卷声明^[13]（PVC）的新访问模式。此访问模式使你可以将卷访问限制为群集中的单个 Pod，确保只有一个 Pod 可以同时向卷写入。这对于需要单写者访问存储的有状态工作负载特别有用。

ReadWriteOncePod beta 版本增加了对使用 ReadWriteOncePod PVC 的 Pod 进行调度程序抢占^[14]的支持。调度程序抢占允许高优先级的 Pod 抢占低优先级的 Pod。例如，当调度一个使用 ReadWriteOncePod PVC 的 Pod A 时，如果发现另一个使用相同 PVC 的 Pod B 并且 Pod A 的优先级更高，则调度程序将返回一个 Unschedulable 状态，并尝试抢占 Pod B。有关更多背景，请参见 KEP: ReadWriteOncePod PersistentVolume AccessMode^[15]。

在滚动升级后遵守 PodTopologySpread

matchLabelKeys 是用于选择用于计算扩展的 Pod 的一组 Pod 标签键列表。这些键用于从 Pod 标签中查找值。这些键值标签与 labelSelector 进行 AND 运算，以选择用于计算传入 Pod 的扩展的现有 Pod 组。在 Pod 标签中不存在的键将被忽略。空列表表示只针对 labelSelector 进行匹配。

使用 matchLabelKeys，用户不需要在不同的修订版本之间更新 pod.spec。控制器/操作器只需为不同的修订版本设置相同标签键的不同值。调度程序将根据 matchLabelKeys 自动假定这些值。例如，如果用户使用 Deployment，则可以使用 pod-template-hash 键控制，它由 Deployment 控制器自动添加，以区分单个 Deployment 中的不同修订版本。

使用挂载加速 SELinux 卷标记

在此版本中，如何将 SELinux 标签应用于 Pod 使用的卷升级为 beta 版本。此功能通过使用正确的 SELinux 标签挂载卷而不是递归更改每个卷上的文件来加速容器启动。带有 SELinux 支持的 Linux 内核允许卷的第一次挂载使用 -o context= 挂载选项设置整个卷上的 SELinux 标签。这样，所有文件将在固定时间内分配给给定标签，而无需递归遍历整个卷。

context 挂载选项无法应用于 bind 挂载或已挂载卷的重新挂载。对于 CSI 存储，CSI 驱动程序执行卷的第一次挂载，因此必须是 CSI 驱动程序实际应用此挂载选项。我们在 CSIDriver 对象中添加了一个新字段 SELinuxMount，以便驱动程序可以宣布它们是否支持 -o context 挂载选项。

如果 Kubernetes 知道 Pod 的 SELinux 标签以及负责 Pod 卷的 CSI 驱动程序宣布 SELinuxMount：true，并且该卷具有 Access Mode ReadWriteOncePod，则它将要求 CSI 驱动程序使用 mount 选项 context= 挂载卷，并告诉容器运行时不要重新标记卷的内容（因为所有文件已经具有正确的标签）。从 KEP: Speed up SELinux volume relabeling using mounts^[16] 中获取更多信息。

稳健的 VolumeManager 重构进入 beta 阶段

这是卷管理器重构，它允许 kubelet 在 kubelet 启动期间填充有关现有卷如何挂载的其他信息。一般来说，这使卷清理更加健壮。如果在节点上启用了 NewVolumeManagerReconstruction 特性门，则在 kubelet 启动期间将获得有关已挂载卷的增强发现。

在 Kubernetes v1.25 之前，kubelet 在 kubelet 启动期间使用不同的默认行为来发现已挂载的卷。如果禁用此特性门（默认情况下启用），则选择传统的发现行为。

在 Kubernetes v1.25 和 v1.26 中，此行为切换是 SELinuxMountReadWriteOncePod 特性门的一部分。

可变 Pod 调度指令进入 beta 阶段

这允许在调度准备就绪门被阻止的 Pod 上使用更受限制的节点亲和性/选择器进行改变。它使得在允许调度之前改变 Pod 的调度指令成为可能，并使外部资源控制器能够影响 Pod 的放置，同时将实际的 Pod 到节点分配卸载给 kube-scheduler。

这为在 Kubernetes 中添加调度功能打开了一扇新的大门。具体来说，构建轻量级调度程序来实现 kube-scheduler 不支持的功能，同时依赖于现有的 kube-scheduler 来支持所有上游功能并处理 Pod 到节点的绑定。如果自定义功能不需要实现调度程序插件——这需要重新构建和维护自定义 kube-scheduler 二进制文件——则应首选此模式，

Kubernetes v1.27 中的特性升级和弃用

升级为稳定版

此版本包括共计 9 个增强功能升级为稳定版：

• kubectl 使用的默认容器注释^[17]
• CronJob 中的时区支持^[18]
• 暴露有关资源请求和限制的指标，表示 Pod 模型^[19]
• 服务器端未知字段验证^[20]
• 节点拓扑管理器^[21]
• 向 Pod.Spec.Container.{Liveness,Readiness,Startup} 探针添加 gRPC 探测^[22]
• 向探针添加可配置的优雅期^[23]
• OpenAPI v3^[24]
• 使用支持的 Go 版本^[25]

弃用和移除

此版本有多项移除：

• 从 CSIStorageCapacity 中移除 storage.k8s.io/v1beta1^[26]
• 移除对弃用的 seccomp 注释的支持^[27]
• 移除 –master-service-namespace 命令行参数^[28]
• 移除 ControllerManagerLeaderMigration 特性门^[29]
• 移除 –enable-taint-manager 命令行参数^[30]
• 移除 –pod-eviction-timeout 命令行参数^[31]
• 移除 CSI 迁移特性门^[32]
• 移除 CSIInlineVolume 特性门^[33]
• 移除 EphemeralContainers 特性门^[34]
• 移除 LocalStorageCapacityIsolation 特性门^[35]
• 移除 NetworkPolicyEndPort 特性门^[36]
• 移除 StatefulSetMinReadySeconds 特性门^[37]
• 移除 IdentifyPodOS 特性门^[38]
• 移除 DaemonSetUpdateSurge 特性门^[39]

版本说明

有关 Kubernetes v1.27 的完整详细信息，请参阅我们的版本说明^[40]。

下载

Kubernetes v1.27 可在 GitHub^[41] 上下载。要开始使用 Kubernetes，你可以使用 minikube^[42]、kind^[43] 等本地 Kubernetes 集群。你还可以使用 kubeadm^[44] 轻松安装 v1.27。

发行团队

Kubernetes 只有在其社区的支持、承诺和辛勤工作下才能实现。每个发行团队都由专注的社区志愿者组成，他们一起构建组成 Kubernetes 版本的许多部分。这需要来自社区各个角落的具有专业技能的人员，从代码本身到其文档和项目管理。

特别感谢我们的发行主管 Xander Grzywinski，他引导我们顺利而成功地完成了发行周期，并感谢发行团队的所有成员互相支持并为社区生产 v1.27 版本而努力工作。

生态系统更新

• 2023 年欧洲 KubeCon + CloudNativeCon 将于 2023 年 4 月 17 日至 21 日在荷兰阿姆斯特丹举行！你可以在活动网站^[45]上找到有关会议和注册的更多信息。
• cdCon + GitOpsCon 将于 2023 年 5 月 8 日至 9 日在加拿大温哥华举行！有关会议和注册的更多信息，请访问活动网站^[46]。

项目速度

CNCF K8s DevStats^[47] 项目聚合了许多与 Kubernetes 和各种子项目的速度相关的有趣数据点。这包括从个人贡献到贡献的公司数量，是对投入到发展这个生态系统的广度和深度的说明。

在为期 14 周^[48]的 v1.27 发布周期（1 月 9 日至 4 月 11 日）中，我们看到了来自 1020 家公司^[49]和 1603 个个人^[50]的贡献。

即将到来的版本网络研讨会

加入 Kubernetes v1.27 发布团队的成员，于 2023 年 4 月 14 日星期五上午 10 点 PDT，了解本次发布的主要功能，以及弃用和移除情况，帮助计划升级。有关更多信息和注册，请访问 CNCF Online Program 网站上的活动页面^[51]。

参与其中

参与 Kubernetes 最简单的方法是加入与你感兴趣的特别兴趣小组^[52]（SIG）。

你有想要广播给 Kubernetes 社区的内容吗？在我们的每周社区会议^[53]上分享你的声音，并通过以下渠道：

• 在 Kubernetes 贡献者网站^[54]上了解更多有关为 Kubernetes 做出贡献的信息。
• 在 Twitter 上关注我们的最新动态 @Kubernetesio^[55]。
• 在 Discuss^[56] 上加入社区讨论。
• 加入 Slack^[57] 社区。
• 在 Server Fault^[58] 上发布问题（或回答问题）。
• 分享^[59]你的 Kubernetes 故事。
• 在博客^[60]上了解有关 Kubernetes 的更多信息。
• 了解有关 Kubernetes 发布团队^[61]的更多信息。

参考资料