发布日期：2023年8月15日，2023年的第二个版本，Kubernetes v1.28 Planternetes，正式发布啦！
本次发布共包含45项增强功能。其中，19个进入Alpha阶段，14个升级至Beta阶段，12个已经成为Stable版本。
0 发布主题和标志
Kubernetes v1.28的主题是Planternetes。
下面看新增内容：
1 支持控制平面和节点版本之间的变化
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，可选择每年只在每个日历年内对节点进行一次小版本升级，仍然保持在上游支持范围内。
如希望保持最新并更频繁地升级集群，这也是完全支持。
2 可用性：从非优雅的节点关闭中恢复
如果节点意外关闭或处于不可恢复的状态（可能由于硬件故障或无响应的操作系统），Kubernetes允许您在此之后进行清理，并允许有状态的工作负载在不同的节点上重启。对于Kubernetes v1.28，这已是稳定功能。
这允许有状态的工作负载在原始节点关闭或不可恢复的状态（如硬件故障或损坏的操作系统）后成功故障转移至不同的节点，例如硬件故障或损坏的操作系统。
比v1.20早的Kubernetes版本缺乏对Linux节点关闭的处理，kubelet与systemd集成并实现优雅的节点关闭（beta版本，默认启用）。但即使故意关闭，也可能无法处理得很好，原因可能：
- 节点运行Windows
- 节点运行Linux，但使用不同的
init（而不是systemd） - 关闭未触发系统抑制锁机制
- 由于节点级配置错误（例如没有为
shutdownGracePeriod和shutdownGracePeriodCriticalPods设置适当的值）
当节点关闭或失败，且kubelet未检测到该关闭时，作为StatefulSet一部分的Pod将停留在关闭节点上处于终止状态。如停止的节点重新启动，该节点上的kubelet可以清理（删除）Kubernetes API仍然视为绑定到该节点的Pod。但是，如果节点保持停止状态 - 或者如果kubelet在重新启动后无法启动 - 则Kubernetes可能无法创建替换Pod。当关闭的节点上的kubelet无法删除旧的Pod时，相关联的StatefulSet无法创建新的Pod（其名称将相同）。
此外，存储也存在问题。如Pod使用卷，现有的VolumeAttachments将不会与原始关闭的节点解除关联，因此由这些Pod使用的PersistentVolumes无法附加到不同的、健康的节点。因此，运行在受影响StatefulSet上的应用程序可能无法正常运行。如果原始关闭的节点启动，那么其Pod将被其kubelet删除，并且新的Pod可以在不同的运行节点上创建。如果原始节点不会启动（在不可变基础设施设计中常见），这些Pod将永远停留在关闭的节点上处于“终止”状态。
如何在非优雅的节点关闭后触发清理的更多信息，参阅Kubernetes文档中关于非优雅的节点关闭的内容。
3 改进CustomResourceDefinition验证规则
通用表达式语言（CEL）可用于验证自定义资源。主要目标允许大多数验证用例直接添加到CRD的模式，避免CRD作者需要设计和实现webhook。作为beta功能，可直接将验证表达式添加到CRD的模式中，而不需验证webhook。
CRD需要直接支持非平凡验证。尽管Admission Webhooks支持CRD验证，但它们会极大地增加CRD的开发和可操作性的复杂性。
在1.28版本添加两个可选字段:
- `reason``
- ``fieldPath`
允许用户在验证失败时指定失败原因和字段路径。
更多信息参阅CRD文档中的验证规则。
4 升级为Beta：ValidatingAdmissionPolicies
通用表达式语言用于Admission控制，可以作为验证Admission Webhooks的一种可定制的、进程内验证Kubernetes API服务器请求的方法。
这是在1.25中升级为Beta的CRD验证规则功能的基础上构建的，但其重点在于验证Admission控制的策略执行能力。
这将降低执行可定制策略的基础设施门槛，并提供帮助社区建立和遵循K8s及其扩展的最佳实践的基本元素。
要使用ValidatingAdmissionPolicies，需在集群的控制平面中启用admissionregistration.k8s.io/v1beta1 API组以及ValidatingAdmissionPolicy功能开关。
5 Admission Webhooks的匹配条件
Kubernetes v1.27允许您为Admission Webhooks指定匹配条件，这可以缩小Kubernetes在Admission时进行远程HTTP调用的范围。ValidatingWebhookConfiguration和MutatingWebhookConfiguration的matchCondition字段是一个CEL表达式，该表达式必须为Admission请求评估为true，才会将该请求发送到webhook。
在Kubernetes v1.28中，该字段已经升级为Beta，默认启用。
要了解更多信息，请参阅Kubernetes文档中的matchConditions。
6 在Linux上支持交换空间（Beta）
这将以可控的、可预测的方式向节点添加交换支持，以便Kubernetes用户可以执行测试并提供数据，以便在交换的基础上继续构建集群功能。
有两种不同类型的交换用户，可能会重叠：
- 节点管理员，可能希望节点级性能调优和稳定性/减少噪声邻居问题时可用交换
- 应用程序开发人员，已编写的应用程序可以从使用交换内存中受益
7 混合版本代理（Alpha）
当集群具有多个混合版本的API服务器（例如在升级/降级期间或运行时配置更改和滚动升级发生时），并非每个API服务器都能够为每个版本的每个资源提供服务。
对于Kubernetes v1.28，您可以在API服务器的聚合层中启用混合版本代理。混合版本代理在本地API服务器无法识别但控制平面内的另一个API服务器能够支持的请求中找到请求。在找到合适的对等体后，聚合层将请求代理到兼容的API服务器；对客户端来说，这是透明的。
在集群上进行升级或降级时，控制平面内的API服务器一段时间内可能处于不同的版本状态；在发生这种情况时，API服务器的不同子集能够为不同的内置资源提供服务（不同的组、版本和资源都是可能的）。这种新的Alpha机制允许您将这种偏差对客户端隐藏起来。
8 控制平面组件的源代码重新组织
Kubernetes贡献者已开始对kube-apiserver的代码进行重新组织，以建立一个新的staging存储库，该存储库使用k/apiserver，但具有更大、经过精心选择的kube-apiserver功能子集，以便可以重复使用。
这是一个渐进的重新组织过程；最终将会有一个新的git存储库，其中包含了从Kubernetes的API服务器中抽象出的通用功能。
9 对容器进行CDI注入的支持（Alpha）
CDI提供了一种将复杂设备注入到容器中的标准化方法（即逻辑上需要多个/dev节点才能注入的设备）。这个新特性使插件开发人员可以利用在1.27中添加到CRI中的CDIDevices字段，将CDI设备直接传递给CDI启用的运行时（containerd和crio-o在最近的版本中）。
10 API意识的sidecar容器（Alpha）
Kubernetes1.28引入了一个用于init容器的Alpha级别的restartPolicy字段，并使用该字段指示何时init容器也是sidecar容器。kubelet将以restartPolicy: Always的顺序启动具有定义的init容器，以及其他init容器。与等待sidecar init容器完成之后再启动主容器（Pod的其他部分）不同，kubelet仅在sidecar init容器启动后等待。
kubelet将认为sidecar容器的启动已完成，如果启动探测成功并且postStart处理程序已完成。这个条件用ContainerStatus类型的Started字段表示。如果未定义启动探测，kubelet将在postStart处理程序完成后立即认为容器启动已完成。
对于init容器，您可以省略restartPolicy字段，或将其设置为Always。省略该字段意味着您想要一个真正的init容器，在应用程序启动之前运行到完成。
sidecar容器不会阻止Pod的完成：如果所有常规容器都完成了，该Pod中的sidecar容器将被终止。
一旦sidecar容器启动（进程运行，postStart成功，任何配置的启动探测都通过），然后发生故障，即使Pod的整体restartPolicy为Never或OnFailure，也将重新启动该sidecar容器。此外，在Pod终止时，sidecar容器将在故障或正常退出时重新启动。
要了解更多信息，请阅读Kubernetes文档中关于sidecar容器的API的内容。
11 自动、追溯分配默认的StorageClass（Stable）
如果您没有提供值，Kubernetes会自动为PersistentVolumeClaim（PVC）设置storageClassName。控制平面还会为任何现有的PVC设置一个StorageClass，如果没有定义storageClassName。之前的Kubernetes版本也具有此行为；对于Kubernetes v1.28，它是自动的并且始终处于活动状态；该功能已升级为稳定（一般可用性）。
要了解更多信息，请在Kubernetes文档中阅读有关StorageClass的内容。
12 Job的Pod替换策略（Alpha）
Kubernetes 1.28为Job API添加了一个新字段，允许您指定是否希望控制平面在之前的Pod开始终止时立即创建新的Pod（现有行为），或者仅在现有的Pod完全终止后才创建新的Pod（新的、可选的行为）。
许多常见的机器学习框架，例如Tensorflow和JAX，需要每个索引独立的Pod。对于旧的行为，如果属于“Indexed” Job的Pod进入终止状态（由于抢占、驱逐或其他外部因素），则会创建一个替换的Pod，但由于与尚未关闭的旧Pod的冲突而立即无法启动。
在现有Pod完全终止之前出现替换Pod，也可能在资源稀缺或预算紧张的集群中引起问题。这些资源可能难以获取，因此只有在现有的Pod终止后，Pod才能找到节点。如果启用了集群自动缩放器，提前创建替换Pod可能会产生不希望的规模增加。
要了解更多信息，请在Job文档中阅读关于延迟创建替换Pod的内容。
13 Job重试的回退限制，按索引（Alpha）
这将Job API扩展为支持按索引进行作业，其中回退限制是按索引计算的，Job可以继续执行，即使它的某些索引失败。
目前，索引作业的索引共享单个回退限制。当作业达到此共享回退限制时，作业控制器将整个作业标记为失败，并清除资源，包括尚未运行完成的索引。
因此，现有的实现未涵盖工作负载真正的尴尬并行情况：每个索引完全独立于其他索引。
例如，如果以索引作业为基础进行一组长时间运行的集成测试，那么每个测试运行只能找到一个测试失败。
要了解更多信息，请在Kubernetes文档中阅读关于处理Pod和容器故障的内容。
更正：去除了CRI容器和pod统计信息（无cAdvisor），因为它没有包含在发布中。原始发布公告中提到Kubernetes 1.28包括了这个新功能。
14 Kubernetes v1.28的功能提升和弃用
14.1 升级到稳定版
该发布包括12个升级为稳定版的增强功能：
-
…
14.2 弃用和删除
删除：
弃用：
16 可用性
Kubernetes v1.28可在GitHub上下载。要开始使用Kubernetes，您可以使用minikube、kind等在本地运行Kubernetes集群。也可以使用kubeadm轻松安装v1.28。
参考
- https://kubernetes.io/blog/2023/08/15/kubernetes-v1-28-release/
- CNCF K8s DevStats项目：汇总了与Kubernetes及其各个子项目的速度相关的许多有趣的数据点。这包括从个人贡献到贡献公司数量的一切，是进化这个生态系统所需努力的深度和广度的体现