1. GitOps 理念与核心原则：声明式配置、版本控制、自动化同步、自愈能力

GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制、自动化同步与自愈能力有机结合，形成一套可审计、可回滚、可复现的发布流水线。在大型 Kubernetes 集群中，GitOps 是解决多环境、多租户、高频发布挑战的核心方法论。

1.1 核心原则概览

1.2 声明式配置：从“如何做”到“要什么”

传统运维依赖脚本（Shell、Ansible Playbook）描述操作步骤，GitOps 则要求开发者只描述最终状态。Kubernetes 原生支持声明式模型，通过 kubectl apply 或 GitOps Operator 将 YAML 清单提交给 API Server。

# 声明式示例：期望运行 3 个 nginx 副本
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

1.3 版本控制：Git 作为单一事实来源

所有配置变更必须通过 Git 提交，禁止直接修改集群资源。Git 仓库不仅存储应用清单，还包含基础设施定义、策略配置、监控告警规则等。每一次提交都对应一次可审计的变更记录。

• 分支策略： 推荐 trunk-based 或 GitFlow 简化版，环境分支（dev/staging/prod）与 feature 分支分离。
• PR 审查： 所有合并到主分支或环境分支的变更必须经过 Code Review，确保配置质量。
• 标签与 Release： 使用 Git tag 标记可部署版本，与容器镜像 tag 对应，实现端到端可追溯。

1.4 自动化同步：Operator 驱动的持续协调

GitOps Operator（如 Argo CD、Flux）持续监控 Git 仓库中的期望状态，并与集群实际状态进行对比。当检测到差异时，Operator 自动执行同步操作，将集群状态拉向 Git 中定义的状态。

# Argo CD Application 示例
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.company.com/k8s-configs.git
    targetRevision: main
    path: environments/production/nginx
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

1.5 自愈能力：集群状态的自动收敛

自愈是 GitOps 区别于传统 CI/CD 的关键特性。当集群因故障、手动操作或资源驱逐导致状态偏离 Git 定义时，Operator 自动执行纠正动作，无需人工介入。

• Reconcile 循环： Operator 每隔 3-5 分钟（可配置）执行一次全量对比。
• Webhook 触发： Git 仓库 Push 事件通过 Webhook 触发即时同步，缩短偏差窗口。
• 健康检查： 结合 K8s Readiness/Liveness Probe 与 Argo CD 资源健康状态，确保同步后的应用真正可用。
• 自动回滚： 当同步后的应用健康检查失败时，Operator 自动回滚到上一个已知正常版本。

1.6 GitOps 核心工作流（SVG 架构图）

1.7 GitOps 与传统 CI/CD 对比

1.8 自愈闭环详解（SVG 流程图）