最可控、最贴近生产的方式是用kubebuilder生成骨架并手动补全证书和AdmissionReview处理逻辑；失败主因是准入链路不通，包括证书缺失、CRD未安装、RBAC权限不足、Secret未挂载及rules配置错误。
直接上结论：用 kubebuilder 生成骨架 + 手动补全证书和 AdmissionReview 处理逻辑，是最可控、最贴近生产的方式。别自己从零写 HTTP server，也别跳过证书校验环节——90% 的失败都卡在这两步。
为什么 kubebuilder init 后跑不起来
新项目执行 make run 卡住或报错，不是代码问题，而是准入链路没通：
-
ENABLE_WEBHOOKS=true（默认）时，manager 会尝试启动 webhook server，但没证书就 panic；本地调试请先加ENABLE_WEBHOOKS=false - 没运行
make install→ CRD 没装进集群 →ctrl.NewWebhookManagedBy(mgr)注册时找不到对应资源类型，静默失败 - 没运行
make deploy→ RBAC 权限缺失 → webhook server 启动后无法读取ValidatingWebhookConfiguration或写日志，manager 日志只显示failed to acquire lease - 证书 Secret 没挂载，或
tls.crt/tls.key路径写死在代码里（应通过环境变量或 flag 传入）
证书和 TLS 配置必须手动干预
Kubernetes 强制要求 webhook endpoint 使用 HTTPS，且 kube-apiserver 会严格校验证书的 subjectAltName。本地自签或 cfssl 生成时，必须包含：
- DNS:
my-webhook.my-namespace.svc - DNS:
my-webhook.my-namespace.svc.cluster.local - IP:
<service-cluster-ip>（部署后查kubectl get svc补上）
服务启动必须用 tls.Listen("tcp", ":443", tlsConfig)，不能监听 :8080 再套 nginx 或 ingress——kube-apiserver 不走代理，只直连 Service ClusterIP。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
AdmissionReview 处理函数不能省略关键字段
Go SDK 不提供自动封装，你得手动生成响应。漏掉任意一项，apiserver 就返回 500 或忽略你的 webhook：
-
Response.UID必须等于Request.UID，否则 apiserver 认为响应不匹配 -
Response.Allowed是*bool类型，不能直接赋true，得写allowed := true; Response.Allowed = &allowed - Mutating Webhook 必须设
Response.Patch（base64 编码的 JSON patch）和Response.PatchType = "JSONPatch" - 不要在 handler 里做耗时操作（如调外部 API），超时默认 30s，超时即视为失败（
failurePolicy: Fail时直接拒绝请求）
rules 字段配错 = webhook 彻底不触发
这是最隐蔽的问题：日志完全安静，你以为代码没跑，其实是配置没命中。重点检查：
-
apiGroups填的是 group 名，不是 API path：[""]对应 core v1（Pod/Service），["apps"]对应 Deployment，["myapp.example.com"]对应 CRD -
resources必须是小写复数：["pods"]✅，["Pod"]❌ -
operations区分大小写：["CREATE"]✅，["create"]❌ -
scope设为"*"才能覆盖所有命名空间；想限定 namespace，得用namespaceSelector.matchLabels，不是namespaces字段（该字段不存在）
真正难的从来不是写逻辑，而是让 apiserver 稳定、可预测地把请求打到你手里——证书、rules、AdmissionReview 结构这三处，任一出错都会导致“看似正常启动，实则完全失联”。
