从Jenkins切换到Tekton的那些事儿，实践中遇到的坑和收获分享

从Jenkins切换到Tekton的那些事儿，实践中遇到的坑和收获分享

我们团队大概在一年前开始考虑从Jenkins迁移到Tekton，主要是因为我们的应用都跑在Kubernetes上，想找一个更“原生”的构建工具，Jenkins虽然功能强大，但维护那个Master节点和一堆插件挺头疼的，每次升级都像是一次冒险，听了几次关于云原生的分享后,我们决定试试Tekton。

一开始，感觉挺新鲜的，Tekton的所有东西都是Kubernetes里的自定义资源，比如Pipeline、Task这些，都是用YAML文件来定义，这听起来很美，和我们用的k8s部署文件风格一致，想着应该很好上手，但真正做起来，第一个坑马上就来了：心智模型的转变，在Jenkins里，我们习惯了一个流水线脚本从头写到尾，逻辑是线性的，但在Tekton里，一切都被拆解成一个个独立的Task，然后通过Pipeline把它们组装起来，还要明确地定义每个Task之间传递什么参数和文件，光是设计这个“组装”结构，我们就讨论了挺久，参考了官方文档和几篇社区文章（比如一篇名为《Tekton Pipelines: A Jenkins Veteran's Perspective》的博客）,才慢慢理清思路。

接着是第二个大坑：调试的复杂性，在Jenkins里，哪个步骤失败了，直接登录到那个Agent节点上去看日志、查文件，虽然笨但直接，在Tekton里，每个Task都跑在一个独立的Pod里，跑完这个Pod就销毁了，一开始，我们经常对着一个失败的PipelineRun发呆，不知道具体是哪个Pod出了错，日志得一层层去捞，后来我们才学会善用kubectl命令和Tekton CLI（tkn）来跟踪和查看日志，我们也引入了像Tekton Dashboard这样的可视化工具，情况才好了一些，这个过程让我们深刻体会到，在k8s里，“可观察性”必须从一开始就设计好,不能事后补救。

还有一个没想到的麻烦是资源管理，在Jenkins里，我们通常指定一个固定的Agent（那个有Docker守护进程的机器”）来跑构建，在Tekton里，每个Task的Pod都需要定义计算资源（CPU/内存），我们一开始给的资源很随意，结果经常遇到构建因内存不足而失败，或者因为资源争抢导致集群其他应用受影响，我们不得不花时间仔细分析每个构建步骤的真实需求，给出一套合理的资源请求和限制，这虽然是个坑，但也逼着我们更精细地管理资源,算是个意外收获。

说到收获,最大的几点是：

第一，真正的云原生体验，Tekton和Kubernetes的集成度极高，我们利用k8s的RBAC来控制不同团队对流水线的访问权限，利用Namespace做逻辑隔离，利用Secret管理凭证变得非常自然，整个构建环境本身就是一组声明式的k8s资源，可以用GitOps的方式来管理,这比维护一堆Jenkins的配置项目和凭据要清晰和安全得多。

第二，可复用性和模块化，一旦我们克服了最初的设计困难，就发现Tekton的Task和Pipeline的复用能力非常强，我们写好了一个“从Git克隆代码”的Task，一个“构建Go应用镜像”的Task，就可以在不同的项目Pipeline里像搭积木一样使用，这大大减少了重复配置,维护点也集中了。

第三，扩展和集成更“k8s”，当我们需要在流水线里加入一个安全扫描步骤时，只需要找一个能跑在容器里的扫描工具，把它封装成一个Tekton Task，然后插入到Pipeline里就行，整个过程不需要去动“中心服务器”，也不需要担心插件兼容性问题，整个流水线的运行完全由k8s调度,弹性很好。

也不是所有都完美，Tekton的社区和插件生态比起Jenkins还是小很多，遇到一些冷门问题，可能需要自己动手去解决或者等社区响应，对于一些非常简单的、一次性的构建任务,写一堆YAML文件确实显得有点重。

从Jenkins切换到Tekton，感觉像是从开一辆功能齐全但有些老旧的汽车，换到了一辆需要自己更多参与组装的模块化电动车，前期学习成本和“组装”成本比较高，路上也会遇到一些新问题，但一旦跑顺了，你会发现它更适应云原生的道路，更灵活，也更能融入整个技术栈，这个过程让我们团队对Kubernetes的理解也加深了不少，如果你们的应用完全跑在k8s上，并且愿意拥抱声明式配置和模块化设计，那么切换是值得的,但要做好前期投入时间和精力的准备。