GitOps 基础回顾：声明式配置、Git 作为单一事实来源、Pull vs Push 模式、Operator 模式
在深入平台门户集成与 Scheduler 参数优化之前，必须重新夯实 GitOps 的核心基础。GitOps 并非简单的“用 Git 存 YAML”，而是一套以声明式配置为输入、以 Git 仓库为权威源、以自动化同步为引擎的交付范式。本节从四个维度拆解其底层逻辑。
2.1 声明式配置：期望状态驱动
声明式配置是 GitOps 的“语言”。运维人员只需描述系统“应该是什么样”，而不必编写“如何变成这样”的步骤。Kubernetes 原生资源（Deployment、Service、ConfigMap）本身就是声明式的典范。
| 维度 | 命令式（Imperative） | 声明式（Declarative） |
|---|---|---|
| 操作方式 | kubectl run、kubectl scale |
kubectl apply -f deployment.yaml |
| 状态管理 | 手动跟踪变更历史 | Git 自动记录每次期望状态 |
| 可复现性 | 依赖操作顺序和环境 | 任意时刻从 Git 重建完全一致 |
| 回滚能力 | 需手动逆向操作 | Git revert + 自动同步 |
| 适用场景 | 调试、临时修复 | 生产环境、合规审计 |
声明式配置的核心价值在于：系统持续向 Git 中定义的期望状态收敛。任何手动修改（如 kubectl edit）都会被下一次同步覆盖，从而杜绝配置漂移。
# 声明式 Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: scheduler-worker
spec:
replicas: 3
template:
spec:
containers:
- name: worker
image: myregistry/scheduler:1.2.0
resources:
requests:
cpu: "500m"
memory: "512Mi"
2.2 Git 作为单一事实来源
Git 仓库不再只是代码托管工具，而是整个平台环境的权威状态存储库。所有环境配置、应用版本、基础设施定义都必须通过 Pull Request 合并到 Git 主分支，才能被同步到目标集群。
Git 作为单一事实来源带来的收益：
- 审计轨迹：每一次变更都有作者、时间戳、Commit SHA，满足 SOC2/PCI 合规要求。
- 协作基础：团队成员通过 Code Review 控制配置质量，避免“一人一台笔记本”的混乱。
- 灾难恢复：集群完全损坏时，只需从 Git 重新 Apply 所有资源即可重建。
2.3 Pull vs Push 模式
GitOps 同步机制分为两种主流模式，理解其差异对设计 Scheduler 参数优化窗口至关重要。
Push 模式（传统 CI/CD）
CI 流水线在构建完成后，主动将配置“推送”到目标集群。典型工具：Jenkins、GitLab CI 直接执行 kubectl apply。
- 优点：实时性高，适合开发环境快速迭代。
- 缺点：CI 需要集群凭证，安全风险高；集群网络必须对 CI 开放；难以处理大规模集群的并发同步。
Pull 模式（GitOps 原生）
集群内部运行一个 Agent（如 Argo CD、Flux），由 Agent 定期从 Git 仓库拉取配置并与当前集群状态做差异对比，自动修正漂移。
- 优点：集群无需对外暴露 API；Agent 可离线运行；天然支持多集群。
- 缺点：同步存在延迟（默认 3-5 分钟），需要配合 Webhook 或 Scheduler 优化。
| 对比维度 | Push 模式 | Pull 模式 |
|---|---|---|
| 安全模型 | CI 持有集群凭证 | 集群主动拉取，无需暴露 |
| 同步触发 | CI 事件驱动 | 定时轮询 + Webhook |
| 配置漂移修复 | 不自动修复 | 自动回滚到 Git 状态 |
| 网络要求 | 集群 API 可达 | Git 仓库可达 |
| 典型工具 | Jenkins、Spinnaker | Argo CD、Flux |
2.4 Operator 模式
Operator 是 Kubernetes 上扩展控制器逻辑的标准模式。它将领域知识（如数据库备份、消息队列扩缩容）编码为自定义控制器，持续监控并调整集群状态。
Operator 与 GitOps 的关系：
- 互补而非替代：GitOps 负责“配置的同步”，Operator 负责“运行时的自治”。
- 典型协作：GitOps 将 Custom Resource（CR）同步到集群，Operator 监听 CR 变化并执行复杂操作（如创建 PVC、调整集群节点）。
Operator 模式在平台门户集成中的典型场景：
- Scheduler 参数调优：编写一个 SchedulerOperator，监听 Git 中
SchedulerConfigCR 的变化，自动调整集群调度器的 Preemption、NodeSelector 等参数。 - 同步窗口管理：Operator 可以根据时间窗口（如业务低峰期）自动暂停/恢复 GitOps 同步，避免大版本更新影响在线服务。