集群升级时的PSS版本管理

集群升级时，Pod Security Standards（PSS）的版本管理是一个容易被低估的环节。很多团队在升级前只检查了 API 兼容性和插件状态，却忽略了准入策略本身也会随 Kubernetes 版本演进。PSS 的具体检查项并非一成不变，尤其涉及操作系统相关字段和各版本允许的设置时，差异可能直接导致升级后原本合规的工作负载被拒绝创建。

问题的根源在于 PSA 标签中的版本语义。命名空间可以通过 enforce-version、audit-version、warn-version 分别固定策略版本，而 latest 则跟随 API Server 版本变化。如果集群长期使用 latest，升级动作本身就可能改变准入判断的基准，造成难以定位的“升级后 Pod 起不来”现象。更稳妥的做法是把策略版本更新作为独立的变更步骤，与 Kubernetes 版本升级分开验证，避免两个变量叠加后无法归因。

升级前的准备应从核对当前标签状态开始。需要记录每个命名空间六个 PSA 标签的原值或不存在状态，并确认集群级默认策略是什么。一个常见的盲区是：删除 enforce 标签后，生效的并非 privileged，而是集群级默认策略，这个默认值如果未提前确认，回滚操作可能引入新的不确定性。同时要检查准入链中的豁免配置——命名空间、用户或 RuntimeClass 的豁免会跳过 PSA 的 enforce、audit 和 warn 检查，因此豁免请求不能作为工作负载合规的证明，升级验证时也不应依赖豁免路径来掩盖问题。

在测试环境验证新版本策略时，建议采用“保留现有强制等级，新增更严格版本的审计”这一路径。例如维持 enforce=baseline 不变，同时设置 audit=restricted 和 warn=restricted，用于提前发现下一阶段可能出现的违规。这种方法的核心价值在于：Baseline 负责当前拦截，Restricted 负责暴露未来的整改清单，两者互不干扰。但要注意，审计依赖请求发生，长时间不重建的旧 Pod、暂停的 CronJob 或未触发的故障恢复路径不会自然出现在日志里，必须将审计结果与控制器清单交叉核对，并通过发布演练或服务端 dry-run 补充覆盖。

服务端 dry-run 是升级前预检的有效工具，但需要明确其边界：它能发现准入警告，却不能代替真实 Pod 创建、调度、挂载和应用健康验证。对于 Deployment 等控制器，整改应落在版本库或部署系统的 Pod 模板上，而非直接修改现有 Pod——否则下次重建仍会恢复旧配置。升级验证的通过标准不应只是“当前业务未中断”，因为标签变更不会修改或驱逐已运行的 Pod，旧模板在后续扩容或节点故障重建时仍可能创建失败。

回滚策略同样需要版本意识。当新 Pod 因 Restricted 被拒绝且业务无法等待整改时，应恢复变更前的实际标签，而不是一律改回 Baseline。如果原状态是 privileged 或没有 enforce 标签，应按保存的配置恢复，必要时删除标签并确认集群默认策略。回滚后要同时检查命名空间标签、GitOps 期望状态和控制器事件，仅看到标签恢复不等于业务恢复，副本补齐和探针健康才是有效信号。

集群升级完成后，建议把 PSS 版本核对纳入常规维护清单：定期复核例外项、审计覆盖和标签漂移，并在每次升级前以目标版本重新运行违规清单。策略版本固定后，升级的准入行为才可预期，排障时也能把“策略语义变化”从“配置错误”中分离出来。