App Template

• Deploy A Nginx App

Deploy N Clusters

ArgoCD 凭借其声明式的 GitOps 理念，能非常优雅地处理多 Kubernetes 集群的应用发布。它允许你从一个中心化的 Git 仓库管理多个集群的应用部署，确保状态一致并能快速回滚。

下面这张图概括了使用 ArgoCD 进行多集群发布的典型工作流，帮你先建立一个整体印象：

flowchart TD
    A[Git仓库] --> B{ArgoCD Server}
    
    B --> C[ApplicationSet<br>集群生成器]
    B --> D[ApplicationSet<br>Git生成器]
    B --> E[手动Application<br>资源]
    
    C --> F[集群A<br>App1 & App2]
    C --> G[集群B<br>App1 & App2]
    
    D --> H[集群A<br>App1]
    D --> I[集群A<br>App2]
    
    E --> J[特定集群<br>特定应用]

🔗 连接集群到 ArgoCD

要让 ArgoCD 管理外部集群，你需要先将目标集群的访问凭证添加进来。

1. 获取目标集群凭证：确保你拥有目标集群的 kubeconfig 文件。
2. 添加集群到 ArgoCD：使用 ArgoCD CLI 添加集群。这个操作会在 ArgoCD 所在命名空间创建一个存储了集群凭证的 Secret。

   argocd cluster add <context-name> --name <cluster-name> --kubeconfig ~/.kube/config

   • <context-name> 是你 kubeconfig 中的上下文名称。
   • <cluster-name> 是你在 ArgoCD 中为这个集群起的别名。
3. 验证集群连接：添加后，你可以在 ArgoCD UI 的 “Settings” > “Clusters” 页面，或通过 CLI 查看集群列表：

   argocd cluster list

💡 选择多集群部署策略

连接集群后，核心是定义部署规则。ArgoCD 主要通过 Application 和 ApplicationSet 资源来描述部署。

• Application 资源：定义一个应用在特定集群的部署。管理大量集群和应用时，手动创建每个 Application 会很繁琐。
• ApplicationSet 资源：这是实现多集群部署的推荐方式。它能根据生成器（Generators）自动为多个集群或多个应用创建 Application 资源。

上面的流程图展示了 ApplicationSet 的两种主要生成器以及手动创建 Application 的方式。

ApplicationSet 常用生成器对比

🛠️ 配置实践示例

这里以 Cluster Generator 为例，展示一个 ApplicationSet 的 YAML 配置：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-multi-cluster
spec:
  generators:
    - clusters: {} # 自动发现ArgoCD中所有已注册集群
  template:
    metadata:
      name: '{{name}}-my-app'
    spec:
      project: default
      source:
        repoURL: 'https://your-git-repo.com/your-app.git'
        targetRevision: HEAD
        path: k8s-manifests
      destination:
        server: '{{server}}' # 生成器提供的集群API地址
        namespace: my-app-namespace
      syncPolicy:
        syncOptions:
        - CreateNamespace=true # 自动创建命名空间
        automated:
          prune: true # 自动清理
          selfHeal: true # 自动修复漂移

在这个模板中：

• generators 下的 clusters: {} 会让 ArgoCD 自动发现所有已注册的集群。
• 在 template 中，{{name}} 和 {{server}} 是变量，Cluster Generator 会为每个已注册的集群填充它们。
• syncPolicy 下的配置实现了自动同步、自动创建命名空间和资源清理。

⚠️ 多集群管理的关键要点

1. 集群访问权限与网络：确保 ArgoCD 控制平面能够网络连通所有目标集群的 API Server，并具有在目标命名空间中创建资源的 RBAC 权限。
2. 灵活的同步策略：
   • 对于开发环境，可以开启 automated 同步，实现 Git 变更自动部署。
   • 对于生产环境，建议关闭自动同步，采用手动触发同步（Manual）或通过 PR 审批流程，以增加控制力。
3. 高可用与性能：管理大量集群和应用时，考虑高可用（HA）部署。你可能需要调整 argocd-repo-server 和 argocd-application-controller 的副本数和资源限制。
4. 考虑 Argo CD Agent：对于大规模集群管理，可以探索 Argo CD Agent。它将一部分控制平面组件（如 application-controller）分布到托管集群上运行，能提升可扩展性。请注意，截至2025年10月，该功能在 OpenShift GitOps 中仍处于技术预览（Tech Preview） 阶段。

💎 总结

利用 ArgoCD 管理多 Kubernetes 集群应用发布，核心是掌握 ApplicationSet 和 Generators 的用法。通过 Cluster Generator 或 Git Generator，你可以灵活地实现“一次定义，多处部署”。

希望这些信息能帮助你着手搭建多集群发布流程。如果你能分享更多关于你具体环境的信息（比如集群的大致数量和应用的组织结构），或许我可以给出更贴合你场景的建议。

ArgoCD Cheatsheets

• decode passd

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

• relogin

ARGOCD_PASS=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)
MASTER_IP=$(kubectl get nodes --selector=node-role.kubernetes.io/control-plane -o jsonpath='{$.items[0].status.addresses[?(@.type=="InternalIP")].address}')
argocd login --insecure --username admin $MASTER_IP:30443 --password $ARGOCD_PASS

• force delete

argocd app terminate-op <$>

Argo Workflows Cheatsheets

Workflow Template

• DAG Template

Blue–Green Deploy

Argo Rollouts 是一个 Kubernetes CRD 控制器，它通过扩展 Kubernetes 的原生 Deployment 资源，为 Kubernetes 提供了更高级的部署策略。其核心原理可以概括为：通过精细控制多个 ReplicaSet（对应不同版本的 Pod）的副本数量和流量分配，来实现可控的、自动化的应用发布流程。

1. 蓝绿部署原理

蓝绿部署的核心思想是同时存在两个完全独立的环境（蓝色和绿色），但任何时候只有一个环境承载生产流量。

工作原理

1. 初始状态：

   • 假设当前生产环境是 蓝色 版本（v1），所有流量都指向蓝色的 ReplicaSet。
   • 绿色 环境虽然可能存在（例如，副本数为 0），但不接收任何流量。

2. 发布新版本：

   • 当需要发布新版本（v2）时，Argo Rollouts 会创建一个与蓝色环境完全隔离的 绿色 环境 ReplicaSet，并启动全部所需的 Pod 实例。
   • 关键点：此时，用户流量仍然 100% 指向蓝色的 v1 版本。绿色 v2 版本在启动和预热期间，完全不影响线上用户。

3. 测试与验证：

   • 运维人员或自动化脚本可以对绿色的 v2 版本进行测试，例如进行 API 调用、检查日志或运行集成测试。这个过程在生产流量不受干扰的情况下进行。

4. 切换流量：

   • 一旦确认 v2 版本稳定，通过一个原子操作，将所有生产流量从蓝色（v1）瞬间切换到绿色（v2）。
   • 这个切换通常是通过更新 Kubernetes Service 或 Ingress 的 selector 标签来实现的。例如，将 app: my-app 的 selector 从 version: v1 改为 version: v2。

5. 发布后：

   • 流量切换后，绿色（v2）成为新的生产环境。
   • 蓝色（v1）环境不会被立即删除，而是保留一段时间，作为快速回滚的保障。
   • 如果 v2 出现问题，只需将流量再次切回蓝色（v1）即可，回滚过程同样迅速且影响小。

原理示意图

[用户] --> [Service (selector: version=v1)] --> [蓝色 ReplicaSet (v1, 100% 流量)]
                                      |
                                      +--> [绿色 ReplicaSet (v2, 0% 流量， 待命)]

切换后：

[用户] --> [Service (selector: version=v2)] --> [绿色 ReplicaSet (v2, 100% 流量)]
                                      |
                                      +--> [蓝色 ReplicaSet (v1, 0% 流量， 备用回滚)]

优点：发布和回滚速度快、风险低、发布期间服务始终可用。 缺点：需要两倍的硬件资源，在切换瞬间可能会有短暂的流量处理问题（如连接中断）。

2. 金丝雀发布原理

金丝雀发布的核心思想是逐步将流量从旧版本迁移到新版本，而不是一次性切换。这个过程允许在影响一小部分用户的情况下，验证新版本的稳定性和性能。

工作原理

1. 初始状态：

   • 与蓝绿部署类似，当前稳定版本（v1）的 ReplicaSet 承载 100% 的流量。

2. 发布金丝雀版本：

   • Argo Rollouts 创建一个新版本（v2）的 ReplicaSet，但只启动少量 Pod（例如，副本数为总体的 1/10）。
   • 此时，通过 流量治理工具（如 Service Mesh：Istio, Linkerd；或 Ingress Controller：Nginx）的规则，将一小部分生产流量（例如 10%）路由到 v2 的 Pod，其余 90% 的流量仍然流向 v1。

3. 渐进式推广：

   • 这是一个多步骤、自动化的过程。Argo Rollouts 的 Rollout CRD 可以定义一个详细的步骤清单（steps）。
   • 示例步骤：
     • setWeight: 10 - 将 10% 的流量切到 v2，持续 5 分钟。
     • pause: {duration: 5m} - 暂停发布，观察 v2 的运行指标。
     • setWeight: 40 - 如果一切正常，将流量提升到 40%。
     • pause: {duration: 10m} - 再次暂停并观察。
     • setWeight: 100 - 最终将所有流量切换到 v2。

4. 自动化分析与回滚：

   • 这是 Argo Rollouts 最强大的功能之一。在每次暂停（pause）阶段，它会持续查询指标分析服务。
   • 指标分析服务 可以配置一系列规则（AnalysisTemplate），例如：
     • 检查 HTTP 请求错误率是否低于 1%。
     • 检查请求平均响应时间是否小于 200ms。
     • 检查自定义业务指标（如订单失败率）。
   • 如果任何一项指标不达标，Argo Rollouts 会自动中止发布并将流量全部回滚到 v1 版本，无需人工干预。

5. 发布完成：

   • 当所有步骤顺利完成，v2 的 ReplicaSet 将接管 100% 的流量，v1 的 ReplicaSet 最终会被缩容至零。

原理示意图

[用户] --> [Istio VirtualService] -- 90% --> [v1 ReplicaSet]
                     |
                     +-- 10% --> [v2 ReplicaSet (金丝雀)]

（推广中）

[用户] --> [Istio VirtualService] -- 40% --> [v1 ReplicaSet]
                     |
                     +-- 60% --> [v2 ReplicaSet (金丝雀)]

（完成后）

[用户] --> [Istio VirtualService] -- 100% --> [v2 ReplicaSet]

优点：发布风险极低，可以基于真实流量和指标进行自动化验证，实现“无人值守”的安全发布。 缺点：发布流程更长，需要与复杂的流量治理工具集成。

总结与核心价值

Argo Rollouts 的核心原理价值在于：

1. 声明式：像定义 Kubernetes Deployment 一样，通过 YAML 文件声明你的发布策略（蓝绿或金丝雀步骤）。
2. 控制器模式：Argo Rollouts 控制器持续监听 Rollout 对象的状态，并驱动整个系统（K8s API、Service Mesh、Metrics Server）达到声明的目标状态。
3. 扩展性：通过 CRD 和 AnalysisTemplate，它提供了极大的灵活性，可以与任何兼容的流量提供商和指标系统集成。
4. 自动化与安全：将“人脑判断”转化为“基于数据的自动化规则”，极大地提升了发布的可靠性和效率，是实现 GitOps 和持续交付的关键一环。

Argo Rollouts Cheatsheets