PSA策略版本固定为何重要?

在 Kubernetes 集群里，PSA 真正容易出问题的时刻，往往不是开启 enforce 的那一天，而是几个月后的一次常规集群升级。原本稳定的命名空间突然开始拒绝 Pod 创建，控制器事件里反复出现 FailedCreate，而团队并没有改过任何清单。排查到最后，问题常常出在一个当时被忽略的细节：策略版本标签没有固定。

版本标签决定了“策略是什么”

PSA 通过命名空间上的标签生效，每个模式都可以单独附带版本。enforce、audit、warn 三者各自独立，也就各自带有版本语义。省略版本标签并不会让策略停留在某个固定状态，而是让该模式跟随集群的默认版本——集群升级，默认版本随之变化，准入判断的依据也就跟着变了。

这正是风险来源。Pod Security Standards 的层级定义并非一成不变，restricted 这类严格层级会随着 Kubernetes 版本演进而补充要求。对使用者来说，字段没改、镜像没改、清单没改，但同一份 Pod 规格在新版本下的判定结果可能从合规变成违规。这种变化不会以显式的配置变更形式出现，它藏在升级过程里，极难在事后归因。

固定版本的直接价值，是把“集群升级”和“策略变更”这两件事解耦。升级只改变控制面，准入判断仍按团队确认过的版本执行，发布行为可预期、可复现。回滚也因此更干净：当 enforce 出问题需要降级时，不必同时怀疑版本漂移是不是另一层变量。

固定不等于放任

但把版本钉死之后，问题只是被推迟，并没有被解决。固定的版本迟早要跟进，否则命名空间会长期停留在旧语义上，与集群整体安全基线脱节，也让后续一次性跨多个版本的调整变得更难评估。

比较稳妥的做法，是给版本升级单独设一条路径，而不是混在集群升级里顺手完成。可以利用三个模式的独立性：enforce 保持在已确认的版本上，warn 或 audit 指向更新的版本，让不合规项以告警和审计记录的形式先暴露出来。观察一个完整的业务周期，等新版本要求下的差距收敛得差不多，再推动 enforce 跟进。这样版本变更就变成一次有观测数据支撑的独立动作，而不是升级带来的意外。

配套还需要两件事。一是把版本标签纳入配置管理，和其他清单一样有归属、有变更记录，避免有人临时改掉再没人记得。二是明确责任节奏，比如跟随集群大版本做一次评估，而不是等出问题才回头看。

PSA 的版本标签看起来只是一个可选后缀，实际上它决定了这套策略是“跟着集群漂移的隐式规则”，还是“团队自己维护的显式契约”。前者省事，代价是把不确定性留给了未来的某次升级；后者多一道维护成本，换来的是准入行为始终在掌控之中。