大家好，我是张晋涛。
Kubernetes v1.28 是 2023 年的第二个大版本更新，包含了 46 项主要的更新。 而今年发布的第一个版本 v1.27 有近 60 项，所以可以看出来，在发布节奏调整后，每个 Kubernetes 版本中都会包含很多新的变化。
其中 20 个增强功能正在进入 Alpha 阶段，14 个将升级到 Beta 阶段，而另外 12 个则将升级到稳定版。
可以看出来很多都是新特性。
我之前每期的 「k8s生态周报」都有一个叫上游进展的部分，会发一些值得关注的内容。
不过最近太忙，停更了几期，正好趁这篇把这些值得关注的内容聊一下。
Kubernetes 集群可以真正年度升级了
我们知道 Kubernetes 集群的架构中 control plane 和 Node 分离的，虽然用户在部署集群的时候，通常会选择将 control plane 和 Node 部署为相同版本。
但是如果要进行集群版本升级的时候，就会发现 control plane 和 Node 在升级过程中是无法保持版本一致的。
举例来说：
- 我部署了一套 v1.23 版本的 Kubernetes 集群，control plane 和 Node 目前都是 v1.23;
- 升级 control plane 到 v1.24;
- 这个时候 Node 还是 v1.23;
- 最后将 Node 也升级到 v1.24;
在这个升级过程中，control plane 和 Node 有一段时间版本是不一致的，这会产生问题吗？
通常来说，对于大多数软件，如果是这种分离式架构，版本不一致是有可能存在问题的（这里我就不说某些系统/软件了）。
但上述过程很明显是一定存在的，所以 Kubernetes 在这方面专门做了处理和兼容 。我们把这个策略叫作 Kubernetes 的版本偏差策略。
Kubernetes 中允许 control plane 和 Node 之间的版本存在 n-2 的偏差。比如：
- control plane 版本为 v1.27
- Node 版本可以为 v1.27, v1.26 和 v1.25
不过从 v1.28 开始，这个版本偏差策略扩展成了 n-3，比如：
- control plane 版本为 v1.28
- Node 版本可以为 v1.28, v1.27, v1.26 和 v1.25
解释完这个版本偏差策略后，我们来看下这个事情到底有多么重要。
Kubernetes 当前的发布和支持策略，是用户可以在一年内持续升级到最新的补丁版本以获取安全修复，并且只要进行 3 个连续的版本升级，就可以追上最新支持的版本了。
然而，由于 control plane 和 Node 之间测试/支持偏差目前仅限于 n-2 个版本，因此每年的 3 个版本升级将不得不进行两次 Node 的升级，才能保持在受支持范围内。例如，从 v1.24 升级到 v1.27 ，这个场景正好是从 2022 年的第一个版本升级到 2023 年的第一个版本。
- control plane 和 Node 都是 v1.24;
- control plane 升级 v1.24 - v1.25 - v1.26;
- Node 升级 v1.24 - v1.26;
- control plane 升级 v1.26 - v1.27
- Node 升级 v1.26 - v1.27
从这里可以看到 Node 要升级两次，事实上在 Kubernetes 集群的维护过程中，Node 版本的升级带来的影响是很大的，
比如原先运行在这些 Node 上的 Pod 需要重新调度/重建等，虽然理想状况下对于业务应该没什么影响（但实际情况下...)
此外，随着集群规模的增加，这个 Node 升级的工作量也是很大的。
如果使用现在新的 n-3 偏差策略，我们来看看效果，还是从 v1.24 到 v1.27 （此处只是用做举例，从 v1.28 才生效）：
- control plane 和 Node 都是 v1.24;
- control plane 升级 v1.24 - v1.25 - v1.26 - v1.27;
- Node 升级 v1.24 - v1.27;
这样的话，Node 只需要升级一次，很明显 节省了很多工作量，并且也可以减少对业务的影响 ，这样也真正实现了 Kubernetes 的年度支持策略。
注意：首个可用 n-3 偏差策略的是 v1.28 ，它允许 control plane 是 v1.28 而 Node 最旧为 v1.25。
关于 Kubernetes 的版本偏差策略的详细说明可以参考 kubernetes.io/releases/ve…
基于 CEL 的 Admission Control 达到 Beta
对 Kubernetes 中的 Adminssion Control 感兴趣的小伙伴可以看看我之前的文章：理清 Kubernetes 中的准入控制（Admission Controller) | MoeLove
- KEP-3488: Implement secondary authz for ValidatingAdmissionPolicy by jpbetz · Pull Request #116054 · kubernetes/kubernetes
- KEP-3488: Implement Enforcement Actions and Audit Annotations by jpbetz · Pull Request #115973 · kubernetes/kubernetes
Kubernetes 在 v1.26 增加了一项很重要的特性，那就是允许使用 CEL 进行 Admission Control，具体内容可以参考我之前写的文章：
Kubernetes v1.26 新特性一览 | MoeLove
其中引入了一个新的资源 ValidatingAdmissionPolicy ，使用起来如下:
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
name: "demo-policy.moelove.info"
Spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: ["apps"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["deployments"]
validations:
- expression: "object.spec.replicas
