admissionregistration.k8s.io/v1 的 ValidatingWebhookConfiguration 不能直接做名单匹配，因其仅转发原始 AdmissionReview，黑白名单逻辑需服务端自行实现；rules 配置错误（如 apiGroups、resources、operations 不匹配）会导致请求未到达服务；须用 client-go 的 scheme.Decode 安全反序列化；名单应内存加载+定期 reload；服务需超时控制、fail-open/fail-closed 策略、TLS 证书合规及 HTTP 超时配置。
为什么 admissionregistration.k8s.io/v1 的 ValidatingWebhookConfiguration 不能直接做“名单匹配”
因为 Kubernetes 准入 Webhook 本身不解析或过滤资源字段，它只把原始 AdmissionReview 对象（含 request.object 和 request.oldObject）转发给你的服务。黑白名单逻辑必须自己实现，不是靠配置项开关。
- 常见错误现象：
ValidatingWebhookConfiguration里填了rules，但发现 Pod 被拒了，日志却显示你的服务根本没收到请求 —— 实际是规则没匹配上 API 组/版本/资源，导致请求压根没进你 webhook - 检查重点：确保
rules[].apiGroups包含""（核心组）、"apps"、"batch"等实际要拦截的组；rules[].resources写成["pods"]而不是["pod"]；rules[].operations明确包含"CREATE"或"UPDATE" - 兼容性影响：K8s v1.16+ 强制要求使用
v1版本的 webhook 配置，旧的v1beta1会被拒绝加载，且不报明确错误，容易卡在 “webhook 不生效” 却查不到原因
Go 里怎么安全反序列化 AdmissionReview 并提取资源名和命名空间
别直接用 json.Unmarshal 到裸 map[string]interface{} —— 字段嵌套深、类型不稳、易 panic。Kubernetes 官方 client-go 提供了 scheme + runtime.Decode 的标准路径。
- 实操建议：用
admissionv1.SchemeGroupVersion注册的 scheme 初始化decoder，调用Decode(body, nil, &review)，其中review是*admissionv1.AdmissionReview - 关键字段提取顺序：
review.Request.Kind.Kind→ 资源类型（如"Pod"）；review.Request.Namespace→ 命名空间；review.Request.Name→ 资源名（仅对 namespaced 资源在 UPDATE/DELETE 时有效）；review.Request.Object.Raw→ 原始 JSON，需二次解码到具体结构体（如*corev1.Pod） - 容易踩的坑：
review.Request.Object.Raw是未解码的字节流，直接 string() 可能含不可见字符；若资源带finalizers或ownerReferences，字段名大小写/嵌套层级稍有偏差就会解码失败，建议用json.Unmarshal+json.RawMessage做懒解析
黑名单 vs 白名单：判断逻辑写在哪一层更可控
名单数据不该硬编码在 Go 代码里，也不该每次请求都去读文件或查 DB。最稳的方式是启动时加载进内存 map，再配合定期 reload（比如监听 ConfigMap 变更），但 reload 本身有竞态风险。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐结构：用
sync.RWMutex包裹一个map[string]map[string]bool，第一层 key 是namespace，第二层是name（或name+kind组合），值为是否允许（白名单 true / 黑名单 false） - 性能影响：单次准入请求内做两次 map 查找（ns + name），耗时在微秒级，远低于网络 IO；但如果名单条目超万级，建议改用前缀树或分片 map，避免锁争用
- 场景差异：白名单默认拒绝所有，只放行名单内资源；黑名单默认放行，只拦截名单内资源。两者语义不同，
if !isAllowed的条件位置不能反 —— 错一次，整个集群就可能被锁死
如何让 webhook 服务在 K8s 里可靠运行而不拖慢 API Server
API Server 对 webhook 响应延迟极其敏感：超过 30 秒会超时断连，连续失败 5 次会临时禁用该 webhook。你的 Go 服务必须轻量、无阻塞、可快速失败。
立即学习“go语言免费学习笔记（深入）”；
- 必须加的防护：
context.WithTimeout(r.Context(), 2*time.Second)包裹所有业务逻辑，超时直接返回Allowed: true（fail-open）或false（fail-closed），按策略选；绝不能让日志写入、HTTP 外部调用、复杂正则匹配卡住主线程 - 证书处理要点：K8s 要求 webhook server 使用 TLS，且证书 Subject.CommonName 必须是 service DNS 名（如
my-webhook.my-ns.svc），不能是 IP 或通配符；自签证书需 base64 后填入caBundle字段，否则 API Server 连接直接拒绝 - 容易被忽略的点：Go HTTP server 默认没有设置
ReadTimeout和WriteTimeout，一旦客户端（即 kube-apiserver）异常断连，goroutine 就会堆积。务必显式配置http.Server{ReadTimeout: 5 * time.Second, WriteTimeout: 5 * time.Second}
