【编者的话】“人间四月芳菲尽，山寺桃花始盛开。” 越来越多专门给 Kubernetes 做应用发布的工具开始缤纷呈现，帮助大家管理和发布不断增多的 Kubernetes 应用。在做技术选型的时候，我们需要给业务选择一个最好的工具、最稳的底座。那我们又该如何比较和衡量这些工具的呢？在这篇文章中阿里一线工程师给大家分享自己独特的体验。洗尽铅华，一起品味这“山寺桃花”。
背景
近年来，伴随着云原生社区（CNCF Community）的迅猛发展，越来越多的应用跑在了 Kubernetes 上。慢慢地，大家的关注点也逐渐从资源层转移到应用层。一方面，我们看到在有越来越多新的 Kubernetes Operators 出现，用来自动化应用的部署和运维。另一方面，随着各路大型云厂商入场，Kubernetes 服务以后就会像家里的水和电一样随心所欲可用，自己再去动手搭建已经没有了意义。于是人们提出了“Kubernetes 将会消失”，这其实指的是以 Kubernetes 为底座来面向全世界任何一个云以及数据中心交付应用，会是接下来的必然趋势。关于这个趋势，我们团队的同学专门在 InfoQ 上写过一篇关于《Kubernetes 多集群/多云技术与发展》的文章，欢迎大家进一步阅读。
Tekton 项目有什么特殊之处？
基于 Kubernetes 做应用发布的工具，我们有着许多选择，其中不乏业界知名项目 Jenkins X、Spinnaker，也有创业公司出来的小工具比如 Argo Rollout。不过在这其中，我们团队现在主要使用的是 Tekton。这里也有个重要的背景，那就是我们团队要面向多云/多集群交付的，是复杂有状态的阿里巴巴中间件应用。这因素我马上会详细介绍到。
可能还有部分同学还不了解 Tekton 项目是什么？这里我先简单介绍下。Tekton 是一款 Kubernetes 原生的应用发布框架，主要用来构建 CI/CD 系统。它原本是 Knative 项目里面一个叫做 build-pipeline 的子项目，用来作为 knative-build 的下一代引擎。然而，随着 Kubernetes 社区里各种各样的需求涌入，这个子项目慢慢成长为一个通用的框架，能够提供灵活强大的能力去做基于 Kubernetes 的构建发布。
可能不少同学会感到疑惑，有这么多功能丰富、声名远扬的项目，为什么我们选择了灰姑娘般的 Tekton？客官别急，容我们先来梳理一下这个平台底座的要求：
- Kubernetes 原生：流程和概念，尤其是面向用户的部分，需要融入到 Kubernetes 体系中。此外，最好能跟生态里的其他工具互相连通，成为生态的一环。
举个例子：Spinnaker 这个项目是很强大的，但它的设计初衷，是面向公有云进行应用交付用的（以虚拟机为运行时），Kubernetes 只是它所支持的一种 Provider，并且 Provider 还得用 Groovy 写集成插件。这就使得它跟 Kubernetes 的协作是比较别扭的。 - 灵活扩展：基本上所有工具都不能够满足我们复杂多变的业务需求。这些工具架构本身需要提供足够灵活的扩展性，来快速定制实现所需功能。
举个例子：Argo Rollout 本身的应用发布，是跟 Kubernetes 的 Workload （比如 Deployment ）耦合在一起的。这就不是一个很具备扩展性的做法。最简单的例子：对于复杂有状态应用来说，大多都是用 Operator 或者 OpenKruise 管理的，这时候 Argo Rollout 该怎么办呢？ - 轻量级：工具本身不能做得“太重”，即不能有太多的组件或太多的概念。小而轻的项目初期易上手、中期易交付、后期易维护。
举个例子：Spinnaker 虽然功能强大，但是这也就意味着它把所有的事情都帮你做了。而我们团队要发布的应用是复杂有状态的中间件应用， 是需要我们写自己的 Rollout Controller 来控制发布流程的。这个要基于 Spinnaker 来做，还得大量做二次开发了，于是原有的众多功能和组件反而成了负担。 - 白盒化：运行中的管道、步骤等需要“白盒化”，即对外暴露状态。这样才能跟前端工具联通，给用户展示实时状态信息。
举个例子：Tekton 其实只提供 Pipeline 这个一个功能，Pipeline 会被直接映射成 Kubernetes Pod 等 API 资源。而比如应用发布过程的控制，灰度和上线策略，都是我们自己编写 Kubernetes Controller 来实现的，这个可控度其实是我们比较喜欢的。另外，这种设计，也就意味着 Tekton 不会在 Kubernetes 上盖一个“大帽子”，比如我们想看发布状态、日志，就等是直接通过 Kubernetes 查看这个 Pipeline 对应的 Pod 的状态和日志，不需要再面对另外一个 API。
接下来我们在几个候选项目之间做比较：
可以看到，Tekton 在灵活实现定制化功能、Kubernetes 原生性、以及社区里的受欢迎程度等方面可以说还是优势明显的。这也是为什么，我们团队在负责阿里中间件复杂有状态应用的交付工作时，选择了在 Tekton 之上构建应用交付体系。
实践案例：使用 Tekton 自动化应用发布
接下来我们将分享使用 Tekton 自动化应用发布的实践案例。
一个基于 Tekton 的应用发布平台的架构如下：
这里的流程大致是：
- 用户把需要部署的应用先按照一套标准的应用定义写成 YAML 文件（类似 Helm Chart）；
- 用户把应用定义 YAML 推送到 Git 仓库里；
- Tekton CD（一个 Kubernetes Operator）会监听到相应的改动，根据不同条件生成不同的 Tekton Pipelines。
Tekton CD 里的操作具体分为以下几种情况：
- 如果 Git 改动里有一个应用 YAML 且该应用不存在，那么将渲染和生成 Tekton Pipelines 用来创建应用。
- 如果 Git 改动里有一个应用 YAML 且该应用存在，那么将渲染和生成 Tekton Pipelines 用来升级应用。这里我们会根据应用定义 YAML 里的策略来做升级，比如做金丝雀发布、灰度升级。
- 如果 Git 改动里有一个应用 YAML 且该应用存在且标记了“被删除”，那么将渲染和生成 Tekton Pipelines 用来删除应用。确认应用被删除后，我们才从 Git 里删除这个应用的 YAML。
接下来，我们看一个创建应用的简单例子：
这个例子里面我们生成了一个 Tekton Pipeline。运行这个 Pipeline 就可以将应用发布到 Kubernetes 集群上。
用户操作的边界就是 Git，之后所有流程都是自动化的。那么整个过程中用户怎么得到反馈信息呢？这里主要有：
- 过程状态：Tekton Pipeline 本身就是 Kubernetes API object，我们通过汇总 Status 将过程状态信息透出给前端。
- 日志和监控：由于 Tekton Pipeline 启动的都是 Kubernetes Pod，我们可以复用原有的基础设施去收集，然后做一遍汇总。
经验总结
上面给大家介绍了 Tekton 项目的基本原理、以及使用 Tekton 做底座进行应用发布的主要流程。在这里总结一些经验体会：
- 复用开源技术。少去做造轮子的事情就意味着能够多专注更具价值的事情。
- 不要只着眼于眼前的需求，还要关注定制化和扩展性，多考虑未来的场景。
- Kubernetes 应用层接下来将会加速发展。帮助开发者在 Kubernetes 上更好地开发、部署、管理应用，把相关流程标准化，是未来的重要趋势。
另外，Tekton 2019 发展规划中还包括了 conditional execution，cancelling or pausing a workflow，resuming a paused or failed workflow，enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上，未来的应用发布平台将会更加强大。
Q&A
Q：请比较一下 Drone 和 Tekton，thx！
A：Drone 是一个 CI/CD 工具，Tekton 是用来做 CI/CD 的框架。Tekton 在更底层，也更为灵活。
Q：Tekton 作为一个执行引擎，可能会有很多执行节点串联运行，不同节点中运行状态和日志是如何反馈的？
A：Tekton Pipeline 本身就是 Kubernetes API object，我们通过汇总 Status 来透出运行状态。由于 Tekton Pipeline 启动的都是 Kubernetes Pod，我们可以复用原有的基础设施去收集，然后做一遍汇总。
Q：Tekton 如何与 GitOps 结合？
A：我们做了一个类似于 flux（https://github.com/fluxcd/flux）的 Operator，通过监听 webhook 事件等来触发操作。
Q：Tekton 集成方面有哪些特性？
A：灵活以及非常云原生。比传统工具更好在 Kubernetes 跟其他组件做集成。比方说，跟 Flagger 等在 Kubernetes 提供金丝雀发布策略的组件结合，做云原生应用发布。
Q： Tekton 既然作为 Knative 项目里面一个叫做 build-pipeline 的子项目，那请问下 Tekton 和 Knative 有什么不同或者对比优缺点吗，我最近有准备做 Knative，今天有幸看到这个分享，正好请教一下？
A：Knative 是 Serverless Framework，跟 Tekton 解决的不是一个层面的事情，没有比较性。相反，他们可以 inter-operate，Knative 里就使用了 Tekton。
Q：我的看法是 CD 和 CI 都只是 Tekton 的 Task，能否讲下你们的 CI？
A：你好，我们做的是 CD。不只是 Tekton Task，也用了其他的 Tekton 原生功能，比如 Pipeline、PipelineResource 等。我们做的是面向多云/多集群交付的、面向复杂有状态的阿里巴巴中间件应用的发布平台。
Q：你们做的这个和 Jenkins X Pipeline Operator and Tekton 的区别和两者的优缺点？
A：Jenkins X 是 CloudBees 团队基于原来 Jenkins 的需求，再使用 Tekton、Prow 等搭建的 CI/CD 平台。这也侧面说明了 Tekton 等云原生工具的优势。但 Jenkins X 做的比较重。而且以 CI 端为主，不支持复杂的发布策略。
Q：请问有什么好的 GitOps trigger？我们使用的的是 Phabricator， 一直没有找到适合的trigger。
A：这个主要看工具本身（比如 Phabricator）提供什么样的 Git trigger，然后才能集成到如 flux 这样的 GitOps 工具中。
Q：请比较一下 Prow 和 Tekton，发现 Kubernetes，Prometheus 以及 Tenkton 本身都是使用了 Prow。
A：Prow 是一款基于 GitHub 做的 Chatbot 工具。Tekton 则是用来实现后面对接的 CI/CD 的底层框架。本人恰好也是早期参与 Prow 项目，所以多说一点这个工具的历史。一开始 GitHub 功能不够强大，这个工具只是为了弥补 GitHub 的不足之处，主要是要经过 review 不能让人手动合并代码。后来功能做着做着变多了，有些被 GitHub 重复了。但是功能集合还是比 GitHub 多，而且 CNCF 里的 infra 默认使用。
以上内容根据2019年8月15日晚微信群分享内容整理。分享人邓洪超，阿里云容器平台工程师， Kubernetes Operator 第二人，云原生应用标准交付与管理领域知名技术专家。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiese，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
