4. 准入控制机制：Kubernetes Admission Webhook（Mutating & Validating）的工作原理
Kubernetes API Server 在处理任何资源请求（创建、更新、删除）时，都会经过一个可插拔的准入控制链。Admission Webhook 是其中最重要的扩展机制，它允许外部服务在对象持久化之前对其进行拦截和修改。在 Cilium CNI 集成 Helm 交付的场景中，Webhook 用于确保 Cilium 的 CRD（如 CiliumNetworkPolicy）和 DaemonSet 配置符合集群安全基线。
4.1 准入控制链中的 Webhook 位置
下图展示了 API Server 在处理一个 kubectl apply -f cilium-config.yaml 请求时，Webhook 在认证、授权之后的执行顺序：
4.2 MutatingAdmissionWebhook：对象修改与默认值注入
Mutating Webhook 在对象被持久化之前，通过 JSON Patch 操作修改请求内容。在 Cilium 的 Helm Chart 中，它常用于：
- 自动注入 Cilium 相关的 Sidecar（如 Envoy 代理）到特定命名空间的 Pod。
- 设置资源默认值：为 CiliumNetworkPolicy 添加默认的标签选择器或流量方向。
- 修正配置冲突：当用户提交的 CiliumConfig 缺少必要字段时，自动填充集群级默认值。
工作流程：
1. API Server 将 AdmissionReview 请求（包含 Object 和 OldObject）发送给 Webhook 服务。
2. Webhook 返回 AdmissionReview 响应，其中包含 JSON Patch 操作列表。
3. API Server 应用 Patch 后，继续执行后续准入阶段。
1. API Server 将 AdmissionReview 请求（包含 Object 和 OldObject）发送给 Webhook 服务。
2. Webhook 返回 AdmissionReview 响应，其中包含 JSON Patch 操作列表。
3. API Server 应用 Patch 后，继续执行后续准入阶段。
4.3 ValidatingAdmissionWebhook：策略强制与安全校验
Validating Webhook 不修改对象，只返回允许或拒绝。在 Cilium 集成场景中，它承担以下职责：
| 校验场景 | 检查内容 | 拒绝条件示例 |
|---|---|---|
| CiliumNetworkPolicy 语法 | 规则中的 endpointSelector、toPorts 格式 | 使用了已废弃的 v1alpha2 API 版本 |
| 安全基线合规 | Pod 是否设置了 privileged: true | 非系统命名空间请求特权容器 |
| 资源配额冲突 | Cilium DaemonSet 的 nodeSelector 与现有节点池冲突 | 同时选中了 Windows 和 Linux 节点 |
| Helm 版本兼容性 | Chart 的 apiVersion 与集群 K8s 版本匹配 | Helm v3 Chart 部署到 K8s 1.16 以下集群 |
4.4 Webhook 配置清单核心字段
在 Helm Chart 中，Webhook 配置通过 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 资源定义。以下是一个针对 CiliumNetworkPolicy 的 Validating Webhook 配置片段：
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: cilium-policy-validator
webhooks:
- name: policy-validator.cilium.io
clientConfig:
service:
name: cilium-webhook-service
namespace: kube-system
path: /validate/ciliumnetworkpolicy
caBundle: <base64-encoded-ca-cert>
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: ["cilium.io"]
apiVersions: ["v2"]
resources: ["ciliumnetworkpolicies"]
scope: "Namespaced"
admissionReviewVersions: ["v1"]
sideEffects: None
timeoutSeconds: 10
failurePolicy: Fail
matchPolicy: Equivalent
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values: ["kube-system"]
最佳实践：在生产环境中，始终将
failurePolicy 设置为 Fail，避免 Webhook 服务不可用时导致不合规对象被创建。同时，通过 namespaceSelector 排除系统命名空间，防止 Webhook 自举死锁。
4.5 Mutating 与 Validating 的协同工作流
下图展示了当用户通过 Helm 安装 Cilium 时，两个 Webhook 如何协同完成一次完整的准入控制：
4.6 常见陷阱与避坑指南
⚠️ 关键陷阱：
- Webhook 自举死锁：如果 Webhook 服务本身需要被准入控制，而它的 Pod 创建请求又被自己拦截，会导致死锁。解决方案：使用
namespaceSelector排除 Webhook 所在的命名空间，或使用objectSelector排除 Webhook 配置资源。 - 超时设置过短：Cilium 的 Validating Webhook 在策略规则较多时可能超过默认的 10 秒超时。建议根据策略复杂度调整
timeoutSeconds至 15-30 秒。 - 证书管理：Webhook 必须通过 TLS 与 API Server 通信。在 Helm Chart 中，建议使用
cert-manager自动签发证书，避免手动轮换。 - sideEffects 字段：必须设置为
None或NoneOnDryRun，否则 Webhook 在 dry-run 模式下会被跳过，导致策略验证遗漏。