集群一多，规矩就得写成代码：聊聊 OPA / Gatekeeper / Kyverno 在多集群里的真实用法

作者：Echo_Wish
一个被“这个集群怎么又不一样了”逼疯过的运维人

一、多集群最怕的不是多，是“各干各的”

先问你一个问题，你一定有共鸣：

同样是 Kubernetes，
为什么 A 集群能跑，B 集群直接被打回？

我见过太多现场：

• 这个集群允许 latest 镜像
• 那个集群强制 resource limit
• 测试集群能用特权容器
• 生产集群一上来就炸

于是最后变成一句话总结：

K8s 是统一的，但“人心”是散的

当集群只有一个时，靠口头规范 + Wiki + 运维自觉还能勉强维持；
一旦到了多集群，靠人记规则，必死。

这就是 Policy as Code 出现的背景。

二、什么是 Policy as Code？别被名词吓住

我用一句大白话解释：

把“不能做什么、必须怎么做”，交给系统，而不是靠人盯

以前是：

• 文档写一堆
• 群里喊一嗓子
• 出事了再复盘

现在是：

• YAML 一提交
• API Server 直接拦
• 想违规？门都没有

在 Kubernetes 里，这个“拦”的位置，就是 Admission Controller。

三、OPA / Gatekeeper / Kyverno，别一上来就选，先搞清楚定位

1️⃣ OPA（Open Policy Agent）——底层发动机

OPA 是什么？

• 一个通用策略引擎
• 使用 Rego 语言
• 不只 Kubernetes 能用

它很强，但也很“原始”。

package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  not input.request.object.spec.containers[_].resources.limits
  msg := "容器必须设置 resources.limits"
}

👉 我的真实感受：

OPA 很强，但直接用 OPA 写 K8s 策略，心智成本不低

2️⃣ Gatekeeper —— OPA 的 K8s 官方形态

Gatekeeper = OPA + K8s 友好封装

优点很明显：

• CRD 形式管理策略
• 和 K8s 生态融合好
• 适合做强约束（硬门槛）

一个典型例子：
禁止使用 latest 镜像

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowLatestTag
metadata:
  name: no-latest-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

👉 Gatekeeper 给我的感觉是：

像“交警”，只负责拦违规，不负责教你怎么开车

3️⃣ Kyverno —— 为 Kubernetes 而生的策略工具

Kyverno 的一句官方口号我很认同：

Policy as Code, but YAML-first

你不需要 Rego，只写 YAML。

比如：
自动给所有 Pod 加 resource limit

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-resource-limits
spec:
  rules:
    - name: set-default-limits
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                resources:
                  limits:
                    cpu: "500m"
                    memory: "512Mi"

👉 我个人的评价很直接：

Kyverno 更像“运维友好型工具”

四、多集群场景下，Policy as Code 真正的痛点在哪？

很多文章只讲“能不能做”，
但多集群真正的难点是：

1️⃣ 策略怎么统一？

你一定会遇到：

• 测试集群宽松
• 预发集群中等
• 生产集群最严

如果你每个集群一套策略：

恭喜你，维护成本直接爆炸

我的建议是：

• 一份策略代码
• 通过参数 / label 控制生效范围

match:
  resources:
    namespaces:
      - prod-*

2️⃣ 策略升级怎么不“误伤”？

策略不是写完就完了，
策略本身也是代码，有 bug。

我踩过最狠的一个坑是：

策略上线 → 所有 Deployment 发布失败

解决方案只有一个：

👉 策略也要走灰度

• 先 audit（只记录不拦）
• 再 enforce（强制执行）

Gatekeeper / Kyverno 都支持。

3️⃣ 多集群下的策略分发问题

现实世界里：

• 10 个集群
• 3 套环境
• N 套业务

你不可能手工 apply。

我的实践经验是：

Policy as Code + GitOps 是绝配

• 策略进 Git
• Argo CD / Flux 统一下发
• 集群只是执行者

五、我心目中“成熟”的多集群策略体系长这样

给你一个真实可落地的参考模型：

policy-repo/
├── base/
│   ├── no-privileged.yaml
│   ├── require-labels.yaml
├── env/
│   ├── prod/
│   ├── staging/
│   └── test/
├── overlays/
│   ├── finance/
│   └── core-service/

核心思想就一句话：

策略像代码一样分层、复用、可演进

六、说点不那么“官方”的真心话

写到这，我想说点心里话。

Policy as Code 不是为了：

• 为难开发
• 显得运维很牛
• 堆工具

它真正解决的是一个老问题：

当规模上来后，如何用系统对抗人的不确定性

如果你现在还在靠：

• 群公告
• 文档约定
• 事后追责

那不是你不努力，
而是工具已经该升级了。

七、写在最后

我越来越坚信一件事：

多集群不是技术问题，是治理问题

而 Policy as Code，
就是运维在规模化时代，
为自己争取“可控性”的最后一道防线。

如果你问我一句建议，我会说：

• 集群 < 3：Kyverno 起步
• 多环境多集群：Gatekeeper + GitOps
• 想做统一治理：OPA 作为底层能力