参考:https://blog.csdn.net/gitblog_00796/article/details/148523806?ops_request_misc=&request_id=&biz_id=102&utm_term=admission%20policy&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-0-148523806.142^v102^pc_search_result_base1&spm=1018.2226.3001.4187

仅做记录

你是否曾经为了在Kubernetes集群中实现自动化的资源修改而不得不编写复杂的准入控制Webhook?传统的Mutating Admission Webhook虽然功能强大,但开发部署复杂、维护成本高,而且存在单点故障风险。Kubernetes 1.30版本引入的Mutating Admission Policy(可变准入策略)彻底改变了这一局面,提供了一种声明式的资源修改方案。

1、基本概念

Mutating Admission Policy是Kubernetes的一种声明式准入控制机制,允许用户在资源创建或更新时自动修改资源规格。与传统的Webhook不同,它完全基于Kubernetes原生API,无需部署额外的服务。

核心组件说明

2、两种突变策略深度解析

2.1、JSON Patch策略:精准操作

JSON Patch基于RFC 6902标准,提供精确的JSON文档修改操作。适合需要对资源进行细粒度修改的场景。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: "sidecar-injection-policy"
spec:
  mutations:
    - patchType: "JSONPatch"
      jsonPatch:
        expression: >
          [
            {
              "op": "add",
              "path": "/spec/initContainers/-",
              "value": {
                "name": "mesh-proxy",
                "image": "mesh-proxy/v1.0.0",
                "restartPolicy": "Always"
              }
            },
            {
              "op": "add", 
              "path": "/metadata/labels/injected",
              "value": "true"
            }
          ]

JSON Patch操作符详解

2.2、ApplyConfiguration策略:声明式配置

ApplyConfiguration采用Kubernetes的声明式配置模型,更适合复杂的结构化修改。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: "security-context-policy"
spec:
  paramKind:
    kind: SecurityProfile
    apiVersion: security.example.com/v1
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["pods"]
  mutations:
    - patchType: "ApplyConfiguration"
      applyConfiguration:
        expression: >
          Object{
            spec: Object.spec{
              securityContext: Object.spec.securityContext{
                runAsNonRoot: true,
                runAsUser: 1000,
                runAsGroup: 1000,
                fsGroup: 1000
              },
              containers: [
                Object.spec.containers{
                  securityContext: Object.spec.containers.securityContext{
                    allowPrivilegeEscalation: false,
                    capabilities: Object.spec.containers.securityContext.capabilities{
                      drop: ["ALL"]
                    }
                  }
                }
              ]
            }
          }

3、实际应用场景与最佳实践

场景一:自动Sidecar注入

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: "istio-sidecar-injection"
spec:
  paramKind:
    kind: SidecarConfig
    apiVersion: networking.istio.io/v1beta1
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["pods"]
  matchConditions:
    - name: "namespace-has-label"
      expression: "namespace.labels['istio-injection'] == 'enabled'"
    - name: "pod-not-annotated"
      expression: "!has(object.metadata.annotations) || object.metadata.annotations['sidecar.istio.io/inject'] != 'false'"
  failurePolicy: Ignore
  reinvocationPolicy: IfNeeded
  mutations:
    - patchType: "ApplyConfiguration"
      applyConfiguration:
        expression: >
          Object{
            spec: Object.spec{
              initContainers: [
                Object.spec.initContainers{
                  name: "istio-init",
                  image: "docker.io/istio/proxyv2:1.20.0",
                  args: ["istio-iptables", "-p", "15001", "-z", "15006", "-u", "1337", "-m", "REDIRECT", "-i", "*", "-x", "", "-b", "*", "-d", "15090,15021,15020"]
                }
              ],
              containers: [
                Object.spec.containers{
                  name: "istio-proxy",
                  image: "docker.io/istio/proxyv2:1.20.0",
                  ports: [
                    Object.spec.containers.ports{
                      containerPort: 15090,
                      protocol: "TCP"
                    }
                  ]
                }
              ]
            }
          }

4、与传统Webhook方案对比

推荐使用Mutating Admission Policy的场景:

  • 简单的资源修改需求

  • 标准化的运维策略实施

  • 对性能要求较高的环境

  • 希望减少外部依赖的部署

仍需Webhook的场景:

  • 复杂的业务逻辑处理

  • 需要外部数据查询的决策

  • 已有成熟的Webhook基础设施

  • 需要与外部系统集成的场景