1. 课程导论：GitOps 核心理念、Webhook 在 GitOps 中的作用、配额与灰度发布准入检查的必要性
1.1 GitOps 核心理念：以 Git 为单一事实来源
GitOps 是一种以 Git 仓库作为声明式基础设施和应用程序的单一事实来源（Single Source of Truth）的运维模式。其核心工作流可概括为：
- 声明式配置：整个系统的期望状态（Deployment、Service、ConfigMap、Namespace 等）全部以 YAML/JSON 文件形式存储在 Git 仓库中。
- 自动同步：集群内的 Operator（如 Argo CD、Flux）持续监控 Git 仓库，一旦检测到配置变更，自动将集群实际状态拉向 Git 中定义的期望状态。
- 不可变发布：所有变更必须通过 Pull Request 合并到 Git 仓库，禁止直接操作集群。
- 可审计回滚：每一次变更都有 Git 提交记录，回滚只需 revert 一次 commit。
关键收益：GitOps 将 Kubernetes 集群的运维从“手动 kubectl”转变为“Git 驱动”，大幅降低配置漂移、提升团队协作效率。
1.2 Webhook 在 GitOps 中的作用：从事件驱动到自动化准入
在 GitOps 体系中，Webhook 承担着事件驱动和准入控制两个关键角色：
| Webhook 类型 | 触发时机 | 在 GitOps 中的典型用途 |
|---|---|---|
| Git Webhook | Git 仓库 Push / PR 合并 | 通知 GitOps Operator 重新同步；触发 CI 流水线验证配置 |
| Admission Webhook | K8s API 资源创建/更新/删除 | 在资源持久化到 etcd 前执行校验、默认值注入、策略检查 |
| Mutating Webhook | Admission 阶段（变异） | 自动注入 Sidecar、添加标签/注解、修改资源配额 |
| Validating Webhook | Admission 阶段（校验） | 验证资源是否符合命名规范、配额限制、安全策略 |
实践要点：Git Webhook 负责“触发同步”，Admission Webhook 负责“拦截校验”。两者结合，可以在配置进入集群之前就完成合规性检查，避免不合规资源被部署。
1.3 配额与灰度发布准入检查的必要性
在多人协作的 GitOps 环境中，如果没有准入检查，以下问题会频繁发生：
- 资源超卖：某个团队在 Namespace 中创建大量 Pod 或 PVC，导致集群资源耗尽，影响其他业务。
- 灰度失控：灰度发布时，新版本 Pod 比例过高或过低，缺乏流量控制，导致线上事故。
- 配置违规：镜像来源不合法、特权容器未授权、标签缺失等安全合规问题。
- 配额冲突：多个应用争抢同一端口、存储类或 GPU 资源。
风险警示：没有准入检查的 GitOps 等于“自动部署漏洞”。Webhook 是最后一道防线，必须在资源进入集群之前完成配额校验和灰度策略验证。
1.4 准入检查的核心维度
| 检查维度 | 检查内容 | 典型策略 |
|---|---|---|
| 资源配额 | CPU / 内存 / GPU / 存储 / Pod 数量 | 每个 Namespace 设置 ResourceQuota；LimitRange 约束容器资源 |
| 灰度发布 | 新版本副本比例、流量权重、金丝雀条件 | 只允许 10% 流量进入新版本；健康检查通过后逐步放量 |
| 安全策略 | 镜像仓库来源、特权模式、hostNetwork | 只允许内部镜像仓库；禁止 privileged: true |
| 命名规范 | 资源名称、标签、注解格式 | 强制 app.kubernetes.io/name 标签；名称正则校验 |
| 依赖检查 | ConfigMap / Secret / PVC 是否存在 | 创建 Deployment 前检查引用的 ConfigMap 是否已存在 |
1.5 本课程实战目标
通过本课程，你将掌握以下核心能力：
- 搭建完整的 Git Webhook 事件接收与处理服务。
- 编写 Validating Admission Webhook 实现资源配额校验。
- 编写 Mutating Admission Webhook 实现灰度发布策略注入。
- 结合 Argo CD / Flux 实现 GitOps 全链路准入控制。
- 使用 Go / Python 开发生产级 Webhook 服务并部署到 K8s 集群。
课程产出：一套可直接用于生产环境的 GitOps 准入检查系统，包含配额管理、灰度发布策略、安全合规校验三大模块。