4. 灰度发布准入机制：准入控制器概念、Webhook准入流程、灰度策略校验逻辑

灰度发布的核心挑战在于：如何在不中断现有服务、不污染生产数据的前提下，安全地将新版本流量引入集群。Kubernetes 准入控制器（Admission Controller）正是解决这一问题的关键枢纽。它拦截所有对 API Server 的请求，在对象持久化之前执行校验与变更，为灰度策略的强制落地提供了不可绕过的执行点。

4.1 准入控制器概念与分类

准入控制器是一段代码，它拦截 Kubernetes API Server 的请求，在对象被持久化到 etcd 之前执行自定义逻辑。根据执行阶段，分为两类：

在灰度发布场景下，准入控制器承担以下职责：

• 强制绑定灰度标签：确保每个新创建的 Pod 都携带 version: canary 或 track: stable 等标识。
• 校验灰度策略合规：检查灰度比例、命名空间白名单、资源配额是否满足准入条件。
• 阻断非法变更：禁止在灰度发布期间修改稳定版本的 Deployment 副本数或镜像版本。

4.2 Webhook 准入流程

Kubernetes 通过 Admission Webhook 实现外部扩展准入逻辑。Webhook 本质上是一个 HTTPS 回调端点，API Server 在请求处理过程中调用该端点。完整流程如下：

1. 客户端发起请求：用户或 CI/CD 系统通过 kubectl apply 或 API 调用创建/更新资源。
2. API Server 认证与授权：验证请求者身份与 RBAC 权限。
3. Mutating Webhook 拦截：API Server 根据 MutatingWebhookConfiguration 规则，将请求对象发送到注册的 Webhook 服务。Webhook 返回 Patch 操作（JSON Patch），修改对象内容。
4. 对象校验（Schema Validation）：Kubernetes 内置校验器检查对象结构合法性。
5. Validating Webhook 拦截：API Server 将（可能已被修改的）对象发送到 Validating Webhook。Webhook 返回允许或拒绝决策。
6. 持久化到 etcd：通过所有准入检查后，对象被写入 etcd，并返回给客户端。

4.3 灰度策略校验逻辑

灰度策略校验是 Validating Webhook 的核心逻辑。它确保灰度发布操作符合预定义的策略规则，防止误操作导致生产故障。校验逻辑通常包含以下维度：

func validateCanaryDeployment(req *admission.AdmissionRequest) *admission.AdmissionResponse {
    // 1. 解析请求对象
    deploy, _ := parseDeployment(req.Object.Raw)

    // 2. 命名空间白名单检查
    if !isNamespaceAllowed(deploy.Namespace) {
        return deny("Namespace not allowed for canary")
    }

    // 3. 灰度比例校验
    canaryReplicas := deploy.Spec.Replicas * canaryPercent / 100
    if canaryReplicas < 1 {
        return deny("Canary replicas must be at least 1")
    }

    // 4. 标签合规性检查
    if deploy.Spec.Template.Labels["version"] != "canary" {
        return deny("Missing required label: version=canary")
    }

    // 5. 镜像版本约束
    if strings.HasSuffix(deploy.Spec.Template.Containers[0].Image, ":latest") {
        return deny("Canary image must not use 'latest' tag")
    }

    return allow()
}

4.4 灰度准入的多环境适配

不同环境（开发、测试、预发、生产）对灰度准入的要求差异显著。标准模板驱动的方案通过 环境级别配置 实现差异化适配：