4. Argo CD 安装与高可用配置:Helm 安装 Argo CD,配置多副本、HPA、Pod Disruption Budget

在生产环境中,Argo CD 作为 GitOps 的核心控制面,其自身的稳定性直接决定了集群交付的可靠性。本章将基于 Helm Chart 完成 Argo CD 的安装,并围绕多副本、HPA 和 PDB 三个维度构建高可用控制面,确保在节点故障、流量突发或计划维护期间,Argo CD 的 API Server、Repo Server 和 Application Controller 均能持续提供服务。

4.1 使用 Helm 安装 Argo CD

Argo CD 官方维护的 Helm Chart 是生产部署的首选方式。它提供了完整的参数化配置能力,支持组件级资源控制、网络策略、证书注入以及高可用拓扑。

4.1.1 添加 Helm 仓库与版本选择

# 添加 Argo CD 官方 Helm 仓库
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

# 查看可用版本,建议选择最新的稳定版本
helm search repo argo/argo-cd --versions --devel | head -5
版本锁定建议: 生产环境务必锁定 Chart 版本与 App Version,避免自动升级引入不兼容变更。建议将 Chart 下载到本地 Git 仓库进行版本管理。

4.1.2 高可用安装命令

以下命令直接启用多副本、HPA 和 PDB 的核心配置,适用于生产集群。

helm upgrade --install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set redis.enabled=true \
  --set redis-ha.enabled=false \
  --set controller.replicas=2 \
  --set server.replicas=2 \
  --set repoServer.replicas=2 \
  --set controller.autoscaling.enabled=true \
  --set controller.autoscaling.minReplicas=2 \
  --set controller.autoscaling.maxReplicas=5 \
  --set controller.autoscaling.targetCPUUtilizationPercentage=70 \
  --set server.autoscaling.enabled=true \
  --set server.autoscaling.minReplicas=2 \
  --set server.autoscaling.maxReplicas=5 \
  --set server.autoscaling.targetCPUUtilizationPercentage=70 \
  --set repoServer.autoscaling.enabled=true \
  --set repoServer.autoscaling.minReplicas=2 \
  --set repoServer.autoscaling.maxReplicas=5 \
  --set repoServer.autoscaling.targetCPUUtilizationPercentage=70 \
  --set controller.pdb.enabled=true \
  --set controller.pdb.minAvailable=1 \
  --set server.pdb.enabled=true \
  --set server.pdb.minAvailable=1 \
  --set repoServer.pdb.enabled=true \
  --set repoServer.pdb.minAvailable=1 \
  --set global.securityContext.runAsNonRoot=true \
  --set global.podSecurityContext.fsGroup=999
注意: 如果集群规模较大(管理超过 500 个 Application),建议将 Redis 替换为 Redis-HA 模式,避免单点 Redis 成为性能瓶颈。此时需设置 redis-ha.enabled=true 并关闭 redis.enabled。

4.2 多副本架构与组件角色

Argo CD 由三个核心组件构成,每个组件在高可用部署中承担不同职责。下表列出各组件在多副本模式下的关键行为。

组件 默认端口 多副本模式 会话亲和性要求 存储依赖
API Server 443 (gRPC/HTTPS) 无状态,前端负载均衡 否(JWT 令牌认证) 无
Repo Server 8081 无状态,缓存共享 否 Redis 缓存
Application Controller 8082 主备模式(Leader Election) 不适用 Redis + Kubernetes API
关键理解: Application Controller 使用 Leader Election 机制,同一时刻只有一个副本执行应用同步和状态检测。多副本仅提供故障转移能力,不提升同步吞吐量。API Server 和 Repo Server 则是完全无状态的,可以通过 HPA 水平扩展以应对 API 请求和 Git 仓库操作的压力。
Argo CD 高可用组件架构 外部流量 / Ingress API Server (副本 1) API Server (副本 2) API Server (副本 N) Repo Server (副本 1) Repo Server (副本 2) Repo Server (副本 N) Controller (Leader) Controller (Follower) Redis 缓存 (状态共享) API Server / Repo Server 无状态可水平扩展 | Controller 主备模式依赖 Leader Election

4.3 配置 Pod Disruption Budget (PDB)

PDB 确保在集群节点进行计划内维护(如内核升级、节点池缩容)时,Argo CD 的关键组件不会同时全部不可用。对于每个组件,我们设置 minAvailable 为 1,保证至少有一个副本能够持续提供服务。

4.3.1 PDB 配置清单

# Application Controller PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: argocd-application-controller-pdb
  namespace: argocd
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-application-controller

# API Server PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: argocd-server-pdb
  namespace: argocd
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server

# Repo Server PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: argocd-repo-server-pdb
  namespace: argocd
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-repo-server
PDB 与 HPA 协同: 当 HPA 缩容时,PDB 不会阻止缩容操作。PDB 仅阻止由 kubectl drain 或节点池缩容触发的主动驱逐。如果 HPA 缩容导致副本数低于 minAvailable,PDB 不会生效,因为缩容是控制器主动删除 Pod,而非节点驱逐。

4.4 配置 Horizontal Pod Autoscaler (HPA)

HPA 基于 CPU 利用率自动调整副本数,应对 Git 仓库操作高峰或 API 请求突发。以下为三个组件分别配置 HPA 的 YAML 示例。

4.4.1 HPA 配置清单

# Application Controller HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: argocd-application-controller-hpa
  namespace: argocd
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: argocd-application-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

# API Server HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: argocd-server-hpa
  namespace: argocd
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: argocd-server
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

# Repo Server HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: argocd-repo-server-hpa
  namespace: argocd
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: argocd-repo-server
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4.4.2 HPA 参数调优建议

参数 推荐值 说明
minReplicas 2 保证基础冗余,避免单点故障
maxReplicas 5~10 根据集群规模调整,管理 1000+ Application 时可适当提高
averageUtilization 70% 预留 30% 的 CPU 余量应对突发流量
behavior.scaleDown.stabilizationWindowSeconds 300 防止频繁缩容导致抖动,建议设置 5 分钟冷却窗口
HPA 与 PDB 协同工作流程 Metrics Server HPA Controller Deployment / RS 节点驱逐 / Drain PDB 准入检查 Pod 驱逐 / 保留 HPA 根据 CPU 利用率调整副本数,不受 PDB 限制 PDB 仅在节点驱逐(kubectl drain)时生效,阻止 Pod 同时被驱逐 两者协同:HPA 保证弹性,PDB 保证计划内维护的可用性

4.5 验证高可用配置

安装完成后,执行以下验证步骤确保高可用配置生效。

  1. 检查 Pod 状态与副本数: kubectl get pods -n argocd,确认每个 Deployment 的副本数符合预期。
  2. 验证 PDB 是否创建: kubectl get pdb -n argocd,确认三个 PDB 均为 HEALTHY 状态。
  3. 验证 HPA 是否生效: kubectl get hpa -n argocd,确认目标 CPU 利用率与当前副本数。
  4. 模拟节点驱逐测试: 选择一个运行 Argo CD Pod 的节点,执行 kubectl drain <node> --ignore-daemonsets --delete-emptydir-data,观察 PDB 是否阻止了最后一个可用副本的驱逐。
  5. 触发 HPA 扩容测试: 使用 kubectl run -it --rm load-generator --image=busybox -- sh -c "while true; do wget -q -O- http://argocd-server.argocd.svc.cluster.local; done" 模拟 API 请求,观察 HPA 是否自动增加副本。
生产注意事项: 如果集群使用 Cluster Autoscaler,请确保 Argo CD 的 PDB 配置与节点池缩容策略兼容。部分云服务商在缩容节点池时可能忽略 PDB,导致服务中断。建议在测试环境中验证节点池缩容行为。