集群一多，规矩就得写成代码：聊聊 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 作为底层能力
