上周有位朋友发我一串工具名说团队准备重构交付流水线让我帮看看 Argo CD、Tekton、还有最近冒出头的 Arbess 该怎么选。我在屏幕前愣了几秒这问题不是三两句话能说完的。这三者看起来都在 CI/CD 圈子里但定位差了十万八千里选错一个后面返工的成本比想象中大很多。这篇文章不打算做那种罗列官方文档的对比我会先讲清楚三者的真实定位再给出在你团队场景里怎么判断、怎么落地以及我自己在实战中踩过的那些坑。无论你是在做平台工程还是在做业务团队的交付负责人这篇都能给你一个明确的决策框架。1. 先把三款工具的定位掰开揉碎它们根本不是同一层的东西很多人把 Argo CD、Tekton、Arbess 放在一起比默认它们都是“CI/CD 工具”这是个挺要命的误解。我在评审不少交付平台方案时发现团队做完对比表之后依然选错就是因为在第一层定位上就没分清。实际上CI 和 CD 本来就是两个完全不同阶段的工作工具解决的问题也不一样。1.1 Argo CD面向终态的 GitOps 持续交付Argo CD 的核心工作是持续交付准确说是 GitOps 模式下的应用发布控制器。它的设计出发点很纯粹集群里应该长什么样完全由 Git 仓库里的声明式配置决定Argo CD 负责把所有集群状态往那个终态拉。它内部的几个核心概念你绕不开Application 声明一个应用应该部署到哪个集群、哪个命名空间、用哪个仓库里的哪个目录Project 做多团队隔离和权限边界Repo Server 负责拉取和渲染 Git 仓库内容Application Controller 负责比对实际状态和期望状态然后执行同步。ApplicationSet 则是用来做多集群、多环境批量生成的这在规模化场景里几乎是必需品。我把 Argo CD 定位成“终态收敛器”。它不关心你的镜像怎么构建出来的不关心测试怎么跑的它只负责把你交付的 YAML、Helm Chart 或者 Kustomize 渲染结果安全、可控地落到集群里并且保证后续任何手动改动都会被收敛回去。这对生产环境来说价值非常大因为你不再依赖“谁来执行 kubectl apply”变更记录天然留在 Git 历史里。1.2 TektonK8s 原生 CI 流水线框架Tekton 走的是另一条路它是云原生时代的 CI 框架出身和 Knative 有很深的渊源后来捐给了 CNCF。它把流水线抽象成了一堆 Kubernetes 自定义资源Pipeline 由多个 Task 组成每个 Task 由多个 Step 组成每个 Step 就是一个小容器。这种“流水线即代码、即 CRD”的思路有个天然好处你的流水线定义本身也存放在集群里能被 Kubernetes 的 RBAC、审计、声明式管理覆盖。比如你想限制某个团队只能跑哪些 Task直接靠 RBAC 就能控制而不需要 Jenkins 那种独立的权限系统。扩展能力也强官方和社区维护了一大批现成 Task从 git clone 到镜像构建到漏洞扫描都有。不过要清楚Tekton 不是 CD 工具。它构建出来的镜像推到了仓库但谁来把这个镜像部署到生产Tekton 不管。你可以让它最后调一下 Argo CD 的 API 触发同步但更常见的架构是Tekton 负责把代码变成可交付的产物Argo CD 负责消费产物并更新集群状态。1.3 Arbess更年轻的轻量级调度与发布引擎Arbess 这个名字在主流社区里出现的时间并不长我接触到的实践更多出现在一些团队内部平台和特定领域的小范围讨论里。从已有资料和使用者的反馈看它更像是面向环境编排、状态切换、灰度执行这类场景的轻量级发布调度引擎定位偏向“把多个环境的发布动作编排起来”而不是像 Argo CD 那样严格绑定 Git 仓库作为唯一事实来源。如果你关注的是这类工具我的建议是用一种偏冷静的心态去评估生态成熟度还不足以和 Argo CD 抗衡自带的生产级能力比如多集群管理、权限模型、审计回溯、高可用部署都需要额外验证。它的优势是轻、上手快对已经有自研发布平台的团队来说可以作为某个环节的补充组件。但要是打算拿它当中枢我劝你慎重。下面这张表可以把定位差异看得更清楚。维度Argo CDTektonArbess 类工具核心定位持续交付 / GitOps 终态收敛云原生 CI 流水线轻量级发布编排 / 环境调度管理对象Application、Project、ApplicationSetPipeline、Task、PipelineRun环境、发布任务、工作流声明式来源Git 仓库YAML CRD配置或 API 触发适合环节CD部署、回滚、多集群同步CI构建、测试、扫描、产物生成边缘环境同步、灰度切换、运维编排生产化成熟度高高中低需额外验证上手成本中等核心概念需要吃透中等偏上CRD 概念多低但有自定义学习成本2. 选型之前先问自己四个关键问题很多人让我推荐工具一上来就问“哪个最强”我一般会反问一句你们现在最痛的是哪一段工具选型本质上不是比参数而是比匹配度。先花 30 分钟把下面这四个问题聊清楚答案基本就出来了。2.1 你的痛点到底是发布慢还是构建慢听起来是废话但实践中大部分团队真的分不清。我见过一个团队花了两个月把 Tekton 流水线搭得非常漂亮每天几百次构建毫无压力结果真正上线时还是靠人工在集群里敲命令交付周期一点没缩短。他们的痛点是发布过程靠人肉、回滚靠运气这应该上 Argo CD而不是 Tekton。反过来也常见。某个兄弟团队天天抱怨“发版太慢”细查之下发现是编译、单测、镜像扫描全都串行跑一次构建要 40 分钟这属于 CI 侧的瓶颈Tekton 就能明显提速。所以选型第一件事把你们的发布流程画出来标出哪些环节属于“把代码变成镜像和扫描报告”哪些属于“把镜像和配置变成线上服务”。2.2 你的多集群、多环境复杂度有多高如果你的业务只有一套 K8s 集群环境也就是 dev、staging、prod 三个 namespace那 Argo CD 的大多数高级能力你都用不大上Arbess 这类简化工具有时候反而更快。但如果你面对的是多集群多 region比如业务同时跑在自建集群和云托管集群上或者有十几个业务线各自拥有独立环境那 Argo CD 的 ApplicationSet 和 Project 隔离机制就是刚需。它可以在一个控制平面里管理几百个集群这个体量目前其他工具很难追。Tekton 在多集群场景里基本只负责生产集群的 CI结果同步给多个 CD 目标。Arbess 这类轻量编排如果要做大规模多集群调度你得自己额外开发大批适配逻辑。2.3 你们团队对 Kubernetes 原生的接受度如何Tekton 和 Argo CD 都建立在 Kubernetes CRD 之上这意味着使用它们之前团队成员得对 Pod、ServiceAccount、RBAC、PVC 这些概念有基本认识。这不是坏事因为一旦掌握所有配置都能用 Git 管理能走完整的评审和审计。但对于一个以传统运维为主、脚本化思维根深蒂固的团队来说这条学习曲线会非常陡。Arbess 这类工具通常提供更友好的操作界面和脚本化编排方式团队成员可以不用理解太深的 Kubernetes 内部机制就上手。代价是当平台出问题的时候你能借力的社区经验和文档非常有限调试全靠自己啃源码这对大部分团队来说反而是更大的成本。2.4 你打算投入多少精力在可观测性和平台工程化上CI/CD 工具本身只是交付链路的一部分真正跑起来以后你会关心流水线成功率、同步延迟、失败原因分布、变更频率这些指标。Argo CD 对 Prometheus metrics 支持很成熟每个 Application 的 sync 状态、health 状态都能暴露出来方便接进 Grafana。Tekton 也有官方的 metrics 和事件系统配合 Tekton Results 甚至可以做流水线历史归档和检索。Arbess 类工具在这块通常是弱项它更多关心“任务执行没执行”而不是“整体交付质量趋势如何”。如果你们有一个平台工程团队后者几乎决定了长期维护成本。3. 手把手过一遍三种方案的核心实操对比光讲概念是空的下面我把三种工具的典型配置方式都过一遍原因也一并说清楚。这样你拿去就能对着改出自己的第一个版本。3.1 用 Argo CD 做一个 GitOps 应用发布Application YAML 拆解先说安装。生产级部署最少三个组件argocd-server、argocd-repo-server、argocd-application-controller官方 Helm Chart 可以一键搞定但我建议单独加一套高可用配置把 repo-server 和 controller 的副本数调到 2 以上否则升级重启期间所有应用同步都会卡住。装完之后最简单的入门方式是用 kubectl 直接创建一个 Application。下面是一个比较标准的示例apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: demo-api namespace: argocd spec: project: production source: repoURL: gitgithub.com:demo/demo-api-deploy.git targetRevision: HEAD path: overlays/production destination: server: https://kubernetes.default.svc namespace: demo-prod syncPolicy: automated: prune: true selfHeal: true这里每个字段都有讲究。source.path 指向仓库里的 overlays/production 目录这是 Kustomize 的常见布局好处是不同的环境用不同的 overlay但基础配置只要维护一份。destination.server 用的是集群地址本地集群可以写 https://kubernetes.default.svc跨集群管理时可以换成目标集群的 API Server 地址。automated 开启后Argo CD 会每隔一段时间自动检测 Git 里的变化并同步同时把集群里被手工改掉的资源也拉回 Git 描述的状态。我要重点提醒的是prune 和 selfHeal 这两个开关千万不要第一天就全开。prune 意味着同步时会删除集群里不在 Git 里的资源如果你仓库目录里的资源清单不全一同步就会把该保留的 Service、ConfigMap 全删了。selfHeal 则会把运维同学临时手动扩的 Pod 副本数直接改回去这功能适合流程成熟后开启初期先手动同步跑两周观察状态。3.2 用 Tekton 搭建一条标准 CI 流水线Task/PipelineRun 示例Tekton 的配置最核心的两个资源是 Task 和 Pipeline。一个 Task 定义一组有序执行的 Step每个 Step 就是一个小容器一个 Pipeline 把多个 Task 串起来通过 workspaces 在任务之间共享代码和产物。以下是一个简化但能直接跑的 Pipeline 示例覆盖了 clone 代码、构建镜像、扫描漏洞三个环节apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: build-push-scan spec: workspaces: - name: shared tasks: - name: clone taskRef: name: git-clone params: - name: url value: https://github.com/demo/demo-api.git - name: build-push taskRef: name: buildah runAfter: - clone workspaces: - name: source workspace: shared params: - name: IMAGE value: registry.demo.io/demo-api:latest - name: scan taskRef: name: trivy-scan runAfter: - build-push workspaces: - name: source workspace: shared实际跑这个 Pipeline 之前你需要先创建一个 PVC 作为 workspace还要准备一个 ServiceAccount并给它赋予创建 Pod 和读取 PVC 的权限。这条流水线的逻辑是第一步把代码拉到共享的 workspace第二步用 buildah 构建并推送镜像第三步对镜像做漏洞扫描。每个 Step 之间可以并发也可以用 runAfter 显式控制顺序。这里有个很大的认知误区要澄清Tekton 的 Step 不是传统 CI 里的“阶段”每个 Step 之间没有会话保持也没有共享文件系统只能靠 workspace 显式传递。所以如果你在 Jenkins 里习惯了在同一个 shell 上下文里跑“编译、打包、发布”一连串命令到了 Tekton 这里要么拆成多个 Task要么把命令写在一个 Step 里。镜像构建我建议用 buildah 或者 kaniko不要尝试在 Step 里装一个 Docker daemon这在生产集群里既危险又容易被安全策略拦死。3.3 Arbess 场景模拟一个多环境一键发布的工作流Arbess 类工具因为没有统一标准我的建议是不要照搬网上的所谓“最佳实践”因为我见过不少人贴出来的配置其实只是自己项目里的内部 DSL。它们的共同点是会提供一种 YAML 或 JSON 的工作流定义描述“哪个环境、更新到什么版本、按什么顺序执行”。我下面写的是一个模拟结构用来帮你理解这类工具通常解决什么问题workflow: name: env-sync steps: - name: switch-stage cluster: stage-cluster action: upgrade artifact: demo-api:1.8.0 - name: canary-prod cluster: prod-cluster action: canary traffic: 10% - name: promote cluster: prod-cluster action: promote require: canary-prod你不需要把它当成某个具体工具的官方语法但可以从中看到它的应用场景当你有多个环境需要同时升级、或者要做灰度流量切换时Arbess 类的逻辑就是把这种“跨环境的发布顺序编排”做得更直接。但反过来它也意味着你和这套自定义 DSL 深度绑定一旦工具升级改变配置格式你维护的学习成本和迁移成本都要自己承担。4. 真实踩坑实录三款工具的典型翻车现场工具本身不难装难的是跑起来之后的各种意外。下面这些坑都是我实际见过或者自己踩过的挨个说清楚能帮你省不少时间。4.1 Argo CD 三大坑Sync 反复失败、仓库认证失效、Webhook 不触发第一个坑是 Sync 状态卡在 OutOfSync。大多数时候不是配置错了而是 Argo CD 的 API Server 里安装的 Kustomize 或 Helm 版本和你本地生成清单时用的版本不一致导致渲染结果有细微差异。排查方法是看 Application 的 conditions去 argocd-repo-server 的日志里翻渲染错误。解决方案很朴素固定使用同一个工具版本最好在仓库根目录建一个 .argocd 配置来锁定版本。第二个坑是私有 GitLab 的 SSH key 认证隔三差五失效。原因通常是 git 仓库的 host key 变了或者 key 的 passphrase 被配置进了错误的字段。如果集群里的 argocd-repo-server 做了多副本你更新密钥之后必须滚动重启所有 Pod因为 repo server 默认会在内存中缓存仓库列表光改 Secret 是不刷新的。第三个坑是 Webhook 不触发。很多人配完 GitHub Webhook 之后发现 push 代码没反应实际原因是 Argo CD 默认只接受事件类型为 push 的请求而且要求 Webhook Secret 和 Argo CD 配置一致。如果用的自建 GitLab还要额外确认 PR 事件和 push 事件分别配置了两个 Webhook而不是只填了一个。4.2 Tekton 三大坑安全上下文被拦截、Workspace 容量爆掉、重复触发流水线Tekton 的 Step 镜像默认以容器镜像自己的用户运行很多社区 Task 里的构建镜像为了省事会以 root 跑。现在的生产集群几乎都开启了 Pod Security Admission 或第三方的安全策略结果就是你 Task 一到 build 阶段就被拒绝创建 Pod看 Events 才能发现是 securityContext 的问题。解决办法是给 Pipeline 指定一个具有合适权限的 ServiceAccount或者用受信任的自定义镜像不要默认认为官方 Task 一定能在你的集群里无障碍运行。Workspace 的坑偏运维向。我见过团队把整个编译缓存和 Git 代码都丢在一个 5Gi 的 PVC 里跑了两个月后所有 PipelineRun 开始卡在 workspace init。这个问题没有优雅解法就是监控要跟上同时给不同的 Task 规划不同用途的 Volume比如持久化 /home/build 用大容量 HDD代码临时目录用 emptyDir。重复触发是另一个让人头大的问题。如果你的 CI 事件源同时配了 webhook 和定时轮询或者 Tekton 的 EventListener 没有做好 deduplicate每 push 一次可能跑两三条同样的流水线。排查时先看 EventListener 的日志里同一事件进没进来两次然后去 TriggerBinding 里加去重属性别一上来就在 Pipeline 里加锁。4.3 Arbess 类工具的注意点API 演进快、文档少、生产级特性需要自测Arbess 这类较新的工具最大的坑是 API 稳定性。我遇到过用户升级一个小版本结果工作流定义的字段名改了一大片所有旧任务全部失效。这类工具往往没有社区版的迁移工具也没有像 Kubernetes 那样的 API deprecation 策略你唯一能做的就是升级前把配置文件全部锁版本并在一套独立环境里先跑一遍回归。第二个注意点是文档和问题排查资源稀缺。Argo CD 报个错你搜一下就有成百上千个 issue 讨论Arbess 报个错大概率只能自己读日志和源码。所以如果团队没有足够的 Go 语言调试能力我建议把它限制在低风险场景不要放到核心生产发布链路上。5. 落地选型建议按团队规模和业务形态直接抄作业看完全部技术对比我给你一个更直白的落地版本。选型不是选最好是选匹配度最高。5.1 简易选型矩阵场景特征推荐方案理由单集群、发布流程简单、团队人数少Argo CD 足够Arbess 可作为辅助学习成本低GitOps 模式能快速规范发布流程多业务线、镜像构建频率高、需要标准化 CITekton Argo CDTekton 标准化构建Argo CD 标准化部署配合最顺多集群、多 region、需要统一控制面Argo CD ApplicationSet 必选一个控制面管所有集群环境一致性靠 Git 保证离线内网、私有化交付Tekton Argo CD 走内网镜像仓库两套工具都是纯自托管不依赖外部 SaaS已有自研发布平台只想补一个轻量环境切换组件Arbess 类工具可试点避免大改造把最痛的环境编排场景先解决5.2 组合拳才是常态Tekton Argo CD 的黄金搭档如果让我给一个最不容易出错的默认架构那就是 Tekton 负责 CIArgo CD 负责 CD中间靠镜像仓库和 Git 仓库衔接。开发 push 代码后Tekton 自动拉代码、跑测试、构建镜像、推送到镜像仓库完成后更新部署仓库里对应环境的镜像版本。Argo CD 检测到部署仓库变化自动同步到目标集群。这套组合的好处是职责边界极其清晰。CI 的波动再大不会影响线上环境的稳定性CD 的回滚再频繁也不会把构建系统拖垮。Argo CD 天然有回滚能力通过 Git 历史回到上一个 commit就相当于一次回滚操作。Tekton 这边只需要关注流水线的效率和产物质量。Arbess 如果你们坚持要试放在这套链路的外围比如做多环境的版本对齐检查而不是替换核心发布路径。5.3 我个人的选型心得我观察到一个规律CI/CD 工具选型翻车的团队大多数不是技术能力不行而是一开始把问题定义错了。他们拿 Argo CD 的文档去对比 Tekton 的功能清单然后得出“Argo CD 构建功能太弱”的结论却忽略了自己根本不需要用 Argo CD 做构建。我自己最舒服的组合就是“Tekton 负责把代码变成可交付的镜像Argo CD 负责把镜像和配置变成集群里的终态”至于 Arbess 这类新工具我会先在一个不重要的边缘环境跑足三个月确认 API 稳定性和运维可观测性都能接受再决定要不要写进平台标准。工具永远在变但你心里要有一把尺哪个环节产出了什么哪个环节消费了什么上下游是否清晰。把这条链路理顺比任何工具选型都重要。