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

Kubernetes v1.28: Planternetes

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

宣布发布 Kubernetes v1.28 Planternetes，这是 2023 年的第二个版本！

此版本包含 45 项增强功能。其中，19 项进入 Alpha 阶段，14 项已升级至 Beta 阶段，12 项已升级至 Stable (稳定) 阶段。

Kubernetes v1.28：Planternetes

Kubernetes v1.28 的主题是 Planternetes。

每个 Kubernetes 版本的发布都凝聚了社区中数千人的辛勤工作。参与本次版本发布的人员来自广泛的背景，其中有行业资深人士、家长，也有学生和开源新手。我们结合各自独特的经验，共同创造出一个具有全球影响力的集体成果。

正如花园一样，我们的版本发布也伴随着不断的变化、挑战和机遇。这个主题颂扬了为使版本达到今天这个成就所付出的细致的关怀、意图和努力。和谐共处，我们共同成长得更好。

新特性概览（主要主题）

控制平面和节点版本之间支持的差异变化

Kubernetes v1.28 将核心节点和控制平面组件之间支持的版本差异从 n-2 扩展到 n-3，以便最旧支持的次要版本节点组件（kubelet 和 kube-proxy）可以与最新支持的次要版本控制平面组件（kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）协同工作。

一些集群操作员会避免节点维护，特别是避免更改节点行为，因为节点是工作负载运行的地方。对于 kubelet 的次要版本升级，支持的流程包括排空该节点，这会中断在该节点上运行的任何 Pod。对于运行非常长时间工作负载的 Kubernetes 最终用户，以及希望 Pod 尽可能保持运行的用户，减少因节点维护而损失的时间是一种优势。

Kubernetes 的年度支持期已经使得年度升级成为可能。用户可以升级到最新的补丁版本以获取安全修复，并每年进行 3 次连续的次要版本升级，以“赶上”最新的受支持次要版本。

以前，为了保持在支持的版本差异范围内，计划年度升级的集群操作员需要升级他们的节点两次（可能仅相隔几个小时）。现在，使用 Kubernetes v1.28，您可以选择每年只对节点进行一次次要版本升级，并且仍然保持在上游支持范围内。

如果您希望保持最新并更频繁地升级集群，那也完全没有问题，并且仍然受到全面支持。

正式可用：从非正常节点关机中恢复

如果节点意外关机或进入不可恢复状态（可能是由于硬件故障或操作系统无响应），Kubernetes 允许您在事后进行清理，并允许有状态工作负载在其他节点上重新启动。对于 Kubernetes v1.28，这现在是一个稳定功能。

这使得有状态工作负载能够在原始节点关机或处于不可恢复状态（例如硬件故障或操作系统损坏）后成功地故障转移到其他节点。

Kubernetes v1.20 之前的版本缺乏对 Linux 节点关机的处理，kubelet 集成了 systemd 并实现了优雅节点关机（Beta 版，默认启用）。然而，即使是故意的关机也可能处理不当，这可能是因为

  • 节点运行 Windows
  • 节点运行 Linux，但使用不同的 init（不是 systemd）
  • 关机未触发系统抑制锁机制
  • 由于节点级别配置错误（例如未为 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 设置适当的值）。

当节点关机或发生故障，且该关机未被 kubelet 检测到时，属于 StatefulSet 的 Pod 将卡在关机节点上的 Terminating 状态。如果停止的节点重新启动，该节点上的 kubelet 可以清理（DELETE）Kubernetes API 仍然认为绑定到该节点的 Pod。但是，如果节点保持停止状态 - 或者如果 kubelet 在重启后无法启动 - 那么 Kubernetes 可能无法创建替换 Pod。当关机节点上的 kubelet 不可用以删除旧 Pod 时，关联的 StatefulSet 无法创建新的 Pod（新 Pod 将具有相同的名称）。

存储也存在问题。如果 Pod 使用了卷，现有的 VolumeAttachments 将不会与原始（现已关机）节点分离，因此这些 Pod 使用的 PersistentVolume 无法挂载到另一个健康的节点。因此，受影响的 StatefulSet 上运行的应用可能无法正常工作。如果原始的关机节点确实启动，其 Pod 将被其 kubelet 删除，并且可以在另一个运行节点上创建新的 Pod。如果原始节点没有启动（这在不可变基础设施设计中很常见），这些 Pod 将永远卡在关机节点上的 Terminating 状态。

有关如何在非正常节点关机后触发清理的更多信息，请阅读非正常节点关机文档。

CustomResourceDefinition 验证规则改进

通用表达式语言 (CEL) 可用于验证自定义资源。主要目标是支持大多数验证用例，这些用例过去可能需要您（作为 CustomResourceDefinition (CRD) 作者）设计和实现 webhook。现在，作为一项 Beta 功能，您可以直接将验证表达式添加到 CRD 的 schema 中。

CRD 需要直接支持非平凡验证。虽然 admission webhooks 支持 CRD 验证，但它们显著增加了 CRD 的开发和可操作性复杂性。

在 1.28 中，新增了两个可选字段 reason 和 fieldPath，允许用户在验证失败时指定失败原因和 fieldPath。

更多信息，请阅读 CRD 文档中的验证规则。

ValidatingAdmissionPolicies 升级至 Beta

Admission 控制的通用表达式语言是可定制的，它作为验证性 Admission Webhook 的替代方案，对 Kubernetes API 服务器的请求进行进程内验证。

这基于 1.25 版本升级到 Beta 的 CRD 验证规则功能，但重点在于验证性 Admission 控制的策略执行能力。

这将降低强制执行可定制策略的基础设施障碍，并提供有助于社区建立和遵循 K8s 及其扩展最佳实践的原语。

要使用ValidatingAdmissionPolicies，您需要在集群的控制平面中同时启用 admissionregistration.k8s.io/v1beta1 API 组和 ValidatingAdmissionPolicy 功能门。

Admission Webhook 的匹配条件

Kubernetes v1.27 允许您为 admission webhooks 指定匹配条件，这使您可以缩小 Kubernetes 在 admission 时进行远程 HTTP 调用的范围。ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 matchCondition 字段是一个 CEL 表达式，只有当它评估为 true 时，admission 请求才会被发送到 webhook。

在 Kubernetes v1.28 中，该字段已移至 Beta 阶段，并且默认启用。

要了解更多信息，请参阅 Kubernetes 文档中的matchConditions。

Beta 支持在 Linux 上启用 swap 空间

这以受控、可预测的方式为节点添加了 swap 支持，以便 Kubernetes 用户可以进行测试并提供数据，以继续在 swap 的基础上构建集群功能。

有两种不同类型的 swap 用户，它们可能重叠

  • 节点管理员，他们可能希望利用 swap 进行节点级性能调优和稳定性/减少吵闹邻居问题。

  • 应用开发者，他们编写的应用将受益于使用 swap 内存。

混合版本代理 (Alpha)

当集群中有多个处于混合版本（例如升级/降级期间或 runtime-config 更改并发生 rollout 时）的 API 服务器时，并非每个 apiserver 都能以每个版本服务所有资源。

对于 Kubernetes v1.28，您可以在 API 服务器的聚合层中启用混合版本代理。混合版本代理会查找本地 API 服务器不认识但控制平面内另一个 API 服务器能够支持的请求。找到合适的对等方后，聚合层会将请求代理到兼容的 API 服务器；这对客户端来说是透明的。

当集群进行升级或降级时，在一段时间内，控制平面内的 API 服务器可能处于不同的版本；此时，API 服务器的不同子集能够服务不同的内置资源集（不同的组、版本和资源都是可能的）。这个新的 Alpha 机制允许您对客户端隐藏这种差异。

控制平面组件的源代码重组

Kubernetes 贡献者已开始重组 kube-apiserver 的代码，以便基于一个新的 staging 仓库构建，该仓库使用 k/apiserver，但包含 kube-apiserver 功能中更大且经过精心选择的子集，以便可重用。

这是一个渐进式的重组；最终将出现一个新的 git 仓库，其中包含从 Kubernetes API 服务器抽象出的通用功能。

支持 CDI 注入容器 (Alpha)

CDI 提供了一种将复杂设备注入容器的标准化方式（即，逻辑上需要注入单个 /dev 节点以上才能工作的设备）。这项新功能使插件开发者能够利用 1.27 版本添加到 CRI 中的 CDIDevices 字段，将 CDI 设备直接传递给支持 CDI 的运行时（其中 containerd 和 crio-o 在最近版本中已支持）。

API 对 Sidecar 容器的感知 (Alpha)

Kubernetes 1.28 为Init Container 引入了一个 Alpha 阶段的 restartPolicy 字段，并用它来指示一个 Init Container 何时也是一个Sidecar Container。Kubelet 会按照定义的顺序启动 restartPolicy: Always 的 Init Container，与其他 Init Container 一起。与等待该 Sidecar Container 完成后再启动 Pod 的主容器不同，kubelet 只会等待 Sidecar Init Container 启动完成。

如果启动探针成功且 postStart handler 完成，kubelet 将认为 sidecar 容器的启动已完成。此条件通过 ContainerStatus 类型的 Started 字段表示。如果您未定义启动探针，kubelet 将在 postStart handler 完成后立即认为容器启动已完成。

对于 Init Container，您可以省略 restartPolicy 字段，或将其设置为 Always。省略该字段表示您需要一个真正的 Init Container，它在应用启动前运行完成。

Sidecar 容器不会阻塞 Pod 完成：如果所有常规容器都已完成，该 Pod 中的 sidecar 容器将被终止。

一旦 sidecar 容器启动（进程正在运行，postStart 成功，并且任何配置的启动探针都通过），然后发生故障，即使 Pod 的整体 restartPolicy 是 Never 或 OnFailure，该 sidecar 容器也会重新启动。此外，sidecar 容器将在故障或正常退出时重新启动，即使在 Pod 终止期间也是如此。

要了解更多信息，请阅读Sidecar 容器 API 文档。

默认 StorageClass 的自动追溯分配升级至稳定

如果您未提供值，Kubernetes 会自动为 PersistentVolumeClaim (PVC) 设置 storageClassName。控制平面还会为任何未定义 storageClassName 的现有 PVC 设置 StorageClass。以前版本的 Kubernetes 也具有此行为；对于 Kubernetes v1.28，它是自动且始终激活的；此功能已升级至稳定 (正式可用) 阶段。

要了解更多信息，请阅读 Kubernetes 文档中关于StorageClass 的内容。

Job 的 Pod 替换策略 (Alpha)

Kubernetes 1.28 为 Job API 添加了一个新字段，允许您指定是希望控制平面在旧 Pod 开始终止时立即创建新 Pod（现有行为），还是仅在现有 Pod 完全终止后才创建（新的、可选行为）。

许多常见的机器学习框架，例如 Tensorflow 和 JAX，要求每个索引对应唯一的 Pod。在旧的行为下，如果属于 Indexed Job 的 Pod 进入终止状态（由于抢占、驱逐或其他外部因素），会创建替换 Pod，但由于与尚未关机的旧 Pod 冲突，该替换 Pod 会立即启动失败。

在旧 Pod 完全终止之前出现替换 Pod 也可能在资源稀缺或预算紧张的集群中导致问题。这些资源很难获得，因此 Pod 可能只有在现有 Pod 终止后才能找到节点。如果启用了集群自动扩缩器，过早创建替换 Pod 可能会导致不必要的扩容。

要了解更多信息，请阅读 Job 文档中的延迟创建替换 Pod。

Job 按索引重试退避限制 (Alpha)

这扩展了 Job API，以支持带有按索引退避限制的索引 Job，并且 Job 即使在部分索引失败的情况下也可以继续执行。

目前，索引 Job 的索引共享一个单一的退避限制。当 Job 达到此共享退避限制时，Job 控制器将整个 Job 标记为失败，并清理资源，包括尚未运行完成的索引。

因此，现有实现并未涵盖工作负载真正 极度并行（embarrassingly parallel）的情况：每个索引完全独立于其他索引。

例如，如果索引 Job 被用作一系列长时间运行的集成测试的基础，那么每次测试运行时将只能发现一个测试失败。

有关更多信息，请阅读 Kubernetes 文档中的处理 Pod 和容器故障。

更正：CRI 容器和 Pod 统计信息无需 cAdvisor 功能已移除，因为它未在发布版中提供。原始发布公告曾声明 Kubernetes 1.28 包含了该新功能。

Kubernetes v1.28 中的功能升级与废弃

升级至稳定版

此版本共有 12 项增强功能被升级至稳定版

废弃与移除

移除项

废弃项

发行说明

Kubernetes v1.28 发行版的完整详情可在我们的发行说明中找到。

可用性

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

发布团队

Kubernetes 仅在社区的支持、承诺和辛勤工作下才得以实现。每个发布团队都由敬业的社区志愿者组成，他们共同努力构建您所依赖的 Kubernetes 发布版的许多组成部分。这需要来自我们社区各个角落的人们的专业技能，从代码本身到其文档和项目管理。

我们要感谢整个发布团队投入大量时间辛勤工作，确保为我们的社区提供一个可靠的 Kubernetes v1.28 发布版。

特别感谢发布负责人 Grace Nguyen，她指导我们顺利成功地完成了发布周期。

生态系统更新

  • KubeCon + CloudNativeCon China 2023 将于 2023 年 9 月 26 日至 28 日在中国上海举行！您可以在活动网站上找到有关会议和注册的更多信息。
  • KubeCon + CloudNativeCon North America 2023 将于 2023 年 11 月 6 日至 9 日在美国伊利诺伊州芝加哥举行！您可以在活动网站上找到有关会议和注册的更多信息。

项目速度

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

在 v1.28 发布周期中，该周期持续了 14 周（5 月 15 日至 8 月 15 日），我们看到了来自911 家公司和1440 名个人的贡献。

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

加入 Kubernetes v1.28 发布团队成员，参加于太平洋时间 (PDT) 2023 年 9 月 6 日星期三上午 9 点举行的网络研讨会，了解此版本的主要功能以及废弃和移除项，以便为升级做好规划。有关更多信息和注册，请访问 CNCF 在线计划网站上的活动页面。

参与其中

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

有什么想向 Kubernetes 社区广播的吗？在我们的每周社区会议上以及通过以下渠道分享您的声音：