📚 课程目录第2章 GitOps核心原理

2. GitOps核心原理：声明式配置、状态同步、Git作为单一事实来源、Operator模式

GitOps 并非单一工具，而是一套以 声明式配置 和 Git 为基石的运维模型。其核心在于将运维意图从“如何做”转变为“要什么”，并通过自动化循环持续收敛集群状态。理解以下四大原理，是后续进行异常日志关联与根因定位的前提。

2.1 四大核心原理概览

原理	核心描述	运维范式转变
声明式配置	用户定义目标状态（YAML/JSON），而非执行步骤。	从命令式（kubectl run）转向声明式（kubectl apply -f）
Git 作为单一事实来源	所有环境配置、策略、版本均以 Git 仓库中的文件为准。	从“谁改了集群”转向“谁合并了 PR”
状态同步	自动化 Agent 持续对比 Git 与集群，自动修复偏差。	从人工巡检转向自动收敛
Operator 模式	用自定义控制器将领域知识编码为自动化逻辑。	从脚本胶水转向智能控制器

2.2 声明式配置：定义“要什么”

声明式配置是 GitOps 的输入语言。用户只需描述应用的最终状态（如副本数、镜像版本、网络策略），系统负责执行达到该状态所需的操作。

  关键对比： 命令式配置关注“如何做”，声明式配置关注“结果是什么”。在 Cilium 网络策略场景中，声明式策略文件直接定义了允许的流量规则，而非编写 iptables 脚本。

# 声明式示例：CiliumNetworkPolicy
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-to-backend"
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

2.3 Git 作为单一事实来源：不可变审计轨迹

Git 仓库成为整个系统的“黄金副本”。所有对集群的变更必须通过 Pull Request 提交到 Git，经审核后合并，再由同步工具应用到集群。这提供了完整的版本历史、回滚能力和访问控制。

不可变历史： 每一次配置变更都有 Commit SHA 和作者记录。
审计合规： 集群状态与 Git 仓库的差异即为“漂移”，可被自动检测。
灾难恢复： 从零重建集群时，只需从 Git 仓库 apply 所有配置。

实践要点： 确保 Git 仓库中存储的配置是“可运行”的完整清单，包括 Deployment、Service、CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy 等。任何手动 kubectl edit 操作都应被视为“配置漂移”事件。

2.4 状态同步：从 Git 到集群的闭环

状态同步是 GitOps 的执行引擎。通常由 Argo CD 或 Flux 等工具实现。其核心循环为：对比 → 识别差异 → 应用修正 → 再次对比。

轮询/Webhook 触发： 检测 Git 仓库是否有新 Commit。
Diff 计算： 将 Git 中的期望状态与集群中的实际状态进行结构化对比。
自动/手动同步： 执行 kubectl apply 或 helm upgrade 以消除差异。
健康检查： 验证应用是否达到 Running 状态，网络策略是否生效。

2.5 Operator 模式：将运维知识编码为控制器

Operator 是 Kubernetes 上的自定义控制器，它扩展了 K8s API，将特定应用（如 Cilium、Prometheus、PostgreSQL）的运维逻辑自动化。在 GitOps 模型中，Operator 负责处理声明式配置无法覆盖的“有状态”或“复杂拓扑”场景。

自定义资源（CRD）： 定义新的 API 对象，如 CiliumNetworkPolicy、CiliumEndpoint。
控制循环： Operator 持续监听 CRD 的变化，并执行相应的调谐逻辑（Reconcile）。
与 GitOps 结合： Git 仓库中存储 CRD 实例的 YAML，Operator 在集群内负责将其转化为底层配置（如 eBPF 程序、iptables 规则）。

异常排查提示： 当 GitOps 同步显示“Synced”但网络策略未生效时，问题可能出在 Operator 层。例如 Cilium Agent 未正确加载 CRD 转换后的 eBPF 规则。此时需要查看 Cilium Operator 和 Agent 的日志，而非仅检查 Git 状态。

2.6 四大原理在异常定位中的协同作用

当生产环境出现网络中断或发布失败时，GitOps 的四大原理提供了清晰的排查路径：

检查 Git 历史： 确认最近一次变更的 Commit 内容，是否为导致异常的配置（单一事实来源）。
对比声明式配置： 查看 CiliumNetworkPolicy 是否被意外修改或删除（声明式配置）。
检查同步状态： 确认 Argo CD 是否显示“OutOfSync”，以及自动同步是否被禁用（状态同步）。
分析 Operator 日志： 如果 Git 和同步状态均正常，则需排查 Cilium Operator 是否成功将 CRD 转换为 eBPF 规则（Operator 模式）。