4. 防护验证目标：验证升级期间租户隔离不被破坏、验证蓝图一致性、验证回滚能力

升级窗口防护验证是集群治理蓝图上线的最后一道安全闸门。验证的核心目标并非检验升级本身是否成功，而是确保在升级扰动期间，租户隔离边界、蓝图声明状态以及失败回退路径均保持完整。本章围绕三个验证维度展开，每个维度对应一组可量化的检查项与通过标准。

4.1 验证维度总览

4.2 租户隔离验证

升级过程中，kube-apiserver 重启、kubelet 版本变更、CNI 插件升级均可能导致网络策略或 RBAC 规则暂时失效。隔离验证的目标是发现这些“瞬时破窗”。

4.2.1 隔离验证检查清单

• 网络策略完整性：每个租户命名空间下的 NetworkPolicy 规则在升级前后保持一致，使用 kubectl get networkpolicy -n <tenant> -o yaml 进行差异比对。
• RBAC 权限隔离：验证跨租户 ServiceAccount 无法访问其他租户的 Pod/Service，使用 kubectl auth can-i 模拟跨租户请求。
• 资源配额隔离：升级期间 ResourceQuota 和 LimitRange 未被重置或删除，确保租户资源上限不变。
• Pod 安全上下文：检查所有 Pod 的 securityContext 中 runAsNonRoot、seccompProfile 等字段未因升级而丢失。

#!/bin/bash
# 租户隔离验证脚本片段
TENANTS=("tenant-a" "tenant-b" "tenant-c")
FAIL=0

for ns in "${TENANTS[@]}"; do
  # 检查网络策略数量是否变化
  BEFORE=$(kubectl get netpol -n $ns --no-headers | wc -l)
  AFTER=$(kubectl get netpol -n $ns --no-headers | wc -l)
  if [ "$BEFORE" -ne "$AFTER" ]; then
    echo "FAIL: $ns 网络策略数量不一致"
    FAIL=1
  fi

  # 模拟跨租户访问
  kubectl auth can-i list pods -n tenant-b --as=system:serviceaccount:tenant-a:default
  if [ $? -eq 0 ]; then
    echo "FAIL: tenant-a 可以访问 tenant-b 的 Pod"
    FAIL=1
  fi
done

exit $FAIL

4.3 蓝图一致性验证

蓝图一致性验证的核心是“声明即事实”。升级完成后，集群的实际状态必须与蓝图仓库中的声明文件逐字段匹配，不允许出现任何非预期的漂移。

4.3.1 一致性验证流程

1. 基线采集：升级前对集群关键资源做快照，包括节点版本、kube-system 组件镜像版本、CRD 列表、核心 ConfigMap。
2. 升级后比对：使用 kubectl diff 或 kyverno-json 等工具，将当前集群状态与蓝图声明文件进行结构化比对。
3. 差异分类：将差异分为“预期差异”（如节点镜像版本升级）和“非预期差异”（如 ConfigMap 内容被篡改）。
4. 零漂移判定：非预期差异项必须为零，否则视为蓝图一致性验证失败。

4.4 回滚能力验证

回滚能力是升级窗口的最后一道防线。验证的目标不是“回滚是否成功”，而是“回滚后集群是否与升级前完全一致”。

4.4.1 回滚验证步骤

4.5 防护验证整体流程

以下 SVG 图展示了升级窗口防护验证的完整流程，包含三个验证维度的执行顺序与决策点。

4.6 验证通过标准汇总

以下表格汇总了三个验证维度的通过标准，用于升级窗口的最终决策。