ValidatingWebhookConfiguration 是 Kubernetes 中用于动态验证资源对象的 API 资源。它允许在 Kubernetes API Server 接收到对象创建、修改或删除请求时，调用外部 Webhook 服务进行验证。这个机制提供了一种灵活的方式，可以根据自定义逻辑检查请求是否符合业务规则，进而决定是否允许操作。
核心原理
当 API Server 收到资源的变更请求时，它会根据配置的 ValidatingWebhookConfiguration 判断是否需要调用 Webhook 服务。Webhook 会收到请求内容并对其进行验证，然后返回允许或拒绝该操作的结果。通过这种方式，可以在不修改 Kubernetes API Server 源代码的情况下，增加自定义的校验逻辑。
使用场景
强制执行特定的资源命名约定。验证Pod 或其他资源是否包含所需的标签、注解等。校验 Deployment、Service 等资源的字段是否合法。防止某些不允许的配置被提交到集群中。 ValidatingWebhookConfiguration 配置的关键字段
apiVersion: admissionregistration.k8s.io/v1kind: ValidatingWebhookConfigurationmetadata: name: my-validating-webhookwebhooks: - name: my-webhook.example.com rules: - apiGroups: # 作用于哪些 API 组 - "" apiVersions: # 作用于哪些 API 版本 - v1 operations: # 拦截哪些操作，例如 CREATE、UPDATE、DELETE - CREATE - UPDATE resources: # 拦截哪些资源 - pods clientConfig: service: name: my-webhook-service # Webhook 的服务名 namespace: default # Webhook 的命名空间 path: /validate # Webhook 服务的路径 caBundle: ... # CA 证书，用于验证服务端证书 admissionReviewVersions: ["v1"] # 支持的 AdmissionReview 版本 sideEffects: None # 侧效应声明 timeoutSeconds: 5 # 超时时间 failurePolicy: Fail # Webhook 失败时的策略：Fail 或 Ignore详细讲解
metadata.name: ValidatingWebhookConfiguration 的名字，用于唯一标识这个配置。
webhooks: 一个列表，每个 Webhook 代表一个外部的验证服务。
rules: 定义了 Webhook 作用于哪些资源、操作和 API 组。这些字段让 API Server 知道在什么情况下调用 Webhook。
apiGroups: 指定 Webhook 适用于哪些 API 组。"" 代表核心组（core API group，如 Pod）。apiVersions: 指定 Webhook 作用于哪些版本的 API。operations: 指定拦截的操作类型，比如 CREATE、UPDATE、DELETE。resources: 指定需要验证的资源类型，如 pods、deployments。 clientConfig: 指定了如何访问 Webhook 服务。
service: Webhook 服务的名称和命名空间。path: 服务的路径，API Server 将向该路径发送请求。caBundle: Webhook 服务的 CA 证书，用于验证 Webhook 服务的 HTTPS 证书。 admissionReviewVersions: 声明 Webhook 支持的 AdmissionReview 版本，常见的有 v1 和 v1beta1。
sideEffects: 声明 Webhook 的执行是否有副作用，比如是否会修改集群的状态。常见值为 None 或 Some.
timeoutSeconds: 定义 Webhook 请求的超时时间。默认值为 30 秒，但通常建议设置较短的超时（如 5 秒）。
failurePolicy: 定义当 Webhook 服务出现错误时的处理方式：
Fail: 如果 Webhook 无法访问或返回错误，操作将被拒绝。Ignore: 即使 Webhook 失败，也不会阻止资源创建或修改。 Webhook 服务的实现
Webhook 服务是一个外部的 HTTP(S) 服务器，用于接收并验证 API Server 发来的 AdmissionReview 请求，返回 AdmissionReview 响应。示例代码如下：
AdmissionReview 请求结构（API Server 发送的请求）：
{ "kind": "AdmissionReview", "apiVersion": "admission.k8s.io/v1", "request": { "uid": "12345678-1234-1234-1234-1234567890ab", "kind": { "group": "", "version": "v1", "kind": "Pod" }, "operation": "CREATE", "object": { "metadata": { "name": "example-pod" }, "spec": { "containers": [ { "name": "example-container", "image": "nginx" } ] } } }}AdmissionReview 响应结构（Webhook 返回的响应）：
{ "kind": "AdmissionReview", "apiVersion": "admission.k8s.io/v1", "response": { "uid": "12345678-1234-1234-1234-1234567890ab", "allowed": true, "status": { "message": "Pod creation is allowed." } }}流程总结
用户通过 kubectl 或 API 发送资源操作请求（如创建 Pod）。API Server 根据ValidatingWebhookConfiguration 确定是否需要调用外部 Webhook 服务。API Server 向 Webhook 服务发送 AdmissionReview 请求，包含待验证的资源内容。Webhook 服务根据业务逻辑验证该请求，并返回是否允许该操作的结果。API Server 根据 Webhook 返回的结果决定是否执行操作。 这种方式让集群管理员可以非常灵活地为 Kubernetes 集群引入动态的业务规则。