2. 门禁类型与分类：代码质量门禁、安全扫描门禁、合规性门禁、资源配额门禁、人工审批门禁

在 GitOps 发布流水线中，准入门禁（Quality Gate）是阻止不合格变更进入下一阶段的策略性检查点。根据检查维度与触发机制的不同，门禁可分为五大核心类型。理解每种门禁的判定逻辑、失败特征与证据留存方式，是排障路径设计的基础。

2.1 门禁分类总览

下表从检查对象、触发时机、判定依据与典型工具四个维度，对比五种门禁的核心差异：

2.2 门禁执行流程与证据链

下图展示了五种门禁在 GitOps 流水线中的典型执行顺序与证据留存节点：

2.3 各门禁类型详解

2.3.1 代码质量门禁

代码质量门禁在 PR 创建或代码推送时触发，通过静态分析工具检查代码可维护性、复杂度与测试覆盖率。常见失败原因包括：

• 覆盖率未达标：新增代码行覆盖率低于阈值（如 80%）。
• 圈复杂度超标：单个方法复杂度超过 15，导致测试难度上升。
• 重复代码率过高：代码块重复率超过 3%，增加维护成本。

2.3.2 安全扫描门禁

安全扫描门禁在镜像构建完成或制品推送至仓库时触发，扫描操作系统包与语言依赖中的已知漏洞（CVE）。判定逻辑通常基于漏洞严重等级与数量：

• Critical / High 级别漏洞：直接阻断流水线，要求修复或提供豁免审批。
• Medium / Low 级别漏洞：允许通过但记录至安全仪表盘，触发告警。
• 许可证合规：检查依赖许可证是否与项目策略冲突（如 GPL 在商业软件中使用）。

2.3.3 合规性门禁

合规性门禁在 Kubernetes Manifest 提交或预发布阶段触发，通过策略引擎（OPA / Kyverno）检查资源定义是否符合组织规范。典型检查项包括：

• 安全上下文：容器是否以非 root 用户运行，是否启用 readOnlyRootFilesystem。
• 网络策略：Pod 是否绑定 NetworkPolicy，是否开放了不必要的端口。
• 标签与注解：是否包含必填标签（如 app.kubernetes.io/name）。
• 资源限制：是否设置了 CPU / 内存的 requests 与 limits。

2.3.4 资源配额门禁

资源配额门禁在部署预检阶段触发，检查目标命名空间的资源使用情况是否允许新变更。判定依据包括：

• CPU / 内存配额：当前已分配量 + 新请求量 ≤ 命名空间上限。
• 存储配额：PVC 总量是否超过存储类配额。
• 对象数量：Pod、Service、ConfigMap 等对象数量是否接近上限。

资源配额门禁的排障路径通常涉及以下步骤：

1. 执行 kubectl describe resourcequota -n <namespace> 查看当前配额使用量。
2. 对比新变更的 requests 与 limits 是否在剩余容量内。
3. 检查是否存在僵尸资源（如未清理的 Completed Pod 或旧 ReplicaSet）。

2.3.5 人工审批门禁

人工审批门禁是流水线中唯一需要人为判断的环节，通常部署在关键环境（生产、预发布）之前。常见模式包括：

• PR Review 模式：要求至少 1 名代码所有者或 Maintainer 批准 PR。
• ArgoCD Sync 审批：在 ArgoCD 中启用 sync-waves 与 manual sync，要求运维人员手动确认。
• 超时自动拒绝：审批超时（如 72 小时）后自动关闭变更请求。

2.4 门禁组合策略与排障优先级

在实际 GitOps 流水线中，门禁通常按以下优先级组合执行：

1. 代码质量门禁（最快反馈，阻断低质量代码进入后续阶段）
2. 安全扫描门禁（防止漏洞扩散至镜像仓库）
3. 合规性门禁（确保 Manifest 符合策略，避免集群违规）
4. 资源配额门禁（预检集群容量，防止部署失败）
5. 人工审批门禁（最终人为确认，适用于生产环境）

排障时建议从最上游的门禁开始排查，因为上游门禁失败会阻断下游门禁的执行，避免重复分析。例如，代码质量门禁失败时，无需继续扫描镜像安全，可节省流水线资源。