kyverno策略是纯yaml/json定义的crd，非go代码；正确做法是用go工具链模板化、批量管理或ci集成策略yaml，并通过kyverno apply本地验证，而非在go中硬编码逻辑。
Kyverno 的 Policy 不是用 Go 写的，别在 main.go 里硬塞策略逻辑
Kyverno 的策略（ClusterPolicy 或 Policy）本质是 Kubernetes 自定义资源（CRD），纯 YAML/JSON 定义，不是 Go 代码。你无法、也不该在 Go 程序里用 if 或 func 去“编写” Kyverno 策略——它不编译、不运行在 Go 进程里，而是由 Kyverno controller 解析并执行。
常见错误现象：
• 把策略逻辑写进 Go 项目，期待它自动生效
• 用 client-go 手动构造 unstructured.Unstructured 去“生成” Policy 并 apply，却忽略验证时机和字段语义
• 在 CI/CD 脚本里拼接 YAML 字符串，导致 validate.rules 缩进错乱或 matchConditions 类型误写成字符串而非数组
- 真正要做的：用 Go 工具链辅助生成/校验 Policy YAML（比如用
gomplate渲染模板，或用kyverno applyCLI 预检） - Policy 中所有
match、validate、mutate字段都必须严格遵循 Kyverno Schema，比如validate.deny.message是字符串，validate.pattern是嵌套结构，不能靠 Go struct tag “猜”映射 - Kyverno v1.9+ 要求
spec.rules[].name必须唯一且非空，Go 生成时若用循环拼接容易漏掉命名，直接报ValidationError(Policy.spec.rules[0].name): missing required field "name"
kyverno apply 是本地验证 Policy 的唯一可靠方式，别信 IDE 插件或 YAML LSP
Kyverno 的策略逻辑有强上下文依赖：比如 request.object 是否含某字段、serviceAccountName 是否在命名空间中存在、imagePullSecrets 是否被引用……这些只有 kyverno apply 在模拟 admission request 时才能真实触发校验。
使用场景：
• GitOps 流水线中，在 kubectl apply 前跑 kyverno apply policy.yaml --resource pod.yaml
• 本地开发时，用真实 Pod/Deployment YAML 测试 mutate.patchStrategicMerge 行为
立即学习“go语言免费学习笔记（深入）”；
-
kyverno apply默认不连接集群，纯离线运行，但会加载本地.kube/config中的 context 用于解析clusterRoles等引用 —— 如果你用kubectx kind-kind切换上下文后没 reload，它可能读错 API 版本 - 错误信息如
failed to resolve variable: request.object.metadata.labels['app']，往往不是 Policy 写错，而是测试用的--resourceYAML 根本没带metadata.labels字段 - 对
generate规则，kyverno apply不执行生成动作（因不操作 etcd），只检查语法；必须上真实集群 +kyverno test或观察日志确认是否触发
用 Go 处理 Kyverno Policy 的典型场景只有三个：模板化、批量管理、CI 集成
你在 Go 里真正需要动手写的，不是 Policy 本身，而是围绕它的工具链：
-
模板化：用
text/template或sprig渲染多环境 Policy（比如 dev/staging/prod 的imageRegistry替换），注意{{ .Registry }}必须是字符串，不能是 map 否则 YAML marshal 失败 -
批量管理：用
client-go列出所有ClusterPolicy，按creationTimestamp排序并过滤过期策略（Kyverno 不提供 TTL 字段，得自己加metadata.annotations["policy.kyverno.io/expiry"]） -
CI 集成：在 GitHub Action 中调
kyverno apply并捕获 exit code；若返回 1，说明策略语法或逻辑错误，但注意：exit code 1 也可能是--resource文件路径不存在，得先test -f检查
性能影响很小——这些 Go 程序只跑在 CI 或本地，不参与集群实时决策；兼容性上，Kyverno CRD 版本（kyverno.io/v2beta1）与 Go client 的 Scheme 注册需匹配，v1.10+ 推荐用 kyverno/pkg/client/clientset/versioned 而非通用 dynamic client，避免字段缺失。
最常被忽略的点：Policy 的 background 和 failurePolicy 字段直接影响行为一致性
这两个字段不写默认值，但线上行为差异极大：
-
background: true（默认）→ Kyverno 后台扫描存量资源并报告违规，但不会阻断新资源创建；设为false后，仅对新请求做 admission 检查，旧资源永远“隐身” -
failurePolicy: Ignore（默认）→ 策略引擎出错（如变量解析失败、正则超时）时放行资源；改成Fail后，任何策略内部错误都会拒绝请求，适合生产环境防配置漂移 - 修改这两个字段必须
kubectl replace或patch，不能apply—— 因为kubectl apply会把未显式声明的字段重置为默认值，导致background: false突然变回true，后台扫描重新启动，CPU 突增
这事没法靠 Go 程序自动兜底，只能靠 Code Review 卡住 PR，或者用 kyverno validate 插件检查 YAML 是否显式声明了这两个字段。
