Kubernetes v1.28 的主题是 Planternetes。

下面是 Kubernetes 1.28 的徽标。

每一次 Kubernetes 的版本发布，都代表着我们社区中成千上万人的共同努力与成果。参与此次发布的人员背景各异，有的是行业资深人士，有的是家长，还有的是学生或是开源领域的新手。我们汇集了各自的经验与专长，共同打造了这一具有全球影响力的产品。

这像一个花园，我们的发布像其生长中的植物一样，经历了各种变化、挑战和机遇。此次的主题就是为了纪念我们付出的精心照料、决心和努力，证明我们和谐共生，共同成长。

这次更新允许测试并扩展核心节点和控制平面组件间的支持版本差异，从之前的 n-2 版本扩展至 n-3 版本。这意味着，受支持的最早的小版本中的节点组件（如 kubelet 和 kube-proxy）可以与最新受支持的小版本的控制平面组件（如 kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）协同工作。

这对终端用户很有价值，因为控制平面升级比节点升级要快一些，而节点升级几乎总是要比运行中的工作负载升级时间更长。

Kubernetes 已经提供了年度支持期，用户可以随时升级到最新的补丁版本以修复安全问题，每年还可以连续进行 3 次小版本的升级，以便与最新支持的小版本保持同步。

但当前的问题是，节点与控制平面之间经过测试并支持的版本偏差限制在两个版本，这意味着三个版本的升级将需要两次更新节点，以保证保持在受支持的版本偏差范围内。

如果节点意外关闭或最终处于不可恢复的状态（可能是由于硬件故障或操作系统反应迟钝），Kubernetes 允许你进行事后清理，并允许有状态的工作负载在不同的节点上重新启动。对于 Kubernetes v1.28，这是一项稳定的功能。

这意味着，当原始节点被关闭或遭遇如硬件故障或系统损坏的非可恢复状态时，状态性工作负载可以成功地切换到另一个节点。

Kubernetes v1.20 之前的版本缺乏对 Linux 上节点关闭的处理，而 kubelet 集成了 systemd 并实现了优雅的节点关闭（beta 版，默认已启用）。不过，即使是有意关闭，也可能无法得到很好的处理，这可能是因为： 

当节点关闭或发生故障，而 kubelet 又未检测到该节点关闭时，作为 StatefulSet 一部分的 Pod 将停留在关闭节点上的终止状态。如果停止的节点重新启动，该节点上的 kubelet 可以清理（DELETE）Kubernetes API 仍然认为与该节点绑定的 Pod。

但是，如果节点一直处于停止状态，或者 kubelet 在重启后无法启动，那么 Kubernetes 可能无法创建替代 Pod。当关闭节点上的 kubelet 无法删除旧的 Pod 时，相关的 StatefulSet 就无法创建新的 Pod（名称相同）。 

存储方面也有问题。如果有 Pod 使用的卷，现有的 VolumeAttachments 不会与原始节点（现已关闭）分离，因此这些 Pod 使用的 PersistentVolumes 无法连接到其他健康的节点。因此，在受影响的 StatefulSet 上运行的应用程序可能无法正常运行。

如果原来关闭的节点恢复运行，那么它们的 Pod 将被其 kubelet 删除，新的 Pod 可以在不同的运行节点上创建。如果原始节点没有启动（这在不可变的基础设施设计中很常见），这些 Pod 将永远停留在关闭节点上的 “终止” 状态。

有关如何在非顺利节点关闭后触发清理的详细信息，请阅读：

https://kubernetes.io/docs/concepts/architecture/nodes/#non-graceful-node-shutdown

通用表达式语言（CEL）可用于验证自定义资源。其主要目标是允许大多数验证用例，而这些用例曾经可能需要你作为自定义资源定义（CRD）的作者来设计和实现 webhook。取而代之的是，作为一个 beta 功能，你可以将验证表达式直接添加到 CRD 的模式中。

直接支持复杂验证对于 CRD 来说是必要的。尽管接纳 webhooks 支持 CRD 验证，但它们使 CRD 的开发和操作变得相对复杂。

在 1.28 中，添加了两个可选字段 reason 和 fieldPath，用户可以指定失败的原因和字段路径。

更多信息，请阅读：

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules

用于入场控制的通用表达式语言是对 Kubernetes API 服务器请求的可定制、进程内验证，可替代验证入场 webhooks。

为入场控制的通用表达式语言提供了一种定制化的、内置的请求验证方法，这是对验证入场 webhooks 的一个替代方案。

该功能建立在 1.25 版升级到测试版的 CRD 验证规则功能的基础上，但侧重于验证入场控制的策略执行功能。    

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

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

Kubernetes v1.27 版允许你为入场 webhooks 指定匹配条件，这让你可以缩小 Kubernetes 在入场时进行远程 HTTP 调用的范围。ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 matchCondition 字段是一个 CEL 表达式，其值必须为 “true”，接纳请求才会发送到 Webhook。

在 Kubernetes v1.28 中，该字段被移至 beta 版，并且默认启用。

要了解更多信息，请参阅：

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchconditions

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

交换有两种不同类型的用户，他们可能会重叠：

当一个集群拥有多个混合版本的 API 服务器时（例如在升级/降级期间，或运行时配置发生变化和部署发生时），并非每个 apiserver 都能为每个版本的每个资源提供服务。 

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

在集群上执行升级或降级时，控制平面内的 API 服务器可能会在一段时间内处于不同的版本；当这种情况发生时，API 服务器的不同子集能够为不同的内置资源集提供服务（不同的组、版本和资源都是可能的）。这种新的 alpha 功能可以帮助你向客户端隐藏这种偏差。

Kubernetes 的贡献者们已经开始重组 kube-apiserver 的代码，以建立一个新的暂存仓库，该仓库消耗 k/apiserver，但拥有更大的、精心挑选的 kube-apiserver 功能子集，从而使其可以重用。

这是一个循序渐进的重组过程；最终会有一个新的 Git 仓库，其通用功能将从 Kubernetes 的 API 服务器中抽象出来。 

CDI 提供了将复杂设备注入容器的标准化方式（即逻辑上需要注入不止一个 /dev 节点才能工作的设备）。这一新特性使插件开发人员能够利用 1.27 版中添加到 CRI 的 CDIDevices 字段，将 CDI 设备直接传递给启用了 CDI 的运行时（如 containerd 和 crio-o 的最新版本）。

Kubernetes 1.28 为 init 容器引入了一个 alpha restartPolicy 字段，并用它来指示 init 容器何时也是 Sidecar 容器。它将按照定义的顺序与其他 init 容器一起启动，并设定 restartPolicy 为 Always。kubelet 会在启动 Pod 的主容器前仅等待 Sidecar init 容器启动。

启动完成的条件是启动探针成功（或未定义启动探针）且 postStart 处理程序已完成。该条件用 ContainerStatus 类型的字段 Started 表示。

对于 init 容器，可以省略重启策略字段，或将其设置为 Always。省略该字段意味着你想要一个真正的 init 容器，在应用启动前完成。  

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

对于 Sidecar 容器，重启行为比 init 容器更复杂。在重启策略设置为 Never 的 Pod 中，在 Pod 启动过程中失败的 Sidecar 容器不会被重启，整个 Pod 将被视为失败。如果 Pod 的 restartPolicy 是 Always 或 OnFailure，则会重试启动失败的 Sidecar 容器。  

一旦 Sidecar 容器启动（进程正在运行、postStart 成功且任何配置的启动探针都已通过），然后出现故障，即使 Pod 的整体重启策略为 Never 或 OnFailure，Sidecar 容器也会重新启动。此外，即使在 Pod 终止期间，也会重启（在失败或正常退出时）Sidecar 容器。  

要了解更多信息，请阅读：

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers

如果没有提供值，Kubernetes 会自动为 PersistentVolumeClaim （PVC） 设置一个 StorageClassName。对于那些没有定义 storageClassName 的现有 PVC，控制平面也会自动设置一个 StorageClass。Kubernetes 以前的版本也有这种行为；Kubernetes v1.28 则是自动的，并且始终处于激活状态；该功能已升级到稳定版（一般可用性）。  

要了解更多信息，请阅读：

https://kubernetes.io/docs/concepts/storage/storage-classes/

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

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

在前一个 Pod 完全终止之前出现一个替代 Pod，也会给资源稀缺或预算紧张的集群带来问题。这些资源可能很难获得，因此只有在现有 Pod 终止后，Pod 才能找到节点。如果启用了群集自动分级器，提前创建替代 Pod 可能会产生不希望的扩展。  

要了解更多信息，请阅读：

https://kubernetes.io/docs/concepts/workloads/controllers/job/#delayed-creation-of-replacement-pods

此功能扩展了 Job API，支持索引任务，在索引 Job 中，重试限制是按索引计算的，Job 可以在部分索引失败的情况下继续执行。

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

因此，现有的实现并没有涵盖这种情况，即工作负载真正地令人尴尬地并行：每个索引都完全独立于其他索引。

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

更多信息，请阅读：

https://kubernetes.io/docs/concepts/workloads/controllers/job/#handling-pod-and-container-failures

这包括两项相关工作（修改 kubelet 的 /metrics/cadvisor 端点和改进替换摘要 API）。 

消费者主要使用两个 API 来收集有关正在运行的容器和 Pod 的统计数据：summary API 和 /metrics/cadvisor。Kubelet 负责实现 summary API，cAdvisor 负责实现 /metrics/cadvisor。  

这增强了 CRI 实现，使其能够满足 Kubernetes 的所有统计需求。从高层次来看，这有两个部分：

该版本共包含 12 项升级到稳定版的增强功能：

1）删除：

2）停用：

下载链接：

https://github.com/kubernetes/kubernetes/releases/tag/v1.28.0