ValidatingWebhookConfiguration是做什么的用的

ValidatingWebhookConfiguration 是 Kubernetes 中用于动态验证资源对象的 API 资源。它允许在 Kubernetes API Server 接收到对象创建、修改或删除请求时，调用外部 Webhook 服务进行验证。这个机制提供了一种灵活的方式，可以根据自定义逻辑检查请求是否符合业务规则，进而决定是否允许操作。

核心原理

当 API Server 收到资源的变更请求时，它会根据配置的 ValidatingWebhookConfiguration 判断是否需要调用 Webhook 服务。Webhook 会收到请求内容并对其进行验证，然后返回允许或拒绝该操作的结果。通过这种方式，可以在不修改 Kubernetes API Server 源代码的情况下，增加自定义的校验逻辑。

使用场景

• 强制执行特定的资源命名约定。
• 验证 Pod 或其他资源是否包含所需的标签、注解等。
• 校验 Deployment、Service 等资源的字段是否合法。
• 防止某些不允许的配置被提交到集群中。

ValidatingWebhookConfiguration 配置的关键字段

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-validating-webhook
webhooks:
  - 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

详细讲解

1. metadata.name: ValidatingWebhookConfiguration 的名字，用于唯一标识这个配置。

2. webhooks: 一个列表，每个 Webhook 代表一个外部的验证服务。

3. rules: 定义了 Webhook 作用于哪些资源、操作和 API 组。这些字段让 API Server 知道在什么情况下调用 Webhook。

   • apiGroups: 指定 Webhook 适用于哪些 API 组。"" 代表核心组（core API group，如 Pod）。
   • apiVersions: 指定 Webhook 作用于哪些版本的 API。
   • operations: 指定拦截的操作类型，比如 CREATE、UPDATE、DELETE。
   • resources: 指定需要验证的资源类型，如 pods、deployments。

4. clientConfig: 指定了如何访问 Webhook 服务。

   • service: Webhook 服务的名称和命名空间。
   • path: 服务的路径，API Server 将向该路径发送请求。
   • caBundle: Webhook 服务的 CA 证书，用于验证 Webhook 服务的 HTTPS 证书。

5. admissionReviewVersions: 声明 Webhook 支持的 AdmissionReview 版本，常见的有 v1 和 v1beta1。

6. sideEffects: 声明 Webhook 的执行是否有副作用，比如是否会修改集群的状态。常见值为 None 或 Some.

7. timeoutSeconds: 定义 Webhook 请求的超时时间。默认值为 30 秒，但通常建议设置较短的超时（如 5 秒）。

8. 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."
    }
  }
}

流程总结

1. 用户通过 kubectl 或 API 发送资源操作请求（如创建 Pod）。
2. API Server 根据 ValidatingWebhookConfiguration 确定是否需要调用外部 Webhook 服务。
3. API Server 向 Webhook 服务发送 AdmissionReview 请求，包含待验证的资源内容。
4. Webhook 服务根据业务逻辑验证该请求，并返回是否允许该操作的结果。
5. API Server 根据 Webhook 返回的结果决定是否执行操作。

这种方式让集群管理员可以非常灵活地为 Kubernetes 集群引入动态的业务规则。

原文地址：https://blog.csdn.net/LONG_Yi_1994/article/details/142894297

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！