tekton 和 Argocd的区别

背景

云原生确实现在百花齐放，但是给开发者带来的就是学习成本。东西太多了。刚学完tekton 又来了一个 argocd，刚开始我是比反感的，但是现在看来确实argocd可以弥补tekton的一些不足。

tekton的不足

ci大体上来说就是 测试、构建镜像、推送镜像、修改部署清单等，这些步骤tekton可以轻松应对，但是到了cd阶段就显得有点力不从心，虽然部署的事情他也能干，但是干的不那么完美。

因为tekton属于push模式，执行kubectl apply 或者 helm install，这种 CD 模式的缺陷很明显：

1. 需要安装配置额外工具（比如 kubectl）
2. 需要 Kubernetes 对其进行授权
3. 需要云平台授权
4. 无法感知部署状态。也就无法感知期望状态与实际状态的偏差，需要借助额外的方案来保障一致性

在我看来最主要的就是没有办法感知部署状态，一锤子买卖部署完就不管了，Argo CD 不仅会监控 Git 仓库中声明的期望状态，还会监控集群中应用的实际状态，并将两种状态进行对比，只要实际状态不符合期望状态，实际状态就会被修正与期望状态一致。假如有人不小心修改了集群中应用的状态（比如修改了副本数量），Argo CD 还是会将其恢复到之前的状态。这就真正确保了 Git 仓库中的编排文件可以作为集群状态的唯一真实来源。这也就是传说中的不可变基础设施。

联手

其实我觉得核心还是围绕着gitops来做，tekton经过测试，编译，打包后将部署文件提交到git仓库，由于argocd是pull模式（Pull 模式会在目标环境中安装一个 Agent，例如在 Kubernetes 集群中就靠 Operator 来充当这个 Agent。Operator 会周期性地监控目标环境的实际状态，并与 Git 仓库中的期望状态进行比较，如果实际状态不符合期望状态，Operator 就会更新基础设施的实际状态以匹配期望状态。），当发现期望与实际不符时，更新资源。
而且argo还有一个非常漂亮的ui界面可以实时看到资源状态。

参考

https://zhuanlan.zhihu.com/p/551331656
https://mp.weixin.qq.com/s/CwKKmm9P4F9mrXge-j76lw
https://mp.weixin.qq.com/s/M08CrTEeriZwvNCjlaZdkg