4. GitOps 基础:ArgoCD 的安装与配置,连接多集群,理解 Application 与 Project 概念
4.1 GitOps 与 ArgoCD 概述
GitOps 是一种以 Git 仓库作为单一事实来源(Single Source of Truth)的运维模式。集群的期望状态声明在 Git 仓库中,由 Operator 自动同步至目标集群,从而实现声明式部署、版本回滚与审计追踪。ArgoCD 是 CNCF 毕业项目,也是目前最流行的 Kubernetes GitOps 工具。
核心原则: Git 仓库中的声明式配置 = 集群期望状态;ArgoCD 持续对比实际状态与期望状态,自动或手动修复漂移。
4.2 ArgoCD 安装
推荐使用 kubectl 或 Helm 在集群中安装 ArgoCD。以下为生产环境常用方式:
4.2.1 使用 Helm 安装(推荐)
# 添加 Helm 仓库
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
# 创建命名空间
kubectl create namespace argocd
# 安装 ArgoCD(包含 CRD、Server、Repo Server、Application Controller、Redis)
helm install argocd argo/argo-cd \
--namespace argocd \
--set server.service.type=LoadBalancer \
--set configs.params."server\.insecure"=true
4.2.2 使用 kubectl 安装(快速验证)
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
4.2.3 获取初始密码
kubectl -n argocd get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d
提示: 生产环境建议使用 LoadBalancer 或 Ingress 暴露 ArgoCD Server,并配置 TLS 证书。默认密码仅用于首次登录,登录后应立即修改。
4.3 连接多集群
ArgoCD 支持通过 argocd cluster add 命令将多个 Kubernetes 集群注册为管理目标。每个集群对应一个 Cluster Secret,存储在 ArgoCD 所在集群的 argocd 命名空间中。
4.3.1 添加集群步骤
- 准备目标集群 kubeconfig: 确保本地 kubeconfig 中包含目标集群的 context。
- 执行添加命令:
# 列出当前 context
kubectl config get-contexts
# 添加集群(使用 context 名称)
argocd cluster add <target-context-name> --name <cluster-display-name>
4.3.2 多集群管理清单
| 集群角色 | 说明 | 典型用途 |
|---|---|---|
| 控制集群(Control Plane) | 安装 ArgoCD 的集群 | 运行 ArgoCD 组件,管理所有目标集群 |
| 目标集群(Target Cluster) | 被 ArgoCD 管理的集群 | 部署业务应用、基础设施组件 |
| 本地集群(in-cluster) | ArgoCD 所在集群自身 | 默认注册,用于管理控制集群上的资源 |
注意: 添加集群时,ArgoCD 会在目标集群创建
argocd-manager ServiceAccount 并绑定 cluster-admin 权限。生产环境应限制该 ServiceAccount 的 RBAC 范围,遵循最小权限原则。
4.4 Application 概念
Application 是 ArgoCD 的核心资源,定义了一个应用从 Git 仓库到 Kubernetes 集群的完整部署路径。每个 Application 包含三个关键要素:
- Source(源): Git 仓库地址、分支、路径,以及 Helm/Kustomize 参数。
- Destination(目标): 目标集群 URL 或名称、目标命名空间。
- Sync Policy(同步策略): 自动/手动同步、自动修剪、自动自愈。
4.4.1 Application YAML 示例
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
4.5 Project 概念
Project 是 ArgoCD 中的逻辑隔离单元,用于对 Application 进行分组和权限控制。一个 Project 可以包含多个 Application,并限制其可访问的 Git 仓库、目标集群和命名空间。
4.5.1 Project 核心能力
| 能力 | 描述 | 示例 |
|---|---|---|
| 仓库白名单 | 限制 Project 下 Application 只能引用指定的 Git 仓库 | https://github.com/my-org/* |
| 目标集群白名单 | 限制 Application 只能部署到指定的集群 | https://cluster-prod.example.com:6443 |
| 命名空间白名单 | 限制 Application 只能部署到指定的命名空间 | default, production-* |
| RBAC 集成 | 与 ArgoCD RBAC 结合,控制用户对 Project 的访问权限 | role: admin |
4.5.2 Project YAML 示例
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: production
namespace: argocd
spec:
description: Production project for business applications
sourceRepos:
- 'https://github.com/my-org/production-apps.git'
destinations:
- namespace: 'production-*'
server: 'https://kubernetes.default.svc'
- namespace: 'production-*'
server: 'https://cluster-prod-east.example.com:6443'
clusterResourceWhitelist:
- group: ''
kind: Namespace
roles:
- name: admin
description: Admin privileges for production project
policies:
- p, proj:production:admin, applications, *, production/*, allow
4.6 Application 与 Project 的关系
下图展示了 ArgoCD 中 Application、Project、Git 仓库与多集群之间的逻辑关系:
4.7 多集群 Application 部署示例
以下示例展示如何通过一个 Project 管理部署到两个不同集群的 Application:
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: multi-cluster-demo
namespace: argocd
spec:
sourceRepos:
- 'https://github.com/my-org/app-config.git'
destinations:
- namespace: 'app-*'
server: 'https://cluster-prod.example.com:6443'
- namespace: 'app-*'
server: 'https://cluster-staging.example.com:6443'
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-prod
namespace: argocd
spec:
project: multi-cluster-demo
source:
repoURL: https://github.com/my-org/app-config.git
targetRevision: main
path: overlays/production
destination:
server: https://cluster-prod.example.com:6443
namespace: app-frontend
syncPolicy:
automated:
prune: true
selfHeal: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-staging
namespace: argocd
spec:
project: multi-cluster-demo
source:
repoURL: https://github.com/my-org/app-config.git
targetRevision: main
path: overlays/staging
destination:
server: https://cluster-staging.example.com:6443
namespace: app-frontend
syncPolicy:
automated:
prune: true
selfHeal: true
4.8 版本漂移校准机制
ArgoCD 通过持续对比 Git 仓库中的期望状态与集群实际状态,检测并修复版本漂移。校准流程如下:
- 状态对比: Application Controller 定期(默认 3 分钟)拉取 Git 仓库最新配置,并与集群资源进行 Diff。
- 漂移检测: 当集群资源与 Git 配置不一致时,ArgoCD 将 Application 状态标记为
OutOfSync。 - 自动修复: 若启用
selfHeal: true,ArgoCD 自动将集群状态回滚至 Git 中定义的期望状态。 - 手动干预: 运维人员可通过 ArgoCD UI 或 CLI 执行
argocd app sync手动触发同步。
最佳实践: 在多集群场景下,建议为每个集群创建独立的 Application,并统一引用同一 Git 仓库的不同分支或目录。通过 Project 的 destination 白名单确保每个 Application 只能部署到授权的集群,从而避免配置泄露。