上一篇【第70篇】K8s垃圾回收机制——“打扫卫生“的艺术级联删除不留孤儿下一篇【第72篇】CRD详解——让你的K8s认识新物种摘要第052篇讲过API Server的第三道防线是Admission Control内置插件PodSecurity、ResourceQuota等能拦能改。但如果你想要自定义规则呢比如所有进prod的Pod必须带environmentprod标签、“所有Pod自动加上一个日志采集Sidecar”、“禁止用latest镜像标签”。这就需要Admission Webhook——它能把API Server收到的请求转发给你的HTTP服务让你动态改写Mutating或拒绝Validating。这是K8s扩展性最强的机制之一Istio的Sidecar自动注入、各大安全工具都靠它。这篇文章讲清两种Webhook的区别、请求/响应格式、证书配置并实战写一个注入Sidecar的MutatingWebhook。一、两种Webhook1.1 Mutating vs Validating【Admission Webhook 两兄弟】 ┌──────────────────────────────────────────────┐ │ MutatingWebhook (变异/改写) —— 动手脚的 │ │ • 可以修改请求内容 │ │ • 典型: 注入Sidecar(Istio)、加默认label、 │ │ 补imagePullSecrets、填默认值 │ │ • 先跑(在Validating之前) │ └──────────────────────────────────────────────┘ │ (改完之后) ▼ ┌──────────────────────────────────────────────┐ │ ValidatingWebhook (校验) —— 把关的 │ │ • 只能放行或拒绝不能改 │ │ • 典型: 拒绝latest标签、拒绝特权容器、 │ │ 强制资源限制、检查镜像来源 │ │ • 后跑(在Mutating之后) │ └──────────────────────────────────────────────┘ 顺序: Mutating全部跑完 → Validating全部跑 任一Validating拒绝 → 整个请求被拒要点核心区别——Mutating能改、Validating不能改只能拒。而且顺序是先Mutating后Validating所以Validating看到的是已经被改过的请求。这保证了先补全、再校验的逻辑比如Mutating注入了SidecarValidating再校验完整性。二、请求和响应格式2.1 数据流【Webhook 的调用过程】 API Server 收到一个创建Pod的请求 │ ▼ 匹配到 MutatingWebhook 规则(比如所有Pod) │ ▼ API Server 把请求序列化成 AdmissionReview 通过 HTTPS POST 给你的Webhook服务 │ ▼ 你的服务处理: • 读取 AdmissionReview.request.object (原始Pod) • 决定: 改写(加sidecar) 或 不动 │ ▼ 返回 AdmissionReview (带 patch 或 allowedtrue) │ ▼ API Server 应用patch(改写Pod) → 继续后续流程2.2 请求/响应结构// API Server 发给你的 AdmissionReview 请求{apiVersion:admission.k8s.io/v1,kind:AdmissionReview,request:{uid:a1b2c3,operation:CREATE,resource:{group:,version:v1,resource:pods},object:{kind:Pod,metadata:{...},spec:{...}},namespace:default}}// 你的服务返回的响应(注入sidecar的例子){apiVersion:admission.k8s.io/v1,kind:AdmissionReview,response:{uid:a1b2c3,allowed:true,patchType:JSONPatch,patch:W3sib3AiOiAiYWRkIiwi...base64...fQ// 注入容器的JSON Patch}}三、配置Webhook3.1 资源定义# MutatingWebhookConfigurationapiVersion:admissionregistration.k8s.io/v1kind:MutatingWebhookConfigurationmetadata:name:sidecar-injectorwebhooks:-name:sidecar.example.com# 匹配规则: 哪些请求转发给我rules:-apiGroups:[]apiVersions:[v1]operations:[CREATE]resources:[pods]# 转发目标(你的服务)clientConfig:service:name:sidecar-injectornamespace:webhook-systempath:/mutatecaBundle:你的CA证书base64# 验证你的服务身份# 失败策略: webhook不可用时怎么办failurePolicy:Fail# Fail拒绝请求 / Ignore放行# 只处理带特定label的Pod(避免无限循环)namespaceSelector:matchLabels:inject-sidecar:true要点配置Webhook时两个易错点(1)caBundle必须正确——API Server用它验证你的Webhook服务身份配错就TLS握手失败(2)failurePolicy——设Fail时如果你的Webhook服务挂了所有匹配的请求都会被拒集群变只进不出生产要权衡用Fail还是Ignore。另外务必用namespaceSelector/objectSelector避免自己注入自己的无限循环。四、实战注入Sidecar的MutatingWebhook4.1 完整思路【自动给Pod注入日志采集Sidecar】 用户创建Pod(没有日志采集器): spec: containers: - name: app image: my-app MutatingWebhook 拦截: → 检测到Pod没log-collector容器 → 生成JSON Patch加一个容器: [{ op: add, path: /spec/containers/-, value: { name: log-collector, image: fluent-bit:1.9, volumeMounts: [...] } }] 返回patch → API Server应用 → 最终Pod变成: containers: [app, log-collector] ← 自动多了采集器4.2 服务端伪代码funcmutate(w http.ResponseWriter,r*http.Request){// 1. 解析AdmissionReviewreview:decodeAdmissionReview(r.Body)pod:decodePod(review.Request.Object.Raw)// 2. 构造patch(注入sidecar)patch:[]Patch{{Op:add,Path:/spec/containers/-,Value:map[string]interface{}{name:log-collector,image:fluent-bit:1.9,}},}patchBytes,_:json.Marshal(patch)// 3. 返回允许 patchresponse:AdmissionReview{Response:AdmissionResponse{UID:review.Request.UID,Allowed:true,Patch:base64.StdEncoding.EncodeToString(patchBytes),PatchType:JSONPatch,},}json.NewEncoder(w).Encode(response)}# 验证: 创建Pod看是否自动加了sidecarkubectl runtest--imagenginx-ninject-sidecartrue kubectl get podtest-ojsonpath{.spec.containers[*].name}# nginx log-collector ← 自动注入了要点这就是Istio/envoy Sidecar自动注入的底层原理——一个MutatingWebhook默默给每个Pod加了一个Envoy容器并配好iptables流量劫持第077篇会展开。你也看到了Webhook不改K8s核心代码纯粹是外部HTTP服务配置就能动态改写任何请求。这种钩子式扩展是K8s强大的根源。下篇讲CRD——让K8s认识全新资源类型。五、和PSP/PSA的关系【Webhook vs 内置准入】 ValidatingWebhook: • 比内置PodSecurity更灵活(你能写任意校验逻辑) • 很多安全工具(如Kyverno/OPA Gatekeeper)基于它 • 可以组合多个webhook形成多道防线 ⚠️ 注意顺序和性能: • 每个Webhook都是一次网络调用 • 太多/太慢的Webhook会拖慢API Server • 谨慎设计failurePolicy本篇小结Admission Webhook是API Server的可插拔安检——把请求转发到你的HTTP服务动态处理。Mutating能改写请求注入Sidecar、补默认值Validating只能放行/拒绝拦latest、禁特权。配置要点caBundle验证身份、failurePolicy控制Webhook挂了怎么办、selector防自循环。Istio的Sidecar自动注入就是MutatingWebhook的经典应用。Webhook不改K8s核心代码纯外部服务配置就能扩展集群行为——这种钩子式扩展是K8s生态繁荣的根。下篇讲CRD——让你的K8s认识全新物种。上一篇【第70篇】K8s垃圾回收机制——“打扫卫生“的艺术级联删除不留孤儿下一篇【第72篇】CRD详解——让你的K8s认识新物种