作者：Kubernetes v1.28 发布团队[1]
宣布 Kubernetes v1.28 Planternetes 的发布，这是 2023 年的第二个版本！
此版本包含 45 个增强功能。其中，19 个进入 Alpha 阶段，14 个升级为 Beta 阶段，12 个升级为稳定版（Stable）。
发布主题和标志
Kubernetes v1.28: Planternetes
Kubernetes v1.28 的主题是 Planternetes。
每个 Kubernetes 版本的发布都是我们社区成员数千人辛勤工作的结晶。参与此次发布的人员来自各种背景，有些是行业老兵，有些是家长，还有些是学生和开源新手。我们结合自己独特的经验，创造了一个具有全球影响力的集体作品。
就像一个花园一样，我们的发布经历了不断变化的成长、挑战和机遇。这个主题庆祝了为了使发布达到当前的状态而进行的细致关怀、意图和努力。我们和谐地共同成长。
新特性（主要主题）
支持控制平面和节点版本之间的偏差变化
这使得可以通过将核心节点和控制平面组件之间的支持偏差从 n-2 增加到 n-3 来进行测试和扩展，以便最旧支持的次要版本的节点组件（kubelet 和 kube-proxy）能够与最新支持的次要版本的控制平面组件（kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）配合使用。
对于最终用户来说，这非常有价值，因为控制平面升级会比节点升级快一些，而运行负载几乎总是需要更长的时间。
Kubernetes 的年度支持期已经使得年度升级成为可能。用户可以升级到最新的补丁版本以获取安全修复，并在每年进行 3 个连续的次要版本升级，以“赶上”最新支持的次要版本。
然而，由于当前节点和控制平面之间的测试/支持偏差仅限于 2 个版本，如果进行 3 个版本的升级，就需要将节点升级两次以保持在支持的偏差范围内。
正式发布：从非优雅节点关机中恢复
如果节点意外关机或进入不可恢复状态（可能是由于硬件故障或无响应的操作系统），Kubernetes 允许你进行后续清理，并允许有状态的工作负载在不同的节点上重新启动。对于 Kubernetes v1.28，这现在是一个稳定的功能。
这使得有状态的工作负载在原来节点关闭或处于不可恢复状态（如硬件故障或损坏的操作系统）后成功切换到其他节点。
早于 v1.20 版本的 Kubernetes 缺乏对 Linux 节点关机的处理，kubelet 与 systemd 集成并实现优雅的节点关机（测试版，并且默认启用）。然而，即使是有意义的关机也可能无法得到很好处理，可能是因为：
- 节点运行 Windows
- 节点运行 Linux，但使用不同的 init（非 systemd）
- 关机未触发系统抑制锁机制
- 由于节点级配置错误（例如未为 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 设置适当的值）。
当节点关机或故障，并且 kubelet 未检测到关机时，作为 StatefulSet 的一部分的 Pod 将停留在关闭的节点上处于终止状态。如果已停止的节点重新启动，该节点上的 kubelet 可以完成清理（删除）Kubernetes API 仍然认为绑定到该节点的 Pod。然而，如果节点保持停止状态 - 或者在重启后 kubelet 无法启动 - 那么 Kubernetes 可能无法创建替代的 Pod。当关闭的节点上的 kubelet 不可用以删除旧的 Pod 时，相关的 StatefulSet 无法创建新的 Pod（具有相同的名称）。
与存储相关的问题也存在。如果 Pod 使用了卷，现有的 VolumeAttachment 不会与原来的（现在已关闭的）节点解除关联，因此这些 Pod 使用的 PersistentVolumes 无法连接到其他健康的节点。结果，运行在受影响的 StatefulSet 上的应用程序可能无法正常工作。如果原来已关闭的节点重新启动，那么其 kubelet 将删除这些 Pod，并且可以在其他运行的节点上创建新的 Pod。如果原来节点不重新启动（在不可变基础架构[2]设计中常见），那么这些 Pod 将永远停留在关闭的节点上处于终止状态。
有关如何在非优雅节点关机后触发清理的更多信息，请阅读非优雅节点关机[3]。
CustomResourceDefinition 验证规则的改进
CEL[4]（Common Expression Language，通用表达式语言）可以用于验证自定义资源[5]。主要目标是允许大多数验证用例，以前可能需要你作为 CustomResourceDefinition（CRD）作者设计和实现 webhook。相反，作为一项测试功能，你可以直接将验证表达式添加到 CRD 的模式中。
CRD 需要直接支持非平凡验证。尽管准入 webhook 支持 CRD 验证，但它们显著增加了 CRD 的开发和可操作性的复杂性。
在 1.28 中，添加了两个可选字段 reason 和 fieldPath，以允许用户在验证失败时指定失败原因和字段路径。
要了解更多信息，请阅读 CRD 文档中的验证规则[6]。
ValidatingAdmissionPolicies 升级为 beta
用于准入控制的 CEL 是对验证准入 webhook 的替代方法，可在 Kubernetes API 服务器上进行定制化、内部验证请求。
这建立在 CRD 验证规则功能的基础上，该功能在 1.25 中升级为 beta，但重点放在验证准入场控制的策略执行能力上。
这将降低实施可定制策略的基础设施障碍，并提供有助于社区建立和遵守 K8s 及其扩展的最佳实践的基本功能。
要使用ValidatingAdmissionPolicies[7]，你需要在集群的控制平面中启用 admissionregistration.k8s.io/v1beta1 API 组和 ValidatingAdmissionPolicy 功能门。
准入 webhook 的匹配条件
Kubernetes v1.27 允许你为准入 webhook 指定匹配条件，从而可以缩小 Kubernetes 在准入时进行远程 HTTP 调用的范围。ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 matchCondition 字段是一个 CEL 表达式，必须对准入请求进行评估为 true 以将其发送到 webhook。
在 Kubernetes v1.28 中，该字段移至 beta，并且默认启用。
要了解更多信息，请参阅 Kubernetes 文档中的matchConditions[8]。
Linux 上启用 swap 空间的测试支持（beta）
这以可控、可预测的方式向节点添加了对 swap 空间的支持，以便 Kubernetes 用户可以进行测试并提供数据，以继续在 swap 空间的基础上构建群集功能。
swap 空间有两种不同类型的用户，它们可能重叠：
- 节点管理员可能希望 swap 空间可用于节点级性能调优、稳定性和降低噪声问题。
- 应用程序开发人员编写的应用程序可能受益于使用 swap 内存。
混合版本代理（alpha 版）
当集群具有多个混合版本的 API 服务器（例如在升级/降级期间或运行时配置更改和部署发生时），并非每个 API 服务器都能为每个版本的每个资源提供服务。
在 Kubernetes v1.28，你可以在 API 服务器的聚合层中启用混合版本代理。混合版本代理会查找本地 API 服务器无法识别但控制平面中的另一个 API 服务器能够支持的请求。找到合适的对等体后，聚合层将请求代理到兼容的 API 服务器；对于客户端来说，这是透明的。
当对集群进行升级或降级时，一段时间内控制平面中的 API 服务器可能处于不同的版本；在这种情况下，不同的 API 服务器子集能够提供不同的内置资源集（不同的组、版本和资源都是可能的）。这种新的 alpha 机制允许你将这种差异对客户端隐藏起来。
控制平面组件的源代码重组织
Kubernetes 的贡献者已经开始对 kube-apiserver 的代码进行重新组织，构建一个基于新的暂存库的版本，该版本使用k/apiserver[9]，但具有更大且经过精心选择的 kube-apiserver 功能子集，以便可重用。
这是一个渐进的重组织过程；最终将会有一个从 Kubernetes 的 API 服务器中抽象出来的通用功能的新的 git 仓库。
对容器的 CDI 注入的支持（alpha 版）
CDI 提供了一种标准化的方式，将复杂设备注入容器（即逻辑上需要多个/dev 节点才能使其正常工作的设备）。这个新功能允许插件开发者利用在 1.27 版本中添加到 CRI 的 CDIDevices 字段，直接将 CDI 设备传递给支持 CDI 的运行时（如 containerd 和 crio-o 在最近的发布中）。
对边车容器的 API 感知（alpha 版）
Kubernetes 1.28 引入了一个 alpha 版的 restartPolicy 字段，用于指示init 容器[10]同时也是边车容器的情况。它将以所定义的顺序启动具有 restartPolicy: Always 的 init 容器，以及其他 init 容器。与在启动 Pod 的主容器之前等待边车容器完成不同，kubelet 只会等待边车 init 容器启动。
启动完成的条件是启动探针成功（或者如果没有定义启动探针）并且 postStart 处理程序完成。这个条件用 ContainerStatus 类型的 Started 字段表示。有关选择此信号的考虑，请参阅“Pod 启动完成条件”部分。
对于 init 容器，你可以省略 restartPolicy 字段，或者将其设置为 Always。省略该字段意味着你希望一个真正的 init 容器在应用程序启动之前运行到完成。
边车容器不会阻塞 Pod 的完成：如果所有常规容器都完成了，该 Pod 中的边车容器将被终止。
对于边车容器来说，重启行为比 init 容器更复杂。对于 restartPolicy 设置为 Never 的 Pod，如果在 Pod 启动期间边车容器失败，它将不会重新启动，整个 Pod 将被视为失败。如果 Pod 的 restartPolicy 是 Always 或 OnFailure，无法启动的边车容器将重试。
一旦边车容器启动（进程正在运行，postStart 成功，并且任何配置的启动探针通过），然后发生故障，即使 Pod 的整体 restartPolicy 是 Never 或 OnFailure，该边车容器也将重新启动。此外，无论是在 Pod 终止期间还是在正常退出期间，边车容器都将重新启动。
要了解更多信息，请阅读有关边车容器的 API[11]。
自动、回溯地分配默认的 StorageClass 升级到稳定版
如果你没有提供 PersistentVolumeClaim（PVC）的 storageClassName 值，Kubernetes 会自动为其设置 storageClassName。控制平面还会为任何没有定义 storageClassName 的现有 PVC 设置 StorageClass。之前的 Kubernetes 版本也具有此行为；对于 Kubernetes v1.28，它是自动的并且始终处于活动状态；该功能已经升级到稳定版（GA）。
要了解更多信息，请阅读 Kubernetes 文档中的StorageClass[12]。
作业的 Pod 替换策略（alpha 版）
Kubernetes 1.28 为 Job API 添加了一个新字段，允许你指定控制平面在上一个 Pod 开始终止时立即创建新的 Pod（现有行为），或者只有在现有的 Pod 完全终止后才创建新的 Pod（新的、可选行为）。
许多常见的机器学习框架，如 Tensorflow 和 JAX，需要每个索引一个唯一的 Pod。在旧的行为下，如果属于索引作业的 Pod 进入终止状态（由于抢占、驱逐或其他外部因素），会创建一个替代的 Pod，但由于与尚未关闭的旧 Pod 的冲突，它立即无法启动。
在前一个 Pod 完全终止之前出现替代 Pod，也会在资源稀缺或预算资源紧张的集群中造成问题。这些资源可能很难获得，因此只有在现有的 Pod 被终止后，Pod 可能才能找到节点。如果启用了集群自动缩放器，提前创建替代 Pod 可能会导致不必要的扩容。
要了解更多信息，请阅读作业文档中关于延迟创建替代 Pod[13]的内容。
作业重试的退避限制，按索引分配（alpha 版）
这扩展了 Job API，以支持按索引分配退避限制的索引作业，并且即使其中一些索引失败，作业也可以继续执行。
目前，索引作业的索引共享一个共享的退避限制。当作业达到此共享的退避限制时，作业控制器将标记整个作业为失败，并清理资源，包括尚未完成运行的索引。
因此，现有的实现不能涵盖工作量真正易并行[14]的情况：每个索引完全独立于其他索引。
例如，如果索引作业被用作长时间运行的集成测试套件的基础，那么每个测试运行只能找到单个测试失败。
要了解更多信息，请阅读 Kubernetes 文档中有关处理 Pod 和容器故障[15]的内容。
CRI 容器和 pod 统计数据，不需要 cAdvisor
这涉及到两个相关的工作（kubelet 的/metrics/cadvisor 端点的更改和替代 summary API 的改进）。
消费者用于收集运行容器和 pod 统计数据的主要 API 有两个：summary API 和/metrics/cadvisor。Kubelet 负责实现 summary API，cadvisor 负责满足/metrics/cadvisor 的需求。
这将增强 CRI 实现，使其能够满足 Kubernetes 的所有统计需求。从高层来看，主要有两个方面：
- 它通过增强 CRI API 的指标来直接从 CRI 补充 summary API 中的 pod 和容器字段。
- 它增强了 CRI 实现，以广播所需的指标，满足/metrics/cadvisor 端点中的 pod 和容器字段。
Kubernetes v1.28 中的功能升级和弃用
升级为稳定版的功能
此版本中有总共 12 个升级为稳定版的增强功能：
- kubectl events
- 追溯默认的 StorageClass 分配
- 非优雅节点关闭
- 支持第三方设备监视插件
- 获取自身用户属性的 Auth API
- 代理终止端点
- 扩展 DNS 配置
- 清理 IPTables 链的所有权
- 减少 iptables-restore 输入大小
- 将 kubelet pod 资源端点升级为 GA
- 扩展 podresources API 以报告可分配资源
- 将 EndpointSlice Reconciler 移至 Staging
弃用和删除
删除：
- 删除 GCE PD 的 CSI 迁移
弃用：
- Ceph RBD in-tree 插件
- Ceph FS 内 in-tree 插件
发布说明
有关 Kubernetes v1.28 发布的完整详细信息，请参阅我们的发布说明[16]。
下载
Kubernetes v1.28 可在GitHub[17]上下载。要开始使用 Kubernetes，你可以使用minikube[18]、kind[19]等本地 Kubernetes 集群运行。你也可以使用kubeadm[20]轻松安装 v1.28。
发布团队
Kubernetes 只有在其社区的支持、承诺和辛勤工作下才得以实现。每个发布团队都由专注的社区志愿者组成，他们共同努力构建组成你所依赖的 Kubernetes 发布的众多组成部分。这需要来自社区各个角落的人们的专业技能，从代码本身到其文档和项目管理。
我们要感谢整个发布团队为确保我们为社区提供一个稳定的 Kubernetes v1.28 版本而付出的辛勤工作。
特别感谢我们的发布负责人 Grace Nguyen，在整个平稳成功的发布周期中为我们提供指导。
生态系统更新
- KubeCon + CloudNativeCon China 2023 将于 2023 年 9 月 26 日至 28 日在中国上海举行！你可以在活动网站[21]上找到关于会议和注册的更多信息。
- KubeCon + CloudNativeCon North America 2023 将于 2023 年 11 月 6 日至 9 日在美国伊利诺伊州芝加哥举行！你可以在活动网站[22]上找到关于会议和注册的更多信息。
项目速度
CNCF K8s DevStats[23]项目汇总了与 Kubernetes 和各个子项目的发展速度有关的一些有趣数据。这包括从个人贡献到贡献的公司数量等各个方面的内容，展示了这个生态系统不断发展所需的广泛努力的深度和广度。
在为期 14 周[24]（5 月 15 日至 8 月 15 日）的 v1.28 发布周期中，我们看到来自911 家公司[25]和1440 名个人[26]的贡献。
即将举行的网络研讨会
在 2023 年 9 月 14 日星期五上午 10 点（时区：PDT），加入 Kubernetes v1.28 发布团队的成员，了解此版本的主要功能，以及弃用和删除功能，为升级计划提供帮助。有关更多信息和注册，请访问 CNCF Online Programs 网站上的活动页面[27]。
参与其中
参与 Kubernetes 最简单的方法，是加入与你的兴趣相吻合的许多特别兴趣小组[28]（SIG）之一。
你有什么想要向 Kubernetes 社区广播的事情吗？在我们的每周社区会议[29]和以下渠道上分享你的声音：
- 在Kubernetes 贡献者网站[30]上了解更多关于为 Kubernetes 做贡献的信息。
- 在 Twitter 上关注我们的最新动态@Kubernetesio[31]。
- 在Discuss[32]加入社区讨论。
- 在Slack[33]上加入社区。
- 在Server Fault[34]上发布问题（或回答问题）。
- 分享[35]你的 Kubernetes 故事。
- 在博客[36]上了解更多关于 Kubernetes 的最新动态。
- 了解更多关于Kubernetes 发布团队[37]的信息。
