本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.27: Chill Vibes

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

我们很高兴地宣布 Kubernetes v1.27 的发布，这是 2023 年的第一个版本！

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

Kubernetes v1.27: Chill Vibes

Kubernetes v1.27 的主题是*放松一下 (Chill Vibes)*。

这个主题听起来有点傻，但这次发布中一些重要的转变激发了这个主题。在一个典型的 Kubernetes 发布周期中，特性需要满足几个最后期限才能被包含进来。如果某个特性错过了任何一个最后期限，它们可以走一个例外流程。处理这些例外情况是发布过程中的正常部分。但 v1.27 是所有人记忆中第一个在增强功能冻结后没有收到任何例外请求的版本。即使在发布过程中，事情也比我们任何人习惯的要平静得多。

这次我们能够享受一个更平静的发布，有一个特定的原因，那就是人们在幕后为改善我们管理发布的方式所做的所有工作。这个主题正是为了庆祝那些为了让社区变得更好而努力工作的人们。

特别感谢 Britnee Laverack 创作了这个徽标。Britnee 也为 Kubernetes 1.24: Stargazer 设计了徽标。

新功能（主要主题）

冻结 k8s.gcr.io 镜像仓库

旧的镜像仓库 k8s.gcr.io 将被 registry.k8s.io 替代，后者已经正式可用好几个月了。Kubernetes 项目创建并运行着 registry.k8s.io 镜像仓库，该仓库完全由社区控制。这意味着旧仓库 k8s.gcr.io 将被冻结，Kubernetes 及相关子项目的镜像将不再发布到旧仓库。

这一变化对贡献者意味着什么？

  • 如果你是某个子项目的维护者，你需要更新你的清单（manifests）和 Helm charts 来使用新的仓库。更多信息，请查看这个 项目。

这一变化对最终用户意味着什么？

  • 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 配置文件默认设置，你必须在每个想要使用它的节点上，使用 --seccomp-default 命令行标志来运行 kubelet。如果启用，kubelet 将默认使用由容器运行时定义的 RuntimeDefault seccomp 配置文件，而不是使用 Unconfined（seccomp 禁用）模式。默认配置文件旨在提供一组强大的安全默认设置，同时保留工作负载的功能。不同容器运行时及其发布版本之间的默认配置文件可能会有所不同。

你可以在相关的 Kubernetes 增强提案（KEP）中找到关于可能的升级和降级策略的详细信息：默认启用 seccomp。

Job 的可变调度指令进入正式发布（GA）

这个功能在 v1.22 中引入，并以 Beta 级别开始，现在已稳定。在大多数情况下，并行 Job 希望 Pod 在有约束的条件下运行，比如都在同一个区域，或者都在 GPU 型号 x 或 y 上，但不能是两者的混合。suspend 字段是实现这些语义的第一步。suspend 允许自定义队列控制器决定 Job 何时应该启动。然而，一旦 Job 被取消挂起，自定义队列控制器就无法影响 Job 的 Pod 实际会落在哪里。

此功能允许在 Job 启动前更新其调度指令，这使得自定义队列控制器能够影响 Pod 的放置，同时将实际的 Pod 到节点的分配工作交给 kube-scheduler。这仅适用于从未被取消挂起过的已挂起 Job。Job 的 Pod 模板中可以更新的字段包括节点亲和性、节点选择器、容忍度、标签、注解和调度门控（scheduling gates）。在 KEP 中查找更多细节：允许更新 Job 的调度指令。

DownwardAPIHugePages 毕业进入稳定版

在 Kubernetes v1.20 中，对 requests.hugepages-<pagesize> 和 limits.hugepages-<pagesize> 的支持被添加到了 downward API 中，以与 cpu、内存和临时存储等其他资源保持一致。此功能在此版本中毕业进入稳定版。你可以在 KEP 中找到更多细节：Downward API HugePages。

Pod 调度就绪进入 Beta 阶段

创建后，Pod 就准备好进行调度了。Kubernetes 调度器会尽职尽责地寻找节点来放置所有待处理的 Pod。然而，在实际情况中，一些 Pod 可能会长时间处于*缺少必要资源*的状态。这些 Pod 实际上会以不必要的方式搅动调度器（以及像 Cluster Autoscaler 这样的下游集成者）。

通过指定/移除 Pod 的 .spec.schedulingGates，你可以控制 Pod 何时准备好被考虑进行调度。

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

通过 Kubernetes API 访问节点日志

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

集群管理员可以在其集群的所有节点上或其中一部分节点上试用此 alpha 功能。

ReadWriteOncePod PersistentVolume 访问模式进入 Beta 阶段

Kubernetes v1.22 为 PersistentVolumes (PVs) 和 PersistentVolumeClaims (PVCs) 引入了一种新的访问模式 ReadWriteOncePod。此访问模式使你能够将卷访问限制为集群中的单个 Pod，确保一次只有一个 Pod 可以写入该卷。这对于需要单写入者访问存储的有状态工作负载特别有用。

ReadWriteOncePod 的 Beta 版本增加了对使用 ReadWriteOncePod PVC 的 Pod 进行调度器抢占的支持。调度器抢占允许较高优先级的 Pod 抢占较低优先级的 Pod。例如，当一个带有 ReadWriteOncePod PVC 的 Pod (A) 被调度时，如果发现另一个 Pod (B) 正在使用相同的 PVC，并且 Pod (A) 具有更高的优先级，调度器将返回一个 Unschedulable 状态并尝试抢占 Pod (B)。更多背景信息，请参见 KEP：ReadWriteOncePod PersistentVolume AccessMode。

滚动升级后遵循 PodTopologySpread

matchLabelKeys 是一个 Pod 标签键的列表，用于选择将要计算分布的 Pod。这些键用于从 Pod 标签中查找值。这些键值标签与 labelSelector 进行逻辑与操作，以选择将为传入的 Pod 计算分布的现有 Pod 组。在 Pod 标签中不存在的键将被忽略。null 或空列表意味着只与 labelSelector 匹配。

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

使用挂载加速 SELinux 卷重新标记

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

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

如果 Kubernetes 知道 Pod 的 SELinux 标签**并且**负责 Pod 卷的 CSI 驱动程序宣布 SELinuxMount: true **并且**该卷的访问模式为 ReadWriteOncePod，那么它将要求 CSI 驱动程序使用挂载选项 context= 挂载该卷**并且**它将告诉容器运行时不要重新标记卷的内容（因为所有文件已经有了正确的标签）。从 KEP 获取更多关于此的信息：使用挂载加速 SELinux 卷重新标记。

健壮的 VolumeManager 重建进入 Beta 阶段

这是一个卷管理器重构，允许 kubelet 在启动期间填充关于现有卷如何挂载的额外信息。总的来说，这使得卷清理更加健壮。如果你在节点上启用 NewVolumeManagerReconstruction 功能门控，你将在 kubelet 启动期间获得对已挂载卷的增强发现。

在 Kubernetes v1.25 之前，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 个晋升为稳定的增强功能

弃用和移除

此版本移除了几项内容

发布说明

Kubernetes v1.27 发布的完整细节可在我们的发布说明中找到。

可用性

Kubernetes v1.27 可在 GitHub 上下载。要开始使用 Kubernetes，你可以使用 minikube、kind 等工具在本地运行 Kubernetes 集群。你也可以使用 kubeadm 轻松安装 v1.27。

发布团队

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

特别感谢我们的发布负责人 Xander Grzywinski 引导我们度过了一个顺利而成功的发布周期，并感谢所有发布团队成员的相互支持和辛勤工作，为社区带来了 v1.27 版本。

生态系统更新

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

项目速度

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

在 v1.27 发布周期中，该周期持续了 14 周（1月9日至4月11日），我们看到了来自 1020 家公司和 1603 名个人的贡献。

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

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

参与其中

参与 Kubernetes 的最简单方法是加入与你兴趣相符的众多特别兴趣小组（SIG）之一。

有什么想向 Kubernetes 社区广播的内容吗？在我们每周的社区会议上分享你的声音，并通过以下渠道进行分享：