
K8s Mutating Admission Policy
参考: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基础设施
需要与外部系统集成的场景