Kubernetes 生产化治理如何把策略、发布和回滚证据串起来

在 Kubernetes 生产环境里，最容易断掉的不是某一条策略，而是“为什么允许发布、发布了什么、出了问题回到了哪里”分别躺在不同系统里。真正可追溯的治理链，可以先固定四类证据：准入策略、发布对象、运行观察、回滚审计，再用服务名、环境名和 release-id 把它们串起来。

官方地址：https://kubernetes.io/

推荐把治理拆成“准入负责判断、对象负责关联、审计负责留痕、回滚负责恢复”四层。这样既能解释一次发布，也能在回滚后复盘当时的依据，而不是只留下一个“已经恢复”的口头结论。

先把治理证据拆成四层

我在设计发布流程时，会先问四个问题：请求有没有经过明确策略？这次发布对应哪个服务和环境？运行异常由什么观测确认？回滚到底回到了哪个修订？四个问题分别对应四种证据，少一层就会出现“能操作、不能解释”的空档。

只靠 CI 记录，优点是接入快，但集群内的人工变更不一定能回链；只靠 Kubernetes 对象，信息贴近现场，却可能缺少审批和业务批次；把策略、对象标签、审计事件与回滚记录组合起来，成本更高，但查询路径最清楚。小团队可以先统一关联键，再逐步加入准入和审计。

策略层：准入规则要能说明为什么拦截

Kubernetes 的 ValidatingAdmissionPolicy 使用 CEL 描述校验逻辑，Policy 定义规则，Binding 负责把规则绑定到资源范围，也可以配合参数资源。下面的示例只要求生产 Deployment 带有责任归属标签，重点是展示“规则”和“作用范围”分离的结构：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: production-owner-label
spec:
  failurePolicy: Fail # 中文注释：策略配置或执行出错时拒绝请求，避免静默放行
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "has(object.metadata.labels) && 'app.kubernetes.io/owner' in object.metadata.labels"
      message: "生产 Deployment 必须声明 app.kubernetes.io/owner"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: production-owner-label-binding
spec:
  policyName: production-owner-label
  validationActions:
    - Deny # 中文注释：校验失败时拒绝创建或更新，而不是只给提示
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production

这里有两个容易混淆的边界：failurePolicy 处理策略本身的错误，validationActions 决定校验不通过时是拒绝、审计还是警告。生产环境不应一上来就把所有规则设成强制拒绝，建议先从少数高价值字段开始，确认误报和例外路径后再扩大范围。

发布层：让对象本身成为发布单据

标签适合筛选和聚合，注解适合保存较长的非标识元数据。可以在 Deployment 的模板和对象元数据中同时保留稳定身份与本次发布信息：

metadata:
  labels:
    app.kubernetes.io/name: checkout
    app.kubernetes.io/instance: production
    app.kubernetes.io/managed-by: release-pipeline
  annotations:
    release.example.com/id: rel-20260915-042
    release.example.com/commit: 7f3c2ab
    release.example.com/change: "调整库存超时处理"
spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/name: checkout
        app.kubernetes.io/instance: production

关联键要稳定、短小、可复制。不要把整份变更单塞进注解，也不要把提交号当成唯一的服务身份。一个实用的查询起点是：

# 中文注释：先按服务和环境筛选，再查看镜像与发布关联键
kubectl get deploy -n prod \
  -l app.kubernetes.io/name=checkout,app.kubernetes.io/instance=production \
  -o custom-columns=NAME:.metadata.name,IMAGE:.spec.template.spec.containers[0].image,RELEASE:.metadata.annotations.release.example.com/id

# 中文注释：查看 Deployment 的修订摘要，确认发布是否触发了新 revision
kubectl rollout history deployment/checkout -n prod

官方语义里，标签用于选择对象，注解不参与选择；因此前者放服务、环境等稳定维度，后者放 release-id、提交号和变更摘要，查询就不会把两种含义混在一起。

回滚层：把动作和结果记在一起

Deployment 默认保留滚动发布历史，只有 Pod 模板发生变化时才会产生新的 revision，单纯扩缩容不会产生新修订。回滚时不要只执行一条命令，还要把触发原因、目标 revision、操作者和恢复后的观察结果写入发布系统或审计记录。

# 中文注释：先列出历史，确认目标修订，再执行回退
kubectl rollout history deployment/checkout -n prod
kubectl rollout undo deployment/checkout --to-revision=12 -n prod

# 中文注释：等待控制器完成回滚，避免把“命令已提交”误当成“服务已恢复"
kubectl rollout status deployment/checkout -n prod --timeout=120s

Kubernetes 审计可以记录 API 请求的时间顺序、发起者、目标对象和来源，但审计记录本身不等于业务结论。发布系统仍要把审计事件与 release-id 对照起来，再补上指标、探针或错误率观察，才能回答“回滚后是否真的恢复”。

落地时最容易忽略的两个问题

第一，不要把所有治理都做成阻断策略。策略表达不清、例外没有期限、故障时没有恢复路径，强制拒绝反而会放大发布风险。第二，不要把“有 revision”当成“有完整证据”。revision 只能说明 Pod 模板变化过，仍需用 release-id、审计主体和运行观察把它解释成一次完整发布。

相关问题

只记录 Git 提交号够不够？ 不够。提交号能指向源代码版本，但不能单独说明哪个环境实际接受了对象、谁触发了变更以及回滚后观察到了什么。

策略应该先用警告还是直接拒绝？ 对高风险字段可以直接拒绝；对新规则或例外较多的场景先采用审计/警告，收集误报后再收紧。关键是把策略模式和上线阶段一并记录。

参考资料

• Kubernetes Validating Admission Policy
• Kubernetes Deployments
• Kubernetes Auditing
• Kubernetes Annotations