3. 准入控制基础：Kubernetes Admission Webhook 原理、Mutating 与 Validating Webhook 的区别
在 Istio 网格升级过程中，准入控制（Admission Control）是保障集群安全与策略合规的第一道防线。Kubernetes 通过 Admission Webhook 机制，允许运维人员在资源持久化之前注入自定义逻辑，从而实现配置校验、自动注入、策略拦截等能力。本章将深入剖析 Admission Webhook 的工作原理，并清晰区分 Mutating 与 Validating 两种 Webhook 的核心差异。
3.1 Kubernetes Admission Webhook 工作原理
Admission Webhook 是 Kubernetes API Server 在处理资源请求（如创建、更新、删除）时，调用外部 HTTP 回调的一种扩展机制。其核心流程可概括为：认证 → 授权 → 准入 → 持久化。Webhook 位于“授权”之后、“持久化”之前，确保所有资源变更都经过策略引擎的审核。
Webhook 通过 AdmissionReview 对象与 API Server 通信。API Server 将请求封装为 AdmissionReview 发送给 Webhook 服务，Webhook 处理后返回包含 Allowed 字段的 AdmissionReview 响应。若 Allowed 为 false，则请求被拒绝，并返回错误信息。
3.2 Mutating 与 Validating Webhook 的核心区别
两种 Webhook 在准入控制链中扮演不同角色，其核心差异体现在执行顺序、功能定位和操作方式上。下表从多个维度进行对比：
| 对比维度 | Mutating Webhook | Validating Webhook |
|---|---|---|
| 执行顺序 | 先执行（在对象变更前） | 后执行（在对象变更后） |
| 核心功能 | 修改资源对象（注入、替换、默认值） | 校验资源对象（合规性、约束检查） |
| 操作类型 | 允许修改 AdmissionReview 中的 Object | 只读检查，不允许修改 Object |
| 典型场景 | Istio sidecar 注入、资源标签自动添加 | Pod 安全策略校验、资源配额检查 |
| 失败策略 | Fail / Ignore | Fail / Ignore |
| 超时控制 | 支持（默认 30s） | 支持（默认 30s） |
| 副作用 | 可能产生多次调用（重试时需幂等） | 通常无副作用 |
3.3 两种 Webhook 的协作关系
在 Istio 网格升级场景中，Mutating 和 Validating Webhook 通常协同工作：
- Mutating Webhook：负责自动注入 sidecar 代理、修改 Pod 的 annotations 和 labels，确保新创建的 Pod 被纳入网格。
- Validating Webhook：负责校验注入后的配置是否合法，例如检查 sidecar 版本是否与控制面兼容、端口映射是否正确。
3.4 配置示例：MutatingWebhookConfiguration 与 ValidatingWebhookConfiguration
两种 Webhook 的配置方式类似，均通过 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源定义。以下是一个简化的 Mutating Webhook 配置示例：
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: istio-sidecar-injector
webhooks:
- name: sidecar-injector.istio.io
clientConfig:
service:
name: istio-sidecar-injector
namespace: istio-system
path: /inject
caBundle: <base64-encoded-ca-cert>
rules:
- operations: ["CREATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
failurePolicy: Fail
sideEffects: None
admissionReviewVersions: ["v1", "v1beta1"]Validating Webhook 的配置结构完全相同，仅 kind 字段不同：
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: istio-validator
webhooks:
- name: validator.istio.io
clientConfig:
service:
name: istiod
namespace: istio-system
path: /validate
caBundle: <base64-encoded-ca-cert>
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: ["networking.istio.io"]
apiVersions: ["v1beta1"]
resources: ["virtualservices", "destinationrules"]
failurePolicy: Fail
sideEffects: None
admissionReviewVersions: ["v1", "v1beta1"]3.5 故障排查要点
在 Istio 网格升级过程中，Webhook 相关故障是常见问题。以下列出几个关键排查方向：
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| Pod 创建卡住，无法调度 | Mutating Webhook 超时或拒绝请求 | 检查 Webhook 服务日志，确认 failurePolicy 是否为 Fail |
| sidecar 未注入 | Mutating Webhook 配置错误或服务不可达 | 验证 clientConfig 中的 service 地址和 CA 证书 |
| 资源更新被拒绝 | Validating Webhook 校验不通过 | 查看 API Server 返回的错误信息，检查 Webhook 日志 |
| Webhook 证书过期 | CA 证书未及时轮换 | 使用 openssl 检查证书有效期，重新生成并更新 caBundle |