不部署 Webhook 也能改 Pod：Kubernetes Mutating Admission Policy 上手指南

不部署 Webhook 也能改 PodKubernetes Mutating Admission Policy 上手指南【免费下载链接】websiteKubernetes website and documentation repo:项目地址: https://gitcode.com/GitHub_Trending/webs/website一个 Sidecar 注入需求的隐藏成本你想给生产环境的关键 Pod 自动挂上审计日志 sidecar。 老办法写一个 Mutating Webhook 服务、申请 TLS 证书、暴露 Service 端点它一超时你就得值班。 Kubernetes 1.30 带来 Mutating Admission Policy修改规则用 YAML 声明API Server 在进程内直接改资源。 不用部署任何额外服务说白了就是把 sidecar 注入从 200 行 Go 压成 20 行 YAML。一图看懂请求链路从 API Server 到突变执行策略不是一个独立服务而是 API Server 加载求值的集群资源。 请求进入准入链后在进程内完成匹配和修改没有跨网络调用。图里两个 match 字段各管一层。 matchConstraints 决定拦哪些请求哪个 API 组、哪种操作、哪类资源namespaceSelector 再按命名空间收窄。 matchConditions 放 CEL 表达式做更细的条件判断。 mutations 才是真正的修改指令API Server 逐条求值把结果写回原对象。 如果不同命名空间要注入不同镜像用 paramKind 指定参数资源ConfigMap 或 CRD 都行。API Server 按命名空间取参数填进表达式一套策略模板配多组参数。那修改指令到底怎么写两种改法怎么选字段级用 JSON Patch整块用 ApplyConfiguration先给结论字段级增删改用 JSON Patch整块结构化覆盖用 ApplyConfiguration。JSON Patch 方式apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: set-log-tier-label spec: matchConstraints: resourceRules: [{apiGroups: [], apiVersions: [v1], operations: [CREATE], resources: [pods]}] mutations: - patchType: JSONPatch jsonPatch: expression: [{op:add,path:/metadata/labels/log.example.com~1tier,value:prod}]这条策略给每个新建 Pod 打上 log.example.com/tier: prod 标签。 路径里的 ~1 是 JSON Patch 对冒号的转义一个 op 一行 JSON长 patch 也一眼能读完。 expression 本质是字符串由 API Server 按 CEL 解析操作符不用背全add、replace、remove 覆盖大部分日常场景。ApplyConfiguration 方式apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: inject-audit-sidecar spec: matchConstraints: resourceRules: [{apiGroups: [], apiVersions: [v1], operations: [CREATE], resources: [pods]}] mutations: - patchType: ApplyConfiguration applyConfiguration: expression: | Object{spec: Object.spec{initContainers: [Object.spec.initContainers{name: audit-log, image: registry.example.com/audit-log:v2.1}]}}这条策略用服务器端 apply 的合并语义往 spec.initContainers 追加一个 audit-log initContainer。 Object{...} 字面量是 CEL 配置片段的写法只写要改的字段其余保持原样。 整块结构化修改用它比逐个列 op 稳不怕数组索引错位。kubectl apply 一条策略验证它真的生效这里只展开一个场景给 env: prod 命名空间里带 tier: critical 标签的 Pod 注入 audit-log sidecar。 策略、条件、修改全在同一个 YAML 里apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: inject-audit-log-sidecar spec: matchConstraints: resourceRules: [{apiGroups: [], apiVersions: [v1], operations: [CREATE], resources: [pods]}] namespaceSelector: {matchExpressions: [{key: env, operator: In, values: [prod]}]} matchConditions: - name: critical-tier-pod expression: has(object.metadata.labels) object.metadata.labels[tier] critical - name: sidecar-absent expression: !has(object.spec.initContainers) || !object.spec.initContainers.exists(c, c.name audit-log) mutations: - patchType: ApplyConfiguration applyConfiguration: expression: | Object{spec: Object.spec{initContainers: [Object.spec.initContainers{name: audit-log, image: registry.example.com/audit-log:v2.1, args: [--sink, stdout]}]}}1.30 里该特性还是 alphaAPI Server 必须打开 MutatingAdmissionPolicytrue 特性门才会真正求值否则资源躺在 etcd 里不生效。 apply 之后两条命令验证kubectl get mutatingadmissionpolicies kubectl describe mutatingadmissionpolicy inject-audit-log-sidecar第一条列出集群所有策略第二条看单条策略的详情和条件状态。 ReadyTrue 且 message 没有报错说明表达式语法通过策略开始拦截请求。 想确认效果就在 prod 命名空间建一个带 tier: critical 标签的 Podkubectl get pod -o yaml 里能看到 audit-log initContainer 被加上。 完整字段定义见官方 MutatingAdmissionPolicy 文档。⚠️ 踩坑速查从现象到根因生产上实际会踩的坑基本是这四类object.metadata.labels[tier] 报 no-such-key 错误不少 Pod 压根没有 labels 字段CEL 对缺失字段直接取索引会报错而不是返回 nil。用 has(object.metadata.labels) 先做保护上面例子里的第一条条件就是这么写的。failurePolicy: Fail 时整个请求被拒通常是 mutation 表达式有类型错误或 JSON Patch 的 path 写错。dev 环境先把策略改成 Ignore突变失败也不挡 Pod 创建边观察边修表达式。kubectl get 能看到策略但请求从不被修改1.30 的 MutatingAdmissionPolicy 特性门默认关闭API Server 没开启就不会执行。给 kube-apiserver 加 --feature-gatesMutatingAdmissionPolicytrue 后重启控制面门控细节见 feature gate 参考。两条策略改同一个字段结果不确定matchConstraints 重叠、同一条请求被两条策略命中patch 应用顺序未定义。按字段或标签拆分职责确实需要顺序时用 reinvocationPolicy 让前一条的结果可被重新求值。什么时候还是得写 WebhookMutating Admission Policy 不是 Webhook 的替代品。 表达式能力受 CEL 限制数据源受限于集群内资源。 要查外部系统才能决定改不改、改成什么样或判断涉及多步业务逻辑Webhook 仍然是唯一答案。判断维度Mutating Admission Policy自建 Mutating Webhook外部数据依赖只能用集群内资源paramKind可调任意外部 API复杂业务逻辑受 CEL 表达式能力限制任意程序逻辑现有基础设施需 1.30 集群并打开特性门可沿用已有准入设施务实路线能用 YAML 表达的修改全部迁到 Mutating Admission PolicyWebhook 只留给必须外呼的场景。 下一步在 dev 集群先 apply 第 4 节的 YAMLkubectl describe 看到 ReadyTrue 就算跑通了。【免费下载链接】websiteKubernetes website and documentation repo:项目地址: https://gitcode.com/GitHub_Trending/webs/website创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考