下面我给你一篇较系统、较深入的 “GitOps 实战：Argo CD + Tekton 打造云原生 CI/CD 流水线” 的讲解和示例流程。你可以把它作为笔记或实操指南，根据你的环境（比如 Kubernetes 集群、云提供商、镜像仓库等）稍作调整即可。

一、概念与总体架构

在进入实战之前，我们先明确几个关键概念与整体架构思路。

1. GitOps、CI、CD 的角色分界

  • CI（Continuous Integration，持续集成）：负责代码变更后的构建、测试、打包、推送镜像等“构建阶段”的流程。
  • CD（Continuous Delivery / Deployment，持续交付 / 持续部署）：负责把代码产物（通常是镜像 + Kubernetes 资源声明）部署到目标环境。
  • GitOps：把 Git 仓库作为“单一可信源”（Single Source of Truth），通过工具自动对比 Git 中的状态与集群实际状态，做到自动同步、回滚、审计等功能。
    • 在 GitOps 架构下，应用的 K8s 资源声明（YAML / Helm / Kustomize 等）通常保存在一个或多个 Git 仓库中。
    • CD 工具（如 Argo CD）会持续监控这些 Git 仓库（或相关分支 / 路径）变化，一旦变更自动同步到 Kubernetes 集群。
    • 当集群状态偏离 Git 的声明时，自动回滚或校正（drift detection & remediation）。

在这个体系里，Tekton 用作 CI 阶段：触发、构建、测试、打镜像、推镜像、更新 manifest 等操作。Argo CD 则用作 CD / GitOps 同步阶段：从 Git 抓取资源声明、同步部署、监控状态、回滚等。

这个分工正好符合 “把 CI 和 CD 责任分离” 的设计思路。很多实战教程也都是这么做的。比如 OpenShift 的 workshop 就明确：Tekton 做 CI 部分，Argo 做 CD 部分。(demo.openshift.com)
也有不少社区实战例子展示这套组合。(Medium)

二、总体架构示意 & 仓库设计

在实操之前，我们先设计好整体工作流和 Git 仓库布局，这样部署时更有条理。

架构示意（简化版）

开发者 → push 代码 → → Tekton Triggers → Tekton Pipeline → build + push 镜像 → 更新 Kubernetes 资源 YAML（在 Git 中）  
                                                   ↓  
                                    Argo CD 监控该资源仓库 → 自动同步到目标 Kubernetes 集群 → 部署 / 回滚 / 监控

更清晰的流程：

  1. 开发者向 App 源码仓库（source repo）提交代码（例如某个分支如 dev 或 main）
  2. 配置 Git webhook，把提交 / 合并事件通知 Tekton Trigger
  3. Tekton 的 Trigger / EventListener 捕获事件，发起 PipelineRun
  4. Pipeline 中各个 Task：
    • 克隆代码
    • 编译 / 测试
    • 构建 Docker 镜像（可用 Kaniko / Buildah / Docker-in-Docker 等方式）
    • 推送镜像到镜像仓库
    • 更新 Kubernetes 资源声明仓库（manifest repo）中的 image 标签 / 其他参数
  5. Manifest 仓库（Git 仓库）被更新后，Argo CD 监控到变更，自动或手动同步到目标 Kubernetes 集群
  6. Argo CD 执行差异计算 (diff)、同步 (sync)、回滚 (rollback) 等操作，保证集群状态与 Git 声明一致。

这个架构也被很多实战教程使用。(Medium)

仓库布局建议

通常我们可以分成两个或三个仓库，视规模与团队分工而定：

仓库内容说明
源码仓库（App Repo）业务代码 + Dockerfile + CI 配置（如 Tekton Pipeline / Trigger 配置等）负责 CI 阶段
Manifest 仓库（K8s Repo / GitOps Repo）Kubernetes 资源声明，如 Deployment / Service / ConfigMap / Ingress / Helm chart / Kustomize 等Argo CD 只监控这个仓库（或分支 / 子目录）
（可选）环境 / 平台仓库管理平台级别资源、基础设施层、监控 / 日志 / 公共组件等大项目可分离管理

在 manifest 仓库里，通常又可以用 “App of Apps” 模式，即主 Application 管理子 Application。这样便于分层管理。
例如 Argo CD 的 Application 资源可以指向 manifest 仓库里的子目录，管理多个子服务、公共库等。

三、关键组件安装与配置步骤

下面我以一个通用 Kubernetes 集群为例（可用于自建 k8s、云原生 Kubernetes、OpenShift / EKS / AKS / GKE 等），给出步骤和注意事项。

1. 安装 Argo CD

Argo CD 是负责 GitOps 同步的核心组件。其安装通常非常简单：

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

安装完成后，会在 argocd 命名空间下创建多个组件（API server、repo-server、application-controller、dex / SSO 组件等）。

接着，你可以暴露 Argo CD 的服务 (LoadBalancer / NodePort / Ingress) 以便访问 Web UI。

初始密码默认可以从 argocd-initial-admin-secret Secret 中获取：

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

你也可以设置 SSO / LDAP / OIDC 等认证方式。
Argo CD 支持 declarative 安装：你甚至可以把 Argo CD 自己也纳入 GitOps。也就是用 Argo CD 部署 Argo CD 本身（“self-managed Argo CD” 模式）。这是成熟团队常用的做法之一。

2. 安装 Tekton（Pipelines + Triggers + Dashboard 可选）

Tekton 核心由几个组件组成，通常至少要安装 Pipelines 模块，若要自动响应 Git 事件，还需 Triggers 模块，若要可视化监控还可安装 Dashboard。

以最新版本为例，安装命令类似：

kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
# 可选 dashboard
kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml

安装完成后，Tekton 会在集群中注册多个 CRD（如 Task, Pipeline, Trigger, EventListener, TriggerBinding, PipelineRun, TaskRun 等）。

注意权限 / RBAC：你需要为 Tekton Controller、Trigger Controller 等配置合适的 ClusterRole / ClusterRoleBinding，以便它们能在集群内创建资源、读取 / 修改等。

3. Secrets / 凭证管理

在实际部署时，CI 阶段（Tekton）往往需要访问：

  • Git 仓库（拉取代码、提交更新 manifest 仓库等）
  • 镜像仓库（推送镜像）
  • Kubernetes 集群 / 对 manifest 仓库的写权限（如果你让 CI 负责更新 manifest repo 的话）

对于这些访问，需要在 Kubernetes 中做 Secrets 或 ServiceAccount 与相应授权：

  • Git 凭证（HTTPS / SSH Key）：在对应命名空间创建 Secret，并让 Tekton 的 Task / Pipeline 能够引用
  • Docker / 镜像仓库凭证：使用 docker-registry 类型 Secret 或 imagePullSecrets 形式
  • RBAC / 权限：CI 阶段更新 manifest 仓库时，应采用最小权限原则，不要给过高权限；CD 阶段 Argo CD 也应配置最小权限。

在某些环境下，还可以使用专门的秘密管理系统（如 HashiCorp Vault、Kubernetes External Secrets、Sealed Secrets、SOPS + Git 加密等）来管理敏感信息，而不是明文放在 Git 中。

四、示例配置（简化版）

下面是一个简化示例，演示如何用 Tekton + Argo CD 实现从代码变更到部署的流程。你可以根据这个示例改造。

1. 源码仓库（App Repo）

假设你的应用 repo 目录结构大致如下：

app-repo/
  ├── src/
  ├── Dockerfile
  ├── .tekton/
  │     ├── pipeline.yaml
  │     ├── trigger.yaml
  │     └── task-*.yaml
  └── README.md

pipeline.yaml（示意）：

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy-pipeline
spec:
  params:
    - name: repo-url
    - name: revision
    - name: image-url
    - name: manifests-path
  workspaces:
    - name: source
  tasks:
    - name: fetch
      taskRef:
        name: git-clone
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: revision
          value: "$(params.revision)"
      workspaces:
        - name: output
          workspace: source

    - name: build
      taskRef:
        name: build-docker
      params:
        - name: image-url
          value: "$(params.image-url)"
      workspaces:
        - name: source
          workspace: source

    - name: update-manifests
      taskRef:
        name: manifest-update
      params:
        - name: manifests-path
          value: "$(params.manifests-path)"
        - name: new-image
          value: "$(params.image-url)"
      workspaces:
        - name: source
          workspace: source

trigger.yaml（示意）：

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: git-webhook-listener
spec:
  serviceAccountName: pipeline-sa
  triggers:
    - name: on-push
      bindings:
        - ref: git-binding
      template:
        ref: pipeline-template

你可以把 git-binding、pipeline-template、TriggerBinding / TriggerTemplate 等也写在同一 YAML 中或拆开。

关键在于：当有 Git push / merge 事件触发时，Tekton 会启动一个 PipelineRun，带上参数如 repo-url、revision、image-url、manifests-path 等。

2. manifest 仓库（K8s Repo）

目录结构示意：

k8s-repo/
  ├── base/
  │     ├── deployment.yaml
  │     └── service.yaml
  └── overlays/
        ├── dev/
        │    └── kustomization.yaml
        └── prod/
             └── kustomization.yaml

其中 deployment.yaml 的 image 字段可以是一个占位符，例如：

containers:
  - name: app
    image: your-registry/app:latest

overlay/dev/kustomization.yaml 可以把 image 替换为参数化值，或用 kustomize edit set image … 方式更新。

在 CI 阶段（Tekton 的 manifest-update Task），你可以写脚本替换 overlay 下的 image 字段为新版本镜像标签，然后把这个修改提交回 manifest 仓库（或生成新的 commit / PR）。也可以使用工具如 kustomize, kpt, yq 等操作声明文件。

3. Argo CD 应用配置

在 Kubernetes 集群中，用 Argo CD 创建一个 Application，指向这个 manifest 仓库：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://your-git-server/k8s-repo.git
    targetRevision: dev
    path: overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: app-namespace
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

这个 Application 表示：Argo CD 会监控这个 Git 仓库的 dev 分支下 overlays/dev 目录的内容，并自动同步（部署 / 删除 / 校正）到指定命名空间。

你可以为不同环境（dev / prod）创建多个 Application，指向不同 overlays 目录或分支。

4. 触发流程演示

  1. 开发者在 app-repo 中提交代码、改动 Dockerfile 或业务代码。
  2. Git webhook 通知 Tekton Trigger。Trigger 创造 PipelineRun。
  3. Tekton Pipeline 执行：
    • 克隆代码
    • 构建镜像并推送
    • 更新 manifest 仓库（替换 image）
    • 提交 / 推送 manifest 仓库（或通过 CI 流程自动更新）
  4. Argo CD 监控 manifest 仓库，探测到变更后自动同步到集群：应用新镜像、新资源变更被部署。
  5. 若集群状态与 Git 有偏差（比如手动改动、误操作等），Argo CD 会自动回滚或校正，保证“声明即事实”。

五、实践建议与注意事项

在真实项目中，有一些细节和实践经验非常值得注意：

  1. Secrets 与敏感信息管理
    • 不要把用户名 / 密码 /凭证写在公开 manifest 中
    • 使用 sealed-secrets、SOPS、Vault、Kubernetes Secret + External Secrets 等方式来管理敏感信息
    • Tekton 访问 Git 或镜像仓库的凭证要最小权限，最好按环境隔离
  2. 并发 / 多服务 / 并行构建
    • 若你的项目有多个微服务，可以为每个服务定义独立 Pipeline
    • 使用 Tekton 的并行 / 分支机制提高效率
    • 注意 manifest 仓库的冲突：多个服务同时更新 manifest 仓库可能冲突，要设计 lock / 排队 / 多分支策略
  3. 回滚 / 灾难恢复
    • Argo CD 本身支持回滚（通过 UI / CLI）
    • 在 manifest 仓库中保留历史 commit
    • 若某次同步失败，要有警报、人工确认机制
  4. 漂移校正 (Drift Detection / Self Healing)
    • 推荐开启 Argo CD 的 selfHeal: true，自动校正集群与 Git 的差异
    • 但要注意：某些手动操作可能被覆盖，要避免与 Git 冲突
  5. 分层 / 多环境管理
    • 使用 overlays / kustomize / helm values 等方式区分 dev / staging / prod
    • 推荐 “App of Apps” 模式管理多个子 Application
    • 可以把公共组件（监控、日志、中间件等）抽出为平台级 Application
  6. 权限与安全边界
    • Argo CD 应配置 RBAC，避免所有人都能随意部署
    • 若要支持多租户 / 团队隔离，要设计 namespace 隔离、项目 (Project) 机制、权限边界
    • Tekton 执行 Pods 要在受控的 namespace 或 ServiceAccount 下，不要滥用 cluster-admin 权限
  7. 可视化与监控
    • 使用 Argo CD UI / CLI 查看应用状态、同步历史、回滚能力
    • 安装 Tekton Dashboard 或使用 Tekton CLI (tkn) 查看 PipelineRun / TaskRun 状态
    • 配合 Prometheus / Grafana 对 CI/CD 流程、失败率、延迟等进行监控
  8. 日志、审计、通知
    • 对失败 / 超时 /异常执行发送通知（Slack / 邮件 /Webhook）
    • 记录构建日志、审计操作记录
    • 在 Argo CD 中开启审计和日志功能
  9. 渐进部署 / 金丝雀 / 蓝绿部署
    • 如果你需要零停机升级 / 版本灰度，可以在 manifest 中使用 Argo Rollouts、Istio / Linkerd / Nginx canary 功能，配合 Argo CD 或其他工具
    • 在 CI 阶段可以生成多个版本镜像 / 不同标签

六、一个开源示例项目参考

这个 GitHub 仓库是一个用 Argo CD + Tekton 实现 GitOps 的示例：bilalislam/gitops-using-argo-cd-and-tekton (GitHub)

它演示了如何：

  • 用 Argo CD 部署 Tekton 本身（把 Tekton 的 CRD 和组件也纳入 GitOps）
  • 在 manifest 仓库里管理 dev / prod 目录
  • 在 CI 阶段更新 manifest 仓库
  • 利用 annotations（如 argocd.argoproj.io/compare-options: IgnoreExtraneous）控制同步行为

你可以克隆这个仓库，结合自己的 Kubernetes 环境试跑一遍。

七、总结（优点 / 局限 /适用场景）

优点

  • 声明式管理 + 回滚能力强：Git 是单一可信源，Argo CD 自动同步 / 校正
  • 责任清晰，分层分工：CI 与 CD 各司其职，易于维护和扩展
  • 云原生 / Kubernetes 原生：Tekton 和 Argo CD 都以 K8s CRD 方式运行，整合度高
  • 可扩展性强：你可以灵活扩展 Task / Pipeline，支持并发 / 多服务 /多环境
  • 可审计 / 审查 / 审核流程：因为整个变更走 Git 提交、流水线、同步流程，天然有审计轨迹

局限与挑战

  • 学习曲线：Tekton + Argo CD 的 YAML 配置、Triggers、权限、RBAC、Secrets 等比较复杂
  • Manifest 仓库冲突管理：多个服务同时更新 manifest 仓库时可能产生冲突
  • 权限边界控制复杂：在大组织环境下要安全地划分权限、租户隔离、访问控制
  • 调试成本：流水线失败、同步失败、网络 / 凭证问题定位时有时比较复杂
  • 资源消耗：在大型集群中，Argo CD 的资源消耗、Git 仓库监控消耗可能成为瓶颈

适用场景

这个组合非常适用于：

  • 团队需要在 Kubernetes 上部署微服务 / 云原生应用
  • 希望使用 Git 作为全部变更的唯一入口
  • 需要自动化、可回滚、可审计的部署流程
  • 规模中等以上，需要分环境（dev / staging / prod）管理
  • 希望未来向金丝雀 / 蓝绿 / 多集群 / 多租户方向扩展

如果是非常简单的小项目，用传统 CI/CD 工具可能更快上手；但若你目标是构建一个可持续、易扩展、符合云原生理念的流水线，Argo CD + Tekton 是当前非常受欢迎、社区活跃、成熟度较高的组合。