Kubernetes 1.28版本：变更摘要（新特性！）和升级注意事项

2 年 ago

科, 雅

3 minutes

首先

这篇文章提供了关于Kubernetes 1.28的CHANGELOG，以及来自Kubernetes v1.28: Planternetes的新特性和升级注意事项的链接。请参考各个总结页面以了解更详细信息。

请提供有关更改详情的链接。

Metrics Changes と SIG Instrumentation @watawuwu

SIG Apps @yosshi_

SIG API Machinery @Ladicle

SIG Auth @hiyosi

SIG CLI @superbrothers

SIG Cluster Lifecycle @yuanying

SIG Storage @ysakashita

SIG Network @tkusumi

SIG Scheduling @ordovicia

SIG Node @y1r96

新闻有哪些重点内容

控制平面和节点版本之间支持的偏移发生了变化。

为了支持核心节点和控制平面组件之间的版本错配从n-2扩大到n-3，最新支持的控制平面组件（kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）和最旧支持的节点组件（kubelet和kube-proxy）能够正常工作。控制平面升级通常比正在运行工作负载的节点升级快一些，因此对于最终用户来说具有价值。

Kubernetes的一年支持期已经使得年度升级可行。用户可以升级到最新的补丁版本以修复安全问题，并且每年可以进行一次三个次要版本的升级以追赶最新的次要版本。

然而，由于目前节点和控制平面之间的测试/支持错配仅限于两个版本，因此在进行三个版本的升级时，需要两次节点更新以适应支持的错配范围内。

通常可用：从非优雅节点关闭恢复

如果节点在意外情况下无法恢复正常（可能是由于硬件故障或操作系统无响应），使用Kubernetes可以在之后清理并在另一个节点上重新启动有状态的工作负载。在Kubernetes v1.28中，这已成为稳定的功能。

这使得在原节点关机或无法恢复正常之后，有状态的工作负载可以故障转移至不同的节点。

在Kubernetes v1.20之前的版本中，缺乏处理Linux节点关机的功能，但kubelet已与systemd集成，并实现了优雅的节点关机（目前处于测试阶段，并默认启用）。然而，由于以下原因，即使是意图良好的关机操作也可能无法正确处理。

ノードレベルの設定エラー(適切な値がshutdownGracePeriodやshutdownGracePeriodCriticalPodsへ設定されていないなど)

当节点关机或者出现故障时，如果该关机没有被kubelet检测到，StatefulSet的Pod将保持在关闭节点上的终止状态。当停止的节点重新启动时，该节点上的kubelet可以通过清除（DELETE）仍然将Kubernetes API视为绑定到该节点的Pod。然而，如果节点继续停机或者在重启后kubelet无法启动，Kubernetes可能无法创建替代的Pod。当关闭节点上的kubelet无法删除旧的Pod时，相关的StatefulSet将无法创建新的具有相同名称的Pod。

而且存储也存在问题。如果该Pod所使用的卷存在，现有的VolumeAttachments将不会从原始节点（目前已关闭）中分离出来，因此无法将这些Pod使用的PersistentVolumes附加到另一个正常的节点上。结果是，运行在受影响的StatefulSet上的应用可能无法正常工作。如果关闭的原始节点重新启动，则这些Pod将被其kubelet删除，并可以在另一个正在运行的节点上创建新的Pod。如果原始节点无法启动（这在不可变基础架构设计中很常见），则这些Pod将永远无法从已关闭节点的终止状态中退出。

关于触发非正常节点关闭后的清理的方法，请参考非正常节点关闭。

NodeOutOfServiceVolumeDetachfeature がGAとなった話のようです。

詳細は @ysakashita さんの Kubernetes: Non Graceful Node Shutdownの動作検証　をご参照ください。

对于CustomResourceDefinition的验证规则进行改进。

常用表达语言（CEL）现在可用于对CustomResource进行验证。主要目标是以前作为CustomResourceDefinition（CRD）的创建者所需的webhook的设计和实现的验证用例的大部分。作为Beta功能，您可以直接向CRD架构中添加验证表达式，而不是使用webhook。

CRD需要直接支持复杂的验证。Admission webhook提供了对CRD的验证支持，但它们也使得CRD的开发和运营变得复杂。

从1.28版本开始，我们添加了两个可选字段，即reason和fieldPath，用于当验证失败时，用户可以指定失败原因和字段路径。

请参考CRD文档中的验证规则以获取详细信息。

验证入学政策毕业进入测试阶段

使用Common Expression Language（CEL）的Admission Control提供了可定制的in-process验证，以替代Validating Admission Webhook，对Kubernetes API服务器上的请求进行验证。

这是基于CRD的Validation Rules在1.25版本中成为beta版的功能，但着重于强制执行Validating admission control策略的功能。

通过这个方式，不仅降低了实施可定制化政策所需的基础设施障碍，还为社区提供了确立和遵守K8s及其扩展功能的最佳实践所需的基本要素。

Translated: Through this approach, not only does it lower the barrier of infrastructure for implementing customizable policies, but it also provides the essential elements that help the community establish and comply with the best practices of both K8s and its extensions.

要使用ValidatingAdmissionPolicies，您需要在控制平面上启用admissionregistration.k8s.io/v1beta1 API组和ValidatingAdmissionPolicy功能开关。

匹配入场通知的条件网络钩子

Kubernetes v1.27允许为admission webhook指定匹配条件，并且这使得Kubernetes在admission时调用外部HTTP时的范围可以缩小。
对于应该发送到webhook的admission请求，ValidatingWebhookConfiguration和MutatingWebhookConfiguration的matchCondition字段描述了应该评估为true的CEL表达式。

从 Kubernetes v1.28 开始，该字段将成为 beta 版，并默认启用。

请参考Kubernetes文档中的matchConditions以获取详细信息。

在Linux上启用交换空间的Beta支持

これにより、Kubernetesユーザーがテストを実施し、スワップ上にクラスタ機能を構築し続けるためのデータを提供できるように、制御された予測可能な方法でノードにスワップサポートが追加されます。

在使用债务互换的用户中，存在两种明确的重复情况：

スワップメモリ利用するとメリットがあるアプリケーションを開発したアプリケーション開発者

混合版本代理（alpha版）

当集群中存在多个不同版本的API服务器时（例如在升级/降级、运行时配置更改或进行扩展时），并非所有API服务器都能够提供所有版本的所有资源。

在Kubernetes v1.28中，您可以在API服务器的聚合层中启用混合版本代理。混合版本代理可以找到本地API服务器不能识别的其他可支持的API服务器。如果找到了适当的对等节点，聚合层将把请求代理到兼容的API服务器上。对于客户端来说，这是透明的。

クラスタのアップグレードやダウングレード時、しばらくの間コントロールプレーンのAPIサーバは異なるバージョンとなるかもしれません。そうなると、APIサーバの異なるサブセットは異なる組み込みリソース・セット（異なるグループ、バージョン、リソースがすべて可能）を提供できるようになります。この新しいアルファ機能はクライアントからそれらのskewを隠蔽してくれます。

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

Kubernetes的贡献者们开始重新组织kube-apiserver的代码，他们正在使用k/apiserver，并构建一个基于全新的暂存库的基础，该库具有更大、更精心选择的kube-apiserver功能的可重用子集。

这是一个分阶段的重组，最终将会有一个具有抽象化通用功能的新Git存储库，源自Kubernetes的API服务器。

支持将CDI注入到容器中（alpha版本）

CDIは複雑なデバイスをコンテナへインジェクションするスタンダードな方法を提供します（つまり、動作させるためにノードの/devを一つ以上注入する必要があるデバイス）。この新機能により、プラグイン開発者は、1.27のCRIに追加されたCDIDevicesフィールドを使用して、CDIデバイスを直接CDI対応のランタイム（最近のリリースではcontainerdとcrio-oが該当）に渡すことができます。

API对侧车容器的认知（α版本）

Kubernetes 1.28ではalphaでinit containerのためにrestartPolicyフィールドを導入し、init containerがサイドカーコンテナとして存在していることを示すためにそのフィールドを利用します。これによりrestartPolicy: Alwaysが設定されたinit containerは定義された順番で、他のinit containerと共にスタートします。Podのメインのコンテナがスタートする前に、kubeletはそのサイドカーコンテナが完了を待つ代わりに、サイドカーのinit containerがスタートするのだけ待ちます。

そのスタートアップの完了条件はstartup probeが成功したということ(もしくはstartup probeが定義されていない場合)そしてpostStart handlerが完了したこととなります。この条件はContainerStatus型のStartedフィールドで表現されます。このシグナルを選択した判断については”Pod startup completed condition”セクションをご確認ください。

サイドカーコンテナでは、init containerよりrestartの振る舞いが複雑です。restartPolicyがNeverへセットされているPodでは、Podのスタートアップ中に失敗するサイドカーコンテナはリスタートされず、Pod全体が終了として扱われます。もしPodのrestartPolicyがAlwaysまたはOnFailureにセットされている場合、起動に失敗したサイドカーはリトライされます。

一度サイドカーコンテナが起動後(プロセスが動作し、postStartが成功し、全ての設定されたstartup probeがパス)、何らかで失敗すると、Pod全体のrestartPolicyがNeverまたはOnFailureであってもサイドカーコンテナはリスタートされます。さらに、サイドカーコンテナはPodがTermination中でさえもリスタートされます(失敗または通常の終了で)。

詳細はサイドカーコンテナのAPIをご参照ください。

自动、追溯地分配默认的StorageClass升级至稳定版。

如果Kubernetes的PersistentVolumeClaim的storageClassName没有设置，它会自动设置。控制平面将为所有尚未定义storageClassName的现有PVC设置StorageClass。以前的Kubernetes版本也具有此功能，但在Kubernetes v1.28中，它始终自动激活。该功能已升级为稳定版本（General Availability）。

请仔细阅读Kubernetes文档中关于StorageClass的部分以获取更详细的信息。

作业（alpha版）的Pod替换政策

在Kubernetes 1.28中，Job API增加了一个新字段，用于指定当前Pod开始终止时，控制平面是立即创建新的Pod（旧有操作），还是等待现有Pod完全终止（新选项操作）。

许多常见的机器学习框架，例如Tensorflow和JAX，对每个索引都需要唯一的Pod。在旧的行为中，当属于Indexed Job的Pod进入终止状态时（由于抢占、驱逐或其他外部因素），会创建替代的Pod，但由于与尚未关闭的旧Pod的冲突，它们很快会启动失败。

前のPodが完全に終了する前に代替のPodが現れることは、リソースが少ないクラスターや予算が厳しいクラスターでも問題を引き起こすことがあります。これらのリソースは入手が難しいため、既存のポッドが終了した後でのみノードを見つけることができるかもしれません。クラスターオートスケーラが有効になっている場合、代替Podの早期作成は望ましくないスケールアップを引き起こす可能性があります。

请详细阅读Job文档中的”延迟创建替代Pod”部分。

工作重试退避限制，每索引（阿尔法）

通过这个功能，Job API将具备按索引设定的退避限制，并且扩展为支持索引化作业，即使某些索引失败，也能够继续执行Job。

目前，索引化的作业索引共享一个单一的后退限制。当作业达到此共享后退限制时，作业控制器会将整个作业标记为失败，并清理资源。这包括未完成执行的索引。

因此，既有的实施没有涵盖工作负载真正“尴尬地并行”的场景：每个索引都是与其他索引完全独立的。

假设有一个用于长时间执行的集成测试套件，其中包含索引化的任务作为基础。在这种情况下，每个测试执行只能发现单个测试失败。

请阅读Kubernetes文档中的”处理Pod和容器故障”部分，以了解更多详细信息。

在没有cAdvisor的情况下，获取CRI容器和Pod的统计数据。

这涉及到两个相关工作：对kubelet的/metrics/cadvisor端点进行更改，以及对替代的summary API进行改进。

为了收集与动态容器和Pod相关的统计数据，消费者使用了两个主要的API：summary API和/metrics/cadvisor。Kubelet负责实现summary API，而cadvisor负责满足/metrics/cadvisor的请求。

通过这一方法，CRI的实施可以完全满足Kubernetes的统计需求。大致上可以分为两个部分：

CRIの実装が、/metrics/cadvisorエンドポイントのpodとcontainerフィールドを満たすための必要なメトリクスをブロードキャストするように強化されます。

在Kubernetes v1.28中，彰显功能改进和弃用

在此版本中，共有12个增强功能已经稳定可用。

Move EndpointSlice Reconciler into Staging

弃用和移除

搬家

Removal of CSI Migration for GCE PD

降低

(Note: “Deprecations” can be translated as “降低” in Chinese, but it would be helpful to have more context to provide a more accurate translation.)

Ceph FS in-tree plugin

紧急升级通知

（不，真的，升级之前一定要读这个）

1つ以上のQueueingHintFnがQueueImmediatelyを返す場合、PodをactiveQにキューします。
QueueingHintFnがQueueImmediatelyを返さず、1つ以上のプラグインがQueueAfterBackoffを返す場合、Podがバックオフ中の場合はPodをbackoffQにキューし、Podのバックオフが既に終了している場合はactiveQにキューします。
すべてのQueueingHintFnがQueueSkipを返す場合、このPodを未スケジュールポッドプールに戻します。

通过拥有适当的QueueingHintFn函数，可以减少不必要的重试，从而提高调度器的整体性能。

我该如何迁移？

为了保持后向兼容性，如果QueueingHintFn为nil，它将始终返回QueueAfterBackoff。
因此，如果只想继续现有的行为，可以注册没有QueueingHintFn的ClusterEventWithHint。
然而，当然考虑到调度性能，注册适当的QueueingHintFn会更好。

Ceph RBD volumesのCSIマイグレーションのサポートは非推奨となりました。out-of-treeのストレージドライバーへの移行のためのKubernetesの機能を利用していたユーザは、そのサポートが完全に削除される前に移行を完了させる必要があります。(#118303, @carlory)
RBDボリュームプラグイン(kubernetes.io/rbd)はこのリリースで非推奨となり、今後のリリースで削除されます。代替としてはRBD CSI driver(https://github.com/ceph/ceph-csi/)をクラスタで利用することです。([#118552](https://github.com/kubernetes/kubernetes/pull/118552), @humblec)