📚 课程目录第3章 Kubernetes调度基础

3. GitOps 原理与工具选型：声明式配置、Git 作为单一事实来源、ArgoCD 与 Flux 对比

3.1 GitOps 核心原理

GitOps 是一种以 Git 仓库作为声明式基础设施和应用程序的单一事实来源（Single Source of Truth）的运维模式。其核心思想是将运维操作从“手动执行命令”转变为“自动同步 Git 状态”。

  核心原则：
  声明式配置：整个系统的期望状态（Deployment、Service、ConfigMap 等）全部以 YAML/JSON 文件形式描述。
Git 作为单一事实来源：Git 仓库中的配置是系统状态的权威定义，任何手动修改集群的行为都被视为“漂移”，会被自动纠正。
自动同步：GitOps Operator 持续监控 Git 仓库，一旦发现变更，自动将集群状态拉齐到 Git 中定义的期望状态。
可审计与回滚：每一次变更都对应一次 Git Commit，天然具备完整的变更历史与回滚能力。

实践要点：GitOps 并非简单的“用 Git 存 YAML”，而是要求所有集群变更都必须通过 Pull Request 合并到 Git 仓库，再由 Operator 自动应用到集群。直接使用 kubectl apply 修改集群属于违规操作。

3.2 声明式配置与 Git 作为单一事实来源

声明式配置是 GitOps 的基石。与命令式（Imperative）配置不同，声明式只描述“系统应该是什么样”，而不描述“如何达到这个状态”。

对比维度	命令式配置	声明式配置
操作方式	`kubectl run`、`kubectl scale`	`kubectl apply -f deployment.yaml`
状态管理	依赖操作顺序和当前状态	始终以 YAML 文件为期望状态
可复现性	低，依赖操作历史	高，YAML 文件即完整描述
GitOps 适配	不适用	天然适配

Git 作为单一事实来源意味着：

环境一致性：开发、测试、生产环境的配置都从同一个 Git 仓库的不同分支或目录派生。
变更审批：通过 Git 的 Pull Request 机制实现变更审批与代码审查。
自动修复：当集群状态因故障或手动操作偏离 Git 状态时，GitOps Operator 会自动回滚。

3.3 ArgoCD 与 Flux 对比

ArgoCD 和 Flux 是当前最主流的两个 GitOps 工具，均已被 CNCF 收录。两者在核心原理上一致，但在架构、同步策略、多集群支持和 UI 体验上存在显著差异。

对比维度	ArgoCD	Flux (v2)
CNCF 状态	毕业项目	毕业项目
架构模式	Controller + API Server + UI (独立组件)	Controller 模式 (多个独立控制器)
同步策略	Pull 模式，支持自动/手动同步，支持 Prune	Pull 模式，基于 GitRepository 和 Kustomization 资源
多集群支持	原生支持，通过 Cluster 注册管理	原生支持，通过 Kubeconfig 或 Cluster API
UI / Dashboard	功能丰富，内置 Web UI，支持应用拓扑图	无内置 UI，需配合 Flux UI 或 Weave GitOps
配置格式	原生支持 Helm、Kustomize、Jsonnet、纯 YAML	原生支持 Kustomize、Helm，通过 Source Controller 管理
SSO / RBAC	内置 SSO 集成 (OIDC/LDAP/SAML)，RBAC 细粒度	依赖 Kubernetes RBAC，SSO 需额外配置
Webhook 支持	支持 GitHub/GitLab/Bitbucket Webhook 加速	支持 Webhook (Notification Controller)
学习曲线	中等，UI 降低入门门槛	较低，CRD 设计简洁，文档清晰

选型建议：

团队需要可视化运维：优先选择 ArgoCD，其内置 Web UI 提供应用拓扑、同步状态、资源树等直观视图。
追求轻量级与 Kubernetes 原生：优先选择 Flux，其 CRD 设计更贴近 K8s 原生资源模型，控制器更轻量。
多集群管理需求：两者均支持，但 ArgoCD 的 Cluster 管理界面更成熟。
安全合规要求高：Flux 默认使用最小权限原则，ArgoCD 需注意 RBAC 配置。

3.4 工具选型决策流程

以下决策树可帮助团队根据自身情况快速选择：

3.5 实践案例：ArgoCD 与 Flux 的同步配置对比

以下展示同一个 Nginx 应用在 ArgoCD 和 Flux 中的配置方式，帮助理解两者的声明式配置差异。

ArgoCD Application 示例

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/gitops-demo.git
    targetRevision: main
    path: apps/nginx
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Flux Kustomization 示例

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nginx-app
  namespace: flux-system
spec:
  interval: 5m
  path: ./apps/nginx
  prune: true
  sourceRef:
    kind: GitRepository
    name: gitops-demo
  targetNamespace: production
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
      namespace: production

关键差异：

ArgoCD 使用 Application CRD 作为顶层资源，将源、目标、同步策略封装在一个对象中。
Flux 将源（GitRepository）和同步（Kustomization）分离为两个 CRD，职责更单一。
ArgoCD 的 syncPolicy 支持 selfHeal 自动修复漂移；Flux 默认通过 interval 轮询检测漂移。