3. 安装与部署:Helm Chart 安装 Argo CD、命名空间规划、高可用部署模式选择
在生产环境中部署 Argo CD 时,安装方式、命名空间隔离策略以及高可用模式的选择直接决定了平台的稳定性与运维成本。本章将围绕 Helm Chart 安装、多环境命名空间规划以及高可用架构选型三个核心维度展开,提供可直接落地的部署方案。
3.1 使用 Helm Chart 安装 Argo CD
Argo CD 官方维护的 Helm Chart 是生产部署的首选方式。它提供了丰富的参数化配置能力,支持自定义镜像仓库、Ingress 控制器、TLS 证书以及高可用开关。
3.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 -10
版本锁定建议: 生产环境务必锁定 Chart 版本与 AppVersion,避免自动升级导致配置不兼容。推荐使用
helm pull 下载 Chart 后离线部署。
3.1.2 基础安装命令
# 创建命名空间
kubectl create namespace argocd
# 使用 Helm 安装(单副本模式,适用于测试环境)
helm install argocd argo/argo-cd \
--namespace argocd \
--set server.service.type=LoadBalancer \
--set configs.params."server\.insecure"=true
3.1.3 关键 values 参数速查表
| 参数路径 | 默认值 | 生产推荐值 | 说明 |
|---|---|---|---|
server.replicas |
1 | 2 或 3 | API Server 副本数,高可用必备 |
repoServer.replicas |
1 | 2 或 3 | 仓库服务副本数,影响 Git 同步吞吐 |
applicationSet.replicas |
1 | 2 | ApplicationSet 控制器副本 |
redis.enabled |
true | true | 内置 Redis,高可用需搭配 sentinel |
configs.params.server.insecure |
false | false | 生产环境应启用 TLS |
global.image.repository |
quay.io/argoproj/argocd | 私有仓库地址 | 离线环境需替换 |
3.2 命名空间规划策略
合理的命名空间规划能够实现租户隔离、资源配额管理以及运维权限的精细化控制。推荐采用“双层命名空间”模型:系统命名空间 与 业务命名空间。
3.2.1 推荐命名空间布局
| 命名空间 | 用途 | 资源配额 | 访问权限 |
|---|---|---|---|
argocd |
Argo CD 核心组件 | 高优先级,预留资源 | 仅平台管理员 |
argocd-rbac |
RBAC 配置与审计日志 | 中等 | 平台管理员 + 审计 |
team-{name} |
业务团队工作负载 | 按团队配额 | 团队管理员 |
shared-services |
共享中间件(Redis、DB) | 中等 | 平台管理员 |
3.2.2 命名空间隔离最佳实践
- 禁止在
argocd命名空间内部署业务应用,避免组件间资源争抢。 - 使用
NetworkPolicy限制argocd命名空间只允许 Ingress 控制器和集群内部 API Server 访问。 - 为每个业务命名空间创建独立的
ResourceQuota和LimitRange,防止单个团队耗尽集群资源。 - 通过 Argo CD 的
Project资源绑定目标命名空间,实现 GitOps 粒度的权限控制。
避坑提示: 不要将 Argo CD 的 Secret 与业务应用的 Secret 混放在同一命名空间。Argo CD 的
argocd-secret 包含管理员密码和签名密钥,应严格限制访问。
3.3 高可用部署模式选择
Argo CD 的高可用部署并非简单的“多副本 + 负载均衡”,需要根据集群规模、故障域以及运维能力选择不同的模式。以下对比三种主流模式。
3.3.1 高可用模式对比
| 模式 | 副本数 | Redis 架构 | 故障恢复时间 | 适用场景 |
|---|---|---|---|---|
| 单副本模式 | 1 | 单实例 | 分钟级(需重建 Pod) | 开发/测试环境 |
| 多副本 + 内置 Redis | 2~3 | 主从 + Sentinel | 秒级(自动故障转移) | 中小规模生产(节点 < 50) |
| 多副本 + 外部 Redis 集群 | 3+ | Redis Cluster / 托管的 Redis | 秒级(独立高可用) | 大规模生产(节点 > 50) |
3.3.2 高可用部署参数示例(多副本 + 内置 Redis Sentinel)
# ha-values.yaml
server:
replicas: 3
autoscaling:
enabled: false # 生产建议固定副本,避免 HPA 抖动
repoServer:
replicas: 3
applicationSet:
replicas: 2
redis:
enabled: true
architecture: replication # 主从模式
master:
persistence:
enabled: true
size: 10Gi
replica:
replicaCount: 2
persistence:
enabled: true
size: 10Gi
sentinel:
enabled: true
replicas: 3
configs:
params:
server.insecure: false # 生产必须启用 TLS
3.3.3 高可用架构示意图
3.4 部署验证与健康检查
安装完成后,执行以下命令验证组件状态:
# 检查所有 Pod 是否 Running
kubectl get pods -n argocd
# 查看 Service 端点
kubectl get svc -n argocd
# 获取初始管理员密码
kubectl -n argocd get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d
# 端口转发访问 UI(本地调试)
kubectl port-forward svc/argocd-server -n argocd 8080:443
健康检查清单:
- 所有组件 Pod 的
READY列显示为1/1或2/2(根据副本数)。 - Redis Sentinel 的
sentinel master mymaster命令返回正确的 Master 地址。 - 通过 UI 或 CLI 执行
argocd app list无超时或连接拒绝错误。 - Ingress 配置的域名可正常访问,TLS 证书未过期。
3.5 生产部署决策树
根据集群规模与可靠性要求,参考以下决策路径选择部署模式:
3.6 常见部署问题与排查
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Pod 启动后 CrashLoopBackOff | Redis 连接失败或 Secret 缺失 | 检查 argocd-secret 是否存在,确认 Redis Service 名称与端口 |
| UI 返回 502 Bad Gateway | Ingress 配置错误或 Server 未就绪 | 检查 Ingress 注解与后端 Service 端口(443/80) |
| Git 同步超时 | Repo Server 资源不足或网络延迟 | 增加 Repo Server 的 CPU/内存限制,或配置 SSH 持久连接 |
| Redis Sentinel 选举失败 | Sentinel 数量不足或网络分区 | 确保 Sentinel 副本数为奇数(至少 3),检查 Pod 间网络连通性 |
快速诊断命令: 使用
kubectl logs -n argocd <pod-name> --tail=50 查看组件日志,重点关注 level=error 或 level=warning 条目。Redis 相关错误通常包含 redis: connection refused 关键字。