validatingwebhookconfiguration 修改 url 后未触发 go 服务，因 kubernetes 不主动重载配置，需手动触发资源变更以重建 tls 连接；须确保 cabundle 与服务证书一致、service dns 匹配 san、私钥权限为 0600，并异步处理通知避免阻塞主流程。
为什么 ValidatingWebhookConfiguration 里改了 URL 却没触发你的 Go 服务
因为 Kubernetes 不会主动轮询或重载 Webhook 配置，改完 clientConfig.service.url 或 clientConfig.caBundle 后，必须手动触发一次资源变更（比如 patch 一个 Pod），K8s 才会重新建立 TLS 握手并校验证书链。常见错误是改完配置就等日志，结果服务压根没被调用——先确认 kubectl get ValidatingWebhookConfiguration your-webhook -o yaml 里的 caBundle 和你 Go 服务实际提供的 CA 是否一致，不一致会导致连接直接被 API Server 拒绝，连 HTTP 层都进不去。
- CA 必须是 base64 编码的 PEM 格式，不是原始证书内容
- Go 服务监听地址必须和
service.name+service.namespace+service.port解析出的 ClusterIP:Port 完全匹配 - API Server 默认超时 30 秒，但若你的
http.Serve没设ReadTimeout/WriteTimeout，长连接可能卡住整个 webhook 链路
AdmissionReview 解析失败：空字段、嵌套结构、版本漂移
K8s 的 AdmissionReview 是动态结构，request.object 和 request.oldObject 的具体类型取决于被操作的资源（如 Pod、Deployment），且不同 K8s 版本中字段名可能变化（例如 v1.22+ 的 status.phase 在旧版可能是 phase）。直接用 json.Unmarshal 到固定 struct 容易 panic 或漏字段。正确做法是先用 runtime.DefaultUnstructuredConverter 转成 unstructured.Unstructured，再按需取值。
- 别写
type Pod struct { ... }然后硬解 —— 资源字段随 K8s 版本松散演进 - 检查
request.kind.group和request.kind.version，决定后续怎么处理，比如apps/v1Deployment 和batch/v1Job 的 spec 结构完全不同 -
request.operation可能是CREATE、UPDATE、DELETE、CONNECT，其中DELETE的request.object为空，别假设它一定有内容
转发通知时怎么避免阻塞 K8s 主流程
Webhook 处理函数必须在 30 秒内返回 AdmissionResponse，否则 API Server 会超时并按 failurePolicy 策略拒绝或忽略。但发 HTTP 通知（比如推到 Slack、写入 Kafka）很可能超时或失败。解决方案是把通知逻辑完全异步化：主流程只做轻量校验和构造通知 payload，然后丢进带缓冲的 channel，由后台 goroutine 消费并重试。不要在 http.HandlerFunc 里直接 http.Post。
- channel 缓冲大小建议 ≥ 100，防止突发流量压爆内存
- 后台 goroutine 必须处理 4xx/5xx 响应，对 400/422 类错误可直接丢弃，对 500/503 应指数退避重试（最多 3 次）
- 别用
context.Background()发通知请求，至少设context.WithTimeout(ctx, 5*time.Second)
证书和 TLS 配置最容易被忽略的三个点
Go 服务跑在集群内，但 K8s API Server 认证它靠的是双向 TLS，而不仅是 Service DNS。很多团队卡在证书环节，不是私钥权限不对，就是证书 SAN 写错。关键不是“能不能连上”，而是“API Server 愿不愿意信你”。
立即学习“go语言免费学习笔记（深入）”；
- 证书的
Subject Alternative Name必须包含your-webhook.your-namespace.svc（Service FQDN），不能只写your-webhook - 私钥文件权限必须是
0600，Go 的tls.Listen会静默失败（不报错但连接被拒） - 如果用
cert-manager自动签发，确保Issuer的ca字段指向同一个 CA，否则caBundle和实际证书不匹配
真正难的不是写通逻辑，是让 K8s API Server 和你的 Go 进程在 TLS 握手那一刻，对证书、域名、时间、CA 都达成共识。中间任何一个环节差毫秒、少一个 SAN、错一位 base64，就静默失败。
