Kubernetes准入Webhook开发与平台集成 - 第1节

1.1 什么是 Webhook

Webhook 是一种轻量级的事件驱动回调机制。当某个事件在源系统中发生时，源系统会主动向预先配置的目标 URL 发送一个 HTTP 请求（通常是 POST），将事件数据实时推送给接收方。简单来说，Webhook 就是“反向 API”——由事件生产者主动推送，而非消费者轮询拉取。

Webhook 的工作流程

1. 注册：消费者在源系统中注册一个回调 URL，并订阅感兴趣的事件类型。
2. 触发：当源系统内部发生订阅事件时（如代码推送、订单创建、Pod 状态变更），立即构造事件负载。
3. 推送：源系统通过 HTTP POST 请求将事件数据发送到注册的 URL。
4. 处理：接收方解析请求，执行自定义逻辑（如触发 CI/CD、更新数据库、发送通知）。
5. 响应：接收方返回 HTTP 状态码（通常为 200 OK）确认收到，源系统根据响应决定是否重试。

1.2 Webhook 与 API 的区别

Webhook 和 API 都是系统间通信的方式，但它们的通信模式和使用场景有本质区别。API 是“拉”模式，Webhook 是“推”模式。

1.3 Webhook 典型应用场景

Webhook 在 DevOps、云原生、SaaS 集成等领域有广泛的应用。以下是三个最典型的场景：

场景一：CI/CD 流水线触发

当开发者向 GitHub/GitLab 推送代码或创建 Pull Request 时，代码仓库通过 Webhook 通知 CI 系统（如 Jenkins、GitLab CI、ArgoCD）自动触发构建、测试和部署流程。

# GitHub Webhook 负载示例（简化）
POST /webhook/jenkins HTTP/1.1
Content-Type: application/json

{
  "ref": "refs/heads/main",
  "commits": [
    {
      "id": "abc123",
      "message": "fix: 修复登录超时问题",
      "timestamp": "2025-01-15T10:30:00Z"
    }
  ],
  "repository": {
    "full_name": "myorg/myapp",
    "clone_url": "https://github.com/myorg/myapp.git"
  }
}

场景二：Kubernetes 准入控制

Kubernetes 提供 Admission Webhook（MutatingWebhook 和 ValidatingWebhook），在资源创建/更新请求持久化之前拦截并处理。这是 Webhook 在云原生平台最核心的落地场景。

• MutatingWebhook：修改资源定义，如自动注入 Sidecar、添加默认标签、设置资源配额。
• ValidatingWebhook：校验资源合规性，如禁止特权容器、强制镜像签名、检查命名空间白名单。

场景三：SaaS 平台事件通知

支付平台（如 Stripe、支付宝）、消息服务（如 Slack、钉钉）、监控系统（如 Prometheus + Alertmanager）都通过 Webhook 将业务事件实时推送给订阅方。