4. Kubernetes 版本语义：major.minor.patch格式、版本兼容性矩阵、kubelet与kube-apiserver版本约束
在构建 Kyverno 准入控制策略以拦截集群升级版本漂移之前，必须深入理解 Kubernetes 的版本语义体系。版本号不仅是标识，更是集群组件间通信与协作的契约。本章将系统解析版本号格式、兼容性矩阵以及 kubelet 与 kube-apiserver 之间的版本约束关系。
4.1 版本号语义：major.minor.patch 格式
Kubernetes 遵循标准的语义化版本 2.0.0 规范，版本号格式为 vMAJOR.MINOR.PATCH。每个字段代表不同的变更范围和兼容性承诺：
| 字段 | 示例 | 变更含义 | 兼容性影响 |
|---|---|---|---|
| MAJOR | 1 | 不兼容的 API 变更或架构重构 | 通常需要迁移脚本或重写配置 |
| MINOR | 28 | 新增功能、特性门控、API 弃用 | 向后兼容，但弃用 API 需关注 |
| PATCH | 3 | 安全修复、Bug 修复、性能优化 | 完全向后兼容，推荐立即升级 |
关键认知：在 Kubernetes 生态中，MAJOR 版本至今仍为 1，尚未出现 v2.0。因此实际生产环境中，版本漂移主要发生在 MINOR 和 PATCH 层级。Kyverno 策略通常需要拦截 MINOR 版本的不一致，而 PATCH 版本差异在大多数场景下可被容忍。
版本号还隐含了发布阶段标识：
- alpha：如 v1.28.0-alpha.1，内部测试，不保证稳定性。
- beta：如 v1.28.0-beta.2，功能冻结，社区验证。
- stable：如 v1.28.0，正式发布，生产可用。
4.2 版本兼容性矩阵
Kubernetes 官方维护了一份版本兼容性矩阵，定义了不同组件之间的支持范围。以下是核心的兼容性规则：
核心原则：Kubernetes 仅支持最近 3 个 MINOR 版本。例如，当最新稳定版为 v1.30 时，官方支持 v1.30、v1.29、v1.28。超出此范围的版本将不再接收安全补丁。
| 组件对 | 兼容性要求 | 最大版本偏差 |
|---|---|---|
| kube-apiserver ↔ kube-controller-manager | 必须相同 MINOR 版本 | 0 |
| kube-apiserver ↔ kube-scheduler | 必须相同 MINOR 版本 | 0 |
| kube-apiserver ↔ kubelet | kubelet 版本 ≤ apiserver 版本 | 最多低 2 个 MINOR |
| kube-apiserver ↔ kubectl | kubectl 版本偏差 ±1 MINOR | ±1 |
| kube-apiserver ↔ cloud-controller-manager | 必须相同 MINOR 版本 | 0 |
版本漂移风险：当集群中不同节点的 kubelet 版本与 kube-apiserver 版本偏差超过 2 个 MINOR 时，kubelet 可能无法正确解析 API 资源，导致 Pod 调度失败、节点状态异常甚至数据面中断。这正是 Kyverno 准入控制需要拦截的核心场景。
4.3 kubelet 与 kube-apiserver 版本约束详解
kubelet 与 kube-apiserver 之间的版本约束是集群升级中最容易产生漂移的环节。官方文档明确规定了以下约束：
- kubelet 版本不得高于 kube-apiserver 版本。例如，kube-apiserver 为 v1.28，则 kubelet 最高只能为 v1.28。
- kubelet 版本可以低于 kube-apiserver 最多 2 个 MINOR 版本。例如，kube-apiserver 为 v1.30，则 kubelet 最低可为 v1.28。
- PATCH 版本不受此限制。kubelet v1.28.3 可以与 kube-apiserver v1.28.1 共存。
以下 SVG 图展示了 kubelet 与 kube-apiserver 之间的版本约束关系：
4.4 版本漂移的典型场景
在实际生产环境中，版本漂移通常由以下操作引发：
- 节点滚动升级不同步：控制面已升级到 v1.30，但部分工作节点仍停留在 v1.28 以下。
- 自动扩缩容引入旧版本节点：集群自动扩缩容时，从旧镜像模板创建了低版本 kubelet 的节点。
- 混合版本集群管理不当：多集群管理工具误将低版本节点注册到高版本控制面。
- 节点重建后版本回退：节点故障重建时，使用了未更新的节点镜像，导致 kubelet 版本回退。
Kyverno 策略切入点：在上述场景中，当新节点尝试加入集群时，kubelet 会向 kube-apiserver 发起 CSR（证书签名请求）或 Node 资源创建请求。Kyverno 可以通过准入控制拦截这些请求，检查请求中携带的 kubelet 版本信息，并与集群当前版本进行比对，从而阻止版本漂移。
4.5 版本信息在 Kubernetes 资源中的体现
kubelet 的版本信息在以下 Kubernetes 资源中可被获取：
| 资源类型 | 字段路径 | 示例值 |
|---|---|---|
| Node | status.nodeInfo.kubeletVersion |
v1.28.3 |
| Node | status.nodeInfo.kubeProxyVersion |
v1.28.3 |
| CertificateSigningRequest | spec.request (需解码) |
包含 kubelet 版本信息 |
以下是一个 Node 资源的版本信息片段示例：
apiVersion: v1
kind: Node
metadata:
name: worker-node-1
status:
nodeInfo:
architecture: amd64
bootID: 123e4567-e89b-12d3-a456-426614174000
containerRuntimeVersion: containerd://1.7.6
kernelVersion: 5.15.0-91-generic
kubeProxyVersion: v1.28.3
kubeletVersion: v1.28.3
operatingSystem: linux
osImage: Ubuntu 22.04.3 LTS
策略编写提示：在 Kyverno 策略中，可以使用
status.nodeInfo.kubeletVersion 字段作为版本比对的数据源。通过 JMESPath 表达式提取版本号中的 MAJOR.MINOR 部分，并与集群期望版本进行字符串或数值比较。
4.6 版本漂移拦截策略设计思路
基于上述版本约束，设计 Kyverno 准入控制策略的核心思路如下：
- 拦截点：Node 资源的 CREATE 和 UPDATE 操作。
- 比对逻辑：提取
status.nodeInfo.kubeletVersion中的 MAJOR.MINOR 部分，与集群控制面版本（可通过 ConfigMap 或硬编码定义）进行比对。 - 允许条件：kubelet 版本 ≤ 控制面版本，且偏差 ≤ 2 个 MINOR 版本。
- 拒绝条件：kubelet 版本 > 控制面版本，或偏差 > 2 个 MINOR 版本。
以下 SVG 图展示了 Kyverno 拦截版本漂移的决策流程：
4.7 版本约束的实践检查清单
在实施 Kyverno 策略之前，建议完成以下检查：
| 检查项 | 说明 | 验证方法 |
|---|---|---|
| 集群当前版本 | 确认 kube-apiserver 的准确版本 | kubectl version --short |
| 节点版本分布 | 统计所有节点的 kubelet 版本 | kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}' |
| 版本偏差阈值 | 确定允许的最大 MINOR 版本偏差 | 根据官方兼容性矩阵设定 |
| 升级窗口 | 定义版本漂移拦截的生效时间范围 | 结合集群维护窗口配置 |
重要提醒：版本漂移拦截策略应作为安全防线，而非常规升级流程的替代品。建议在 CI/CD 流水线中预先验证节点镜像版本，确保加入集群的节点版本始终在允许范围内。Kyverno 策略作为最后一道准入屏障，防止意外或恶意操作导致版本不一致。