GitOps 与持续交付（ArgoCD / Flux）（仓库结构与同步策略）

适用场景

GitOps 的价值是"环境状态可追溯、可回滚"：谁在什么时候改了什么，Git 里全有。前提是权限与分支策略管好，否则变成"用 Git 破坏生产"。

配置步骤（仓库结构与同步策略）

# 目录示例
# apps/order/overlays/prod/kustomization.yaml
# clusters/prod/apps.yaml（ArgoCD Application 清单）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: order-prod, namespace: argocd }
spec:
  project: default
  source: { repoURL: 'https://git.example.com/k8s.git', path: apps/order/overlays/prod, targetRevision: main }
  destination: { server: 'https://kubernetes.default.svc', namespace: order }
  syncPolicy: { syncOptions: [CreateNamespace=true] }

关键参数与建议

• 仓库结构：应用清单与集群清单分离，按环境分目录
• 同步策略：手动同步（重要环境）或自动同步（开发环境）
• 差异检测：漂移告警，防止有人手工改动集群
• 回滚：Git revert 即回滚，配合镜像版本可追溯
• 权限：生产分支保护 + 代码评审，禁止直推

容易踩的坑

• 所有环境同目录，容易误改生产
• 自动同步 + 直推主线，缺少评审
• 清单与镜像版本不绑定，回滚不知回到哪

验证与巡检

argocd app list
argocd app diff order-prod

• 巡检：无 OutOfSync 漂移、生产分支受保护

小结

GitOps 验收：任何一次生产变更都能在 Git 找到对应提交，并且能通过 revert 回滚。做不到就还是"脚本+手工"。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。