题干与适用场景
平台团队要把多个命名空间迁移到 Kubernetes Pod Security Standards 的 restricted 级别。现有工作负载来源复杂，既有生产服务也有临时构建任务。请设计发现、整改、例外、切换和回滚流程。
面试官考察点
- 是否理解
enforce、audit、warn的不同副作用。 - 是否能把命名空间、工作负载和例外纳入治理边界。
- 是否用观测数据驱动整改，而不是直接全局拒绝。
- 是否考虑版本固定、审计留痕和紧急回滚。
回答前需要澄清的问题
- 集群和命名空间的 Kubernetes 版本、租户边界与发布工具是什么？
- 目标是
baseline还是restricted，是否允许按命名空间分级？ - 哪些工作负载需要特权、hostPath 或主机网络？
- 回滚是暂时降低策略，还是保留旧集群承接流量？
30 秒回答框架
先按命名空间启用 audit 与 warn，收集违规对象并让提交者看到修复提示；不要直接全局 enforce。按风险和业务重要性分批整改，使用固定的策略版本，所有例外必须有负责人、原因、期限和替代方案。小范围试运行通过后切到 enforce，持续观察拒绝率与发布成功率；紧急回滚只降低受影响命名空间的策略并保留审计记录。
分步骤深入解答
1. 建立资产和策略基线
盘点命名空间、Pod 模板、控制器和发布来源，按生产、共享基础设施、开发和临时任务分组。为每组选择目标级别与版本，记录允许的例外，不把未标注命名空间当成“安全”。
2. 先观察再阻断
先设置 audit 记录违规，再设置同级别 warn 给客户端反馈。聚合审计事件，按规则、团队和镜像归因，形成可排序的整改队列。这样能在不阻断现有流量的情况下暴露风险。
metadata:
labels:
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted3. 修复工作负载
优先移除不必要的特权、hostNetwork、hostPID、hostPath 和可写 root filesystem；补齐非 root、seccomp 与 capability 限制。将策略检查放进 CI，在提交阶段失败并给出具体字段，而不是等集群拒绝。
4. 治理例外
例外只按命名空间或明确的受控入口发放，记录业务影响、负责人、到期日和补偿控制。Admission exemption 不是永久白名单；每次续期都要重新审查，禁止把所有系统命名空间无条件豁免。
5. 分批切换 enforce
先在低风险命名空间执行 enforce，观察拒绝率、发布失败、重启和租户投诉，再扩大范围。策略版本固定，升级版本先在 warn/audit 中预演，避免 latest 的隐性行为变化。
6. 回滚与验证
发布控制器要能暂停并恢复旧模板。若核心服务受阻，临时把单个命名空间降回较宽级别，同时保留 audit 和事件。验证应覆盖新建 Pod、Deployment 模板、滚动升级、Job、例外到期和策略版本升级。
高质量示范回答
我会先盘点命名空间和工作负载，固定目标策略版本，再以 audit 加同级 warn 收集违规并推动修复。CI 阶段提前检查安全上下文，例外必须有负责人、原因和到期日。低风险命名空间先切 enforce，逐步扩大并监控拒绝率、发布成功率和业务错误。版本升级先用 warn/audit 预演。出现阻断时只回滚受影响命名空间的策略，保留审计记录并修复根因，不做全局永久放宽。
常见错误
- 直接全局
enforce→ 大量发布同时失败 → 先 audit/warn 再分批切换。 - 把未标注命名空间视为安全 → 策略覆盖出现盲区 → 明确标注并纳入盘点。
- 用永久豁免解决所有失败 → 风险长期隐藏 → 例外必须限时和可审计。
- 只在集群中发现违规 → 修复反馈太晚 → 把检查前移到 CI 和模板评审。
- 使用
latest却不做预演 → 版本升级产生意外拒绝 → 固定版本并提前观测。
追问及应对
warn 和 audit 都不阻断，为什么需要同时启用？
warn 让提交客户端立即看到反馈，audit 把违规写入审计记录。两者分别服务开发修复和平台度量，不能互相替代。
例外应该按 Pod 还是按命名空间？
优先使用可治理的命名空间边界，并限制受控入口；按单个 Pod 放行容易被复制和绕过。例外仍需负责人、期限和补偿控制。
如何证明迁移没有降低可用性？
用分批切换前后的拒绝率、发布成功率、重启、SLO 和租户错误对比，并对滚动升级和 Job 等非长驻工作负载做回放。