📚 课程目录第2章多集群门禁概念

2. 多集群门禁概念：门禁、作用与准入检查关系

在多集群发布场景中，门禁（Gate）是控制发布流程能否继续执行的逻辑关卡。它像现实中的安检闸机——只有通过所有检查的发布请求，才能进入下一阶段。本章从定义、作用、与准入检查的关系三个维度，帮你建立对门禁的完整认知。

2.1 什么是门禁（Gate）

门禁是一个可编程的决策点，部署在发布流水线的关键位置。它接收当前发布上下文（目标集群、版本号、健康状态等），输出“通过”或“拒绝”的二元结果。在 Fleet 多集群架构中，门禁通常以 Webhook 或 策略引擎 的形式存在。

维度	说明
触发时机	发布前、灰度切换前、全量推送前
输入	集群元数据、当前版本、目标版本、健康指标、时间窗口
输出	Pass（允许继续） / Reject（阻断并告警）
实现方式	Fleet 原生 Gate、自定义 Webhook、OPA/Gatekeeper 策略

关键认知：门禁不是一次性检查，而是贯穿发布全生命周期的多次决策点。每个门禁的通过条件可以独立配置，形成“渐进式放行”的效果。

2.2 门禁在多集群发布中的作用

多集群环境比单集群复杂得多——集群间网络延迟、资源水位差异、版本兼容性等问题都会影响发布安全。门禁在以下四个层面发挥核心作用：

风险隔离：阻止有问题的版本扩散到更多集群，将爆炸半径控制在最小范围。
合规保障：确保每个集群的发布都满足组织策略（如安全基线、标签规范、资源配额）。
灰度节奏控制：通过门禁条件（如金丝雀集群健康时长、错误率阈值）自动决定是否扩大灰度范围。
审计与回滚触发：门禁拒绝时自动记录原因，并触发回滚流程，避免人工遗漏。

  实战案例：某金融科技公司使用 Fleet 管理 50 个集群。他们在灰度发布流水线中设置了 3 道门禁：

  · 门禁 1：检查目标集群是否已通过安全基线扫描（OPA 策略）

  · 门禁 2：检查金丝雀集群的 5 分钟错误率是否 < 0.1%

  · 门禁 3：检查全量推送时，所有集群的 etcd 健康状态是否为 Healthy

  任何一道门禁失败，发布自动暂停并通知 SRE 值班人员。

2.3 门禁与准入检查的关系

这两个概念容易混淆，但它们在 Kubernetes 生态中有明确分工：

对比维度	门禁（Gate）	准入检查（Admission Check）
作用范围	发布流水线级别（跨集群、跨阶段）	单个资源创建/更新请求级别（API Server 拦截）
触发时机	发布流程中的特定阶段（如灰度前、全量前）	资源提交到 API Server 时（Mutating / Validating）
检查内容	集群状态、灰度指标、时间窗口、人工审批	资源规范、安全上下文、镜像签名、标签合规
失败后果	暂停发布、触发回滚、通知审批人	拒绝资源创建/更新、返回错误给客户端
典型实现	Fleet Gate、Argo Rollouts AnalysisTemplate	ValidatingWebhookConfiguration、OPA Gatekeeper

两者的关系可以概括为：准入检查是门禁的底层能力之一。门禁可以调用准入检查来验证资源合规性，但门禁的视野更宽——它还能评估集群健康、灰度指标、甚至等待人工审批。在 Fleet 多集群门禁架构中，两者协同工作：

准入检查：在资源落地到目标集群前，确保资源本身合规（如镜像来自可信仓库）。
门禁：在发布流程的更高层面，决定“是否允许将这批资源推送到这个集群”。

常见误区：不要试图用准入检查替代门禁。准入检查无法感知集群间的灰度进度、无法等待人工审批、无法根据时间窗口动态调整策略。门禁是发布编排层的决策者，准入检查是资源层的守门员。

2.4 门禁的典型分类

根据决策来源，门禁可以分为以下三类，在实际项目中通常组合使用：

门禁类型	决策依据	示例	适用场景
自动门禁	指标、策略、集群状态	错误率 < 0.5%、OPA 策略通过	常规灰度发布、自动化流水线
人工门禁	审批人操作	SRE 点击“确认放行”	生产环境全量发布、高危变更
时间门禁	时间窗口、日历规则	仅允许 09:00-18:00 发布	金融、电商等业务高峰期保护

  最佳实践：在 Fleet 多集群门禁配置中，建议将自动门禁作为第一道防线，人工门禁作为最后一道防线。自动门禁拦截 90% 以上的问题，人工门禁处理剩余 10% 的复杂决策。时间门禁作为全局约束，避免非工作时间发布。