第 8/18 天引言从”推式部署”到”拉式同步”的范式转变在前七天的实战中我们依次完成了 K8s 集群搭建、Harbor 私有镜像仓库部署、GitLab CE 自托管、GitLab Runner 配置、CI 流水线搭建以及 Harbor 镜像版本管理。至此持续集成CI侧的管道已经打通——代码提交后会自动触发 Kaniko 构建并推送到 Harbor。但一个完整的 DevOps 管道还需要持续交付CD这一环如何把 Harbor 里的新镜像安全、可追溯、可回滚地发布到 K8s 集群传统的做法是在 CI 流水线末尾直接kubectl apply或调用 Helm 部署这属于”推式Push部署”。它的痛点在于部署状态分散在各个流水线日志里、谁在什么时候改了什么资源难以审计、回滚靠记忆和手工操作。GitOps则把 Git 仓库作为基础设施和应用配置的”唯一事实来源”Single Source of Truth由集群内的控制器持续”拉取” Git 仓库的声明式配置并与集群实际状态对账任何差异都会被自动纠正或告警。今天我们要部署的Argo CD就是 CNCF 毕业项目中最主流的 GitOps 控制器之一。本篇将完成 Argo CD 的安装、CLI 配置、Web UI 访问以及 GitOps 配置仓库的创建与首次应用同步为后续 CI/CD 联动打好基础。核心概念Argo CD 与 GitOps 工作模型什么是 GitOpsGitOps 由 Weaveworks 在 2017 年提出其四大核心原则是声明式描述整个系统的期望状态以声明式YAML/Helm/Kustomize描述而非过程式脚本。版本控制且变更审计所有配置存储在 Git 仓库每次变更都有 commit 记录可追溯、可审查、可回滚。自动拉取并应用集群内的控制器主动拉取 Git 仓库的变更并应用到集群而非外部 CI 系统推送。持续对账与告警控制器持续比较 Git 期望状态与集群实际状态即Drift Detection出现偏差时自动纠正或发出告警。Argo CD 架构简介Argo CD 是一个专为 Kubernetes 设计的 GitOps 持续交付工具其核心架构包括API Server提供 gRPC/REST API供 Web UI 和 CLI 交互。Repository Server内部服务负责克隆 Git 仓库并缓存配置文件生成渲染后的清单。Application Controller核心对账引擎定期比较 Git 中的期望状态与集群中的实际状态并触发 Sync 操作。Redis缓存服务加速状态查询。Dex可选身份认证中间件支持 SSO 集成。GitOps 仓库的三种主流结构结构说明适用场景单仓库单环境所有配置在一个仓库按目录区分环境小团队、单一集群单仓库多环境一个仓库内dev/、staging/、prod/分目录中等规模多环境应用仓库 配置仓库分离应用源码在 A 仓库部署清单在 B 仓库生产级职责分离本系列采用应用仓库 配置仓库分离模式配置仓库即 GitOps 仓库。实战步骤Argo CD 部署与配置仓库创建步骤一创建 GitOps 配置仓库在 GitLab 中新建一个名为gitops-manifests的仓库作为 Argo CD 的配置来源。该仓库将存放所有应用的 K8s 声明式清单。 代码示例# 在 GitLab Web UI 创建空仓库 gitops-manifests 后克隆到本地git clone gitgitlab.stellardata.top:devops/gitops-manifests.gitcd gitops-manifests# 创建目录结构按环境 应用组织mkdir -p apps/guestbook/devmkdir -p apps/guestbook/prodmkdir -p projects# 初始化 READMEcat README.md ‘EOF’# GitOps 配置仓库本仓库作为 Argo CD 的 Single Source of Truth存放所有应用的 Kubernetes 声明式清单。## 目录结构– apps/// 按应用和环境划分的部署清单– projects/ Argo CD AppProject 定义EOFgit add . git commit -m “init: gitops-manifests 仓库初始化”git push origin main步骤二准备示例应用清单在配置仓库中放入一个简单的示例应用用于验证 Argo CD 的同步能力 代码示例# apps/guestbook/dev/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: guestbooknamespace: devlabels:app: guestboyspec:replicas: 2selector:matchLabels:app: guestboytemplate:metadata:labels:app: guestboyspec:containers:– name: guestboyimage: harbor.stellardata.top/library/guestboy:v1.0.0ports:– containerPort: 3000resources:requests:cpu: 100mmemory: 128Milimits:cpu: 250mmemory: 256Mi—apiVersion: v1kind: Servicemetadata:name: guestboynamespace: devspec:selector:app: guestboyports:– port: 80targetPort: 3000type: ClusterIP 代码示例# apps/guestbook/dev/namespace.yamlapiVersion: v1kind: Namespacemetadata:name: devlabels:managed-by: argocd 代码示例git add . git commit -m “feat: 添加 guestboy dev 环境部署清单”git push origin main步骤三安装 Argo CDArgo CD 官方提供命名空间安装方式。我们将其部署到argocd命名空间 代码示例# 创建命名空间kubectl create namespace argocd# 使用官方 Helm Chart 安装推荐生产环境使用 Helm 管理配置helm repo add argo https://argoproj.github.io/argo-helmhelm repo updatehelm install argocd argo/argo-cd–namespace argocd–version 7.7.0–set server.service.typeNodePort–set server.service.nodePortHttp30080–set configs.cm.application.instanceLabelKeyargocd.argoproj.io/instance–set server.extensions.enabledtrue# 查看 Pod 状态等待全部 Runningkubectl get pods -n argocd -w# 输出示例# NAME READY STATUS RESTARTS AGE# argocd-application-controller-0 1/1 Running 0 90s# argocd-redis-xxxx 1/1 Running 0 90s# argocd-repo-server-xxxx 1/1 Running 0 90s# argocd-server-xxxx 1/1 Running 0 90s安装完成后获取初始管理员密码 代码示例# Argo CD 1.9 使用 Secret 存储初始密码kubectl -n argocd get secret argocd-initial-admin-secret-o jsonpath“{.data.password}” | base64 -d ; echo# 输出示例AbCdEf123456步骤四安装 Argo CD CLI 并登录 代码示例# 下载 Argo CD CLILinux amd64curl -sSL -o /usr/local/bin/argocdhttps://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64chmod x /usr/local/bin/argocd# 验证版本argocd version# 登录 Argo CDadmin / 上一步获取的密码argocd login localhost:30080–username admin–password AbCdEf123456–insecure# 出现 “admin logged in successfully” 即成功# 修改默认密码生产环境必须修改argocd account update-password–current-password AbCdEf123456–new-password ‘YourStrong#Pass2026’步骤五通过 CLI 创建第一个 Argo CD ApplicationArgo CD Application 是核心 CRD它定义了”从哪个 Git 仓库的哪个目录同步到哪个集群命名空间”。 代码示例# argocd-guestboy-app.yamlapiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: guestboy-devnamespace: argocdfinalizers:– resources-finalizer.argocd.argoproj.iospec:project: defaultsource:repoURL: gitgitlab.stellardata.top:devops/gitops-manifests.gittargetRevision: mainpath: apps/guestboy/devdestination:server: https://kubernetes.default.svcnamespace: devsyncPolicy:automated:prune: true # Git 中删除资源时自动从集群中删除selfHeal: true # 检测到 Drift 时自动恢复到 Git 期望状态syncOptions:– CreateNamespacetrue # 目标命名空间不存在时自动创建 代码示例# 应用 Application 资源kubectl apply -f argocd-guestboy-app.yaml -n argocd# 查看 Application 状态argocd app get guestboy-dev# 关键字段# Health Status: Healthy# Sync Status: Synced# 对应的 Deployment、Service 资源已在 dev 命名空间创建# 查看集群实际资源kubectl get all -n dev步骤六通过 Web UI 验证同步效果Argo CD 的 Web UI 提供了直观的可视化拓扑能清晰展示应用资源的层级关系和健康状态。 代码示例# 端口转发访问 Web UI本地访问kubectl port-forward svc/argocd-server -n argocd 8080:443# 浏览器访问 https://localhost:8080# 使用 admin 账号登录后可看到# 1. guestboy-dev 应用卡片# 2. 资源拓扑树Deployment → ReplicaSet → Pod# 3. Sync 状态为 SyncedHealth 状态为 Healthy在 Web UI 中点击guestboy-dev可以展开资源树查看每个资源的实时状态。绿色表示健康黄色表示进行中红色表示异常。这种可视化对排障极其友好——当某个 Pod 起不来时UI 会直接标红并提示原因。步骤七验证 GitOps 自动对账能力GitOps 的核心价值在于”声明即真相”。我们来测试 selfHeal 自动纠正能力 代码示例# 手动修改集群中的副本数模拟人工误操作kubectl scale deployment guestboy -n dev –replicas5# 几秒内 Argo CD 检测到 Drift自动回滚到 Git 中声明的 replicas:2kubectl get deployment guestboy -n dev -w# 查看同步事件argocd app sync-history guestboy-dev在syncPolicy.automated.selfHeal: true配置下任何对集群资源的”手动篡改”都会被自动纠正回 Git 仓库中的期望值。这就是 GitOps”Git 即真相”的威力。常见问题Q1Argo CD 连接私有 GitLab 仓库报权限错误Argo CD 默认使用 HTTPS 方式访问 Git 仓库。对于自托管 GitLab 私有仓库需要配置 Repository Credential 代码示例# 方式一使用 Personal Access Tokenargocd repo add https://gitlab.stellardata.top/devops/gitops-manifests.git–username deploy-token–password–name gitops-repo# 方式二使用 SSH Key生产推荐# 先创建 Secret 存放私钥kubectl create secret generic gitlab-ssh-key-n argocd–from-filesshPrivateKey/root/.ssh/id_ed25519# 然后通过 Argo CD CRD 配置仓库凭证或通过 UI 添加配置完成后在 Web UI 的 Settings → Repositories 中能看到Connected状态。Q2Argo CD Sync 卡在 OutOfSync 不自动同步最常见原因是缺少syncPolicy.automated配置或automated下未启用prune。检查 Application spec 代码示例argocd app get guestboy-dev | grep -A5 “Sync Policy”# 如果 Sync Policy 为 需添加 automated 配置Q3生产环境是否该开启 selfHealselfHeal: true适合 dev/test 环境能保证集群始终与 Git 一致。但在生产环境如果运维人员需要紧急手工扩容以应对流量突发selfHeal 会立刻回滚这个操作。生产环境通常设selfHeal: false仅在 Argo CD 中标记 Drift 并告警由人工决策是否同步。总结本篇完成了 GitOps 范式的核心工具 Argo CD 的全流程部署概念层面理解了 GitOps 的四大原则与 Push/CD 模式的区别认识到 Git 作为 Single Source of Truth 的价值。仓库层面创建了gitops-manifests配置仓库按应用 环境组织目录结构并放入了示例应用清单。部署层面通过 Helm 在argocd命名空间安装 Argo CD配置 NodePort 暴露 Web UI。配置层面安装 CLI、登录、修改密码、创建第一个 Application CRD。验证层面通过 CLI 和 Web UI 双重验证了应用的自动同步与 selfHeal 自动对账能力。至此我们的 DevOps 管道在 CD 侧具备了”Git 变更 → Argo CD 检测 → 自动同步到集群”的能力。但 Argo CD 目前还需要手动触发同步或依赖 automated 策略真正的全链路闭环需要让 CIGitLab 构建推镜像与 CDArgo CD 同步形成联动——CI 完成后自动更新 GitOps 仓库中的镜像 Tag从而触发 Argo CD 同步。这正是明天的核心主题。下期预告第 9 天CI 与 CD 联动从代码提交到部署的全自动闭环——我们将打通 GitLab CI 与 Argo CD实现”代码提交 → Kaniko 构建镜像 → 自动更新 GitOps 仓库镜像 Tag → Argo CD 自动同步部署”的完整无人值守闭环。系列大纲全链路架构总览从代码提交到灰度发布的完整管道设计K8s 集群与网络基础kubeadm 离线部署与 Cilium 网络插件Harbor 私有镜像仓库部署与验证Helm 安装与镜像推送GitLab CE 自托管部署代码仓库与项目管理平台GitLab Runner 配置K8s Executor 与 RBAC 权限设置GitLab CI 流水线搭建.gitlab-ci.yml 与 Kaniko 无守护进程构建Harbor 镜像版本管理与 Tag 策略配置Argo CD 部署与 GitOps 配置仓库创建今天CI 与 CD 联动从代码提交到部署的全自动闭环Prometheus 部署kube-prometheus-stack 与 ServiceMonitor 指标采集Grafana 看板搭建K8s 标准面板与自定义业务看板告警规则与 Alertmanager钉钉/邮件通知渠道配置Argo Rollouts 安装与基础概念CRD 与 Rollout 资源定义金丝雀发布实战setWeight 流量分割与 pause 步骤AnalysisTemplate 指标分析与自动回滚机制全链路端到端演示代码提交→构建→灰度→监控→告警完整流程生产化加固要点Harbor/GitLab/Argo CD 高可用方案供应链安全闭环Trivy 扫描 cosign 签名 Kyverno 验签