10.1. GitOps 与渐进式发布：Argo CD、Flux 与 Rollouts

GitOps 的核心不是「装一个 Argo CD」，而是一条约束：集群的期望状态只能从 Git 收敛，任何手工 kubectl apply 都会被控制器纠正。渐进式发布则把「一次全量切换」改成「按指标逐步放量」，两者结合才是可审计、可回滚的交付链路。

层级:: L4 · 实战
难度:: 进阶
预计:: 55 分钟
前置:: Helm、Kustomize、Deployment

10.1.1. GitOps 的四个原则

声明式：集群状态用 YAML/Helm/Kustomize 描述。
版本化：所有变更进 Git，可审计、可回滚。
自动收敛：控制器持续对比 Git 与集群，发现漂移就同步。
持续协调：不是一次性流水线，而是长期运行的 reconcile 循环。

工具	模型	适合
Argo CD	Application/ApplicationSet，UI 强	多团队、多集群、可视化
Flux	GitRepository/Kustomization/HelmRelease	轻量、组合式、与 CI 解耦

10.1.2. Argo CD 最小实验

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd get pods
kubectl -n argocd port-forward svc/argocd-server 8080:443

初始密码：

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d

application-demoapp.yaml

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

prune 删除 Git 中已移除的资源，selfHeal 纠正手工改动。生产环境要配合 SyncWindow、ignoreDifferences 和审批流程，避免自动同步把误提交直接放大。

10.1.3. App-of-Apps 与 Sync Waves

一个 Application 管一个应用；一个 ApplicationSet 或 app-of-apps 管一组应用。常见顺序：

00-crds → 01-namespaces → 02-rbac → 03-operators → 10-apps → 20-ingress

用 argocd.argoproj.io/sync-wave 注解控制顺序，数值小的先同步。数据库迁移、CRD、Operator 必须排在使用它们的应用之前；否则会出现「应用先起、CRD 未安装」的循环。

10.1.4. Argo Rollouts 金丝雀

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
kubectl argo rollouts version

rollout-demoapp.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demoapp
spec:
  replicas: 5
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
        - name: demoapp
          image: ikubernetes/demoapp:v1.0
          ports:
            - containerPort: 80
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: {duration: 2m}
        - setWeight: 50
        - pause: {duration: 2m}
        - setWeight: 100

kubectl argo rollouts get rollout demoapp --watch
kubectl argo rollouts set image demoapp demoapp=ikubernetes/demoapp:v2.0
kubectl argo rollouts promote demoapp
kubectl argo rollouts abort demoapp

没有指标分析的 canary 只是「慢一点的全量发布」。生产环境要接 Prometheus 分析模板，按错误率/延迟自动 promote 或 abort。

10.1.5. Flux 的差异

Flux 用 GitRepository 拉取仓库，用 Kustomization 或 HelmRelease 描述部署；它更像一组可组合的控制器，UI 不是核心。多租户场景常用 Flux 的 Kustomization 隔离命名空间与权限。

选择建议：需要强 UI、多团队自助、ApplicationSet 批量管理，选 Argo CD；需要轻量、GitOps 与 CI 解耦、控制器组合，选 Flux。

10.1.6. 验证清单

Argo CD/Flux 能拉取 Git 仓库并显示 Synced/Healthy。
手工改一个副本数，控制器能自动纠正（selfHeal）。
Git 删除资源后，prune 能清理集群资源。
Sync Waves 顺序正确，CRD/Operator 先于应用。
Rollout 能按权重暂停、promote、abort。
发布失败时能在 5 分钟内回滚到上一版本。

10.1.7. 排错表

现象	原因	处理
`ComparisonError`	仓库/路径/分支错误	检查 repoURL、path、targetRevision
`OutOfSync` 不收敛	手动改动 / webhook 改资源	开 selfHeal，配置 ignoreDifferences
`SyncFailed`	CRD 未安装 / RBAC 不足	调整 sync-wave、检查 ServiceAccount
Rollout 卡在 pause	没有 promote / 分析失败	`argo rollouts promote` 或查 AnalysisRun
删除资源被重建	prune 未开 / finalizer	检查 syncPolicy 与资源 owner

10.1.8. 进阶挑战

用 ApplicationSet 为三个环境生成 Application。
把 Helm Chart 作为 Argo CD 的 source，并通过 values 覆盖环境差异。
给 Rollout 接 Prometheus 分析，错误率超过 1% 自动 abort。
用 Flux 实现同样的部署，比较两者的可观测性与权限模型。

10.1.9. 小结

GitOps 的约束是「Git 是唯一事实源」，工具只是实现方式。
Argo CD 强在 UI/多团队，Flux 强在组合与轻量。
渐进式发布必须绑定指标与回滚，否则只是延迟切换。
交付链路要把 CI、GitOps、Rollouts 的职责分开。