3. K8s集群升级对策略的影响：API版本变更、CRD变化、准入控制器行为差异
Kubernetes 集群升级并非简单的版本号变更，它对运行中的 Rego 策略可能产生静默破坏或性能退化。本章聚焦三大核心影响维度：API 版本变更、CRD 结构变化、准入控制器行为差异，帮助你在升级前精准识别风险点。
⚠️ 升级前必知： 超过 60% 的 Rego 策略故障在集群升级后 48 小时内才被发现，原因往往是策略作者未意识到底层 API 对象的字段路径或默认值已改变。本章内容可帮助你提前规避此类问题。
3.1 API 版本变更对 Rego 策略的影响
K8s API 版本（如 v1、v1beta1、v1alpha1）在升级过程中可能被废弃或移除。Rego 策略中硬编码的 apiVersion 字段路径将直接失效。
| API 版本变更类型 | 典型场景 | 对 Rego 策略的影响 |
|---|---|---|
| 版本废弃 | extensions/v1beta1 → apps/v1（Ingress、Deployment） |
策略中 input.request.object.apiVersion == "extensions/v1beta1" 永远不匹配 |
| 字段重命名 | deployment.spec.rollbackTo 在 apps/v1 中被移除 |
策略引用 input.request.object.spec.rollbackTo 导致 undefined 或规则静默跳过 |
| 默认值变化 | PodSecurityPolicy 在 v1.25 被移除，替换为 PSA |
策略依赖的 input.request.object.spec.securityContext 默认值逻辑改变 |
| 结构字段类型变更 | Container.ports.containerPort 从 string 变为 integer |
Rego 类型断言 is_string(port) 失败，规则抛出运行时错误 |
🔍 检测方法： 在升级前运行
kubectl convert --validate=true 对集群中所有现有资源进行版本转换验证。同时，在 Rego 策略中添加 apiVersion 白名单检查，拒绝未知版本。
3.2 CRD 变化对 Rego 策略的影响
自定义资源定义（CRD）在升级过程中可能发生结构模式（structural schema）变更、版本转换或字段验证规则调整。Rego 策略如果直接引用 CRD 的嵌套字段，将面临以下风险：
- 字段路径变更： CRD 从
v1alpha1升级到v1时，字段可能被重新组织到新的嵌套结构下。 - 必填字段新增： 升级后 CRD 要求某些字段必须存在，但现有资源不包含，导致 Rego 策略中
input.request.object.spec.newField为undefined。 - 枚举值范围缩小： CRD 的
enum约束收紧，策略中允许的值可能在新版本中被拒绝。 - 类型转换： 字段类型从
string变为object，Rego 的object.get()调用可能抛出类型不匹配错误。
💡 最佳实践： 在 Rego 策略中使用
object.get() 并设置默认值，避免直接点号访问可能不存在的字段。例如：spec := object.get(input.request.object, ["spec"], {})。
3.3 准入控制器行为差异
K8s 集群升级可能改变准入控制器（Admission Controller）的执行顺序、启用状态或默认行为，从而影响 Rego 策略的输入数据。
| 准入控制器行为变化 | 升级前 | 升级后 | 对 Rego 策略的影响 |
|---|---|---|---|
| MutatingWebhook 执行顺序 | Rego 策略在 MutatingWebhook 之后执行 | Rego 策略在 MutatingWebhook 之前执行 | 策略看到的 input.request.object 未经过变异，缺少默认值 |
| ValidatingAdmissionPolicy 启用 | 未启用（CEL 策略未激活） | 默认启用 CEL 策略 | Rego 策略与 CEL 策略可能产生冲突或重复验证 |
| PodNodeSelector 行为 | 仅作用于 Pod 创建 | 作用于 Pod 更新（v1.24+） | Rego 策略中 input.request.operation == "UPDATE" 分支被触发 |
| ResourceQuota 校验时机 | 在 Rego 策略之后校验 | 在 Rego 策略之前校验 | 策略可能收到被 Quota 拒绝的请求，导致重复拒绝 |
3.4 综合影响评估矩阵
以下矩阵帮助你快速评估集群升级对现有 Rego 策略的风险等级：
| 影响维度 | 风险等级 | 典型症状 | 检测窗口 |
|---|---|---|---|
| API 版本废弃 | 高 | 策略规则永远不匹配，所有请求通过 | 升级后立即暴露 |
| CRD 字段路径变更 | 高 | Rego 抛出 undefined 错误，规则静默跳过 |
首次触发该 CRD 资源时 |
| 准入控制器顺序变化 | 中 | 策略误判合规性，产生误报或漏报 | 需要对比升级前后日志 |
| 字段默认值变化 | 中 | 策略对未显式设置的字段行为不一致 | 需要回归测试 |
| CRD 枚举值范围缩小 | 低-中 | 策略允许的值被 API Server 拒绝 | 创建/更新资源时 |
🛡️ 防御性策略编写建议：
- 始终使用
object.get()访问嵌套字段，并设置合理的默认值。 - 在策略开头添加
apiVersion白名单检查，拒绝未知版本。 - 对 CRD 资源使用
input.request.object.apiVersion动态判断版本，而非硬编码。 - 在升级前运行
opa eval --data policy.rego --input test-fixtures/对历史资源进行回归测试。
3.5 升级前策略兼容性检查清单
- ☑️ API 版本扫描： 使用
kubectl api-resources --api-group=列出所有已启用 API 版本，与策略中引用的版本交叉比对。 - ☑️ CRD 结构验证： 对每个 CRD 运行
kubectl explain crd.spec.versions.schema.openAPIV3Schema检查字段路径是否匹配。 - ☑️ 准入控制器顺序确认： 查看
kube-apiserver --enable-admission-plugins参数，确认 MutatingWebhook 与 ValidatingWebhook 的相对顺序。 - ☑️ 默认值回归测试： 准备一组最小化资源定义（不设置可选字段），验证 Rego 策略是否仍能正确评估。
- ☑️ 性能基线对比： 在升级前记录策略评估延迟（P99），升级后对比是否出现退化。