初探云原生应用管理之：聊聊 Tekton 项目
【编者的话】“人间四月芳菲尽，山寺桃花始盛开。”越来越多专门给Kubernetes做应用发布的工具开始缤纷呈现，帮助大家管理和发布不断增多的Kubernetes应用。在做技术选型的时候，我们需要给业务选择一个最好的工具、最稳的底座。那我们又该如何比较和衡量这些工具的呢？在这篇文章中阿里一线工程师给大家分享自己独特的体验。洗尽铅华，一起品味这“山寺桃花”。
背景Tekton项目有什么特殊之处？基于Kubernetes做应用发布的工具，我们有着许多选择，其中不乏业界知名项目JenkinsX、Spinnaker，也有创业公司出来的小工具比如ArgoRollout。不过在这其中，我们团队现在主要使用的是Tekton。这里也有个重要的背景，那就是我们团队要面向多云/多集群交付的，是复杂有状态的阿里巴巴中间件应用。这因素我马上会详细介绍到。
可能还有部分同学还不了解Tekton项目是什么？这里我先简单介绍下。Tekton是一款Kubernetes原生的应用发布框架，主要用来构建CI/CD系统。它原本是Knative项目里面一个叫做build-pipeline的子项目，用来作为knative-build的下一代引擎。然而，随着Kubernetes社区里各种各样的需求涌入，这个子项目慢慢成长为一个通用的框架，能够提供灵活强大的能力去做基于Kubernetes的构建发布。
可能不少同学会感到疑惑，有这么多功能丰富、声名远扬的项目，为什么我们选择了灰姑娘般的Tekton？客官别急，容我们先来梳理一下这个平台底座的要求：
Kubernetes原生：流程和概念，尤其是面向用户的部分，需要融入到Kubernetes体系中。此外，最好能跟生态里的其他工具互相连通，成为生态的一环。
举个例子：Spinnaker这个项目是很强大的，但它的设计初衷，是面向公有云进行应用交付用的（以虚拟机为运行时），Kubernetes只是它所支持的一种Provider，并且Provider还得用Groovy写集成插件。这就使得它跟Kubernetes的协作是比较别扭的。
灵活扩展：基本上所有工具都不能够满足我们复杂多变的业务需求。这些工具架构本身需要提供足够灵活的扩展性，来快速定制实现所需功能。
举个例子：ArgoRollout本身的应用发布，是跟Kubernetes的Workload（比如Deployment）耦合在一起的。这就不是一个很具备扩展性的做法。最简单的例子：对于复杂有状态应用来说，大多都是用Operator或者OpenKruise管理的，这时候ArgoRollout该怎么办呢？
轻量级：工具本身不能做得“太重”，即不能有太多的组件或太多的概念。小而轻的项目初期易上手、中期易交付、后期易维护。
举个例子：Spinnaker虽然功能强大，但是这也就意味着它把所有的事情都帮你做了。而我们团队要发布的应用是复杂有状态的中间件应用，是需要我们写自己的RolloutController来控制发布流程的。这个要基于Spinnaker来做，还得大量做二次开发了，于是原有的众多功能和组件反而成了负担。
白盒化：运行中的管道、步骤等需要“白盒化”，即对外暴露状态。这样才能跟前端工具联通，给用户展示实时状态信息。
举个例子：Tekton其实只提供Pipeline这个一个功能，Pipeline会被直接映射成KubernetesPod等API资源。而比如应用发布过程的控制，灰度和上线策略，都是我们自己编写KubernetesController来实现的，这个可控度其实是我们比较喜欢的。另外，这种设计，也就意味着Tekton不会在Kubernetes上盖一个“大帽子”，比如我们想看发布状态、日志，就等是直接通过Kubernetes查看这个Pipeline对应的Pod的状态和日志，不需要再面对另外一个API。
接下来我们在几个候选项目之间做比较：
可以看到，Tekton在灵活实现定制化功能、Kubernetes原生性、以及社区里的受欢迎程度等方面可以说还是优势明显的。这也是为什么，我们团队在负责阿里中间件复杂有状态应用的交付工作时，选择了在Tekton之上构建应用交付体系。
实践案例：使用Tekton自动化应用发布接下来我们将分享使用Tekton自动化应用发布的实践案例。
一个基于Tekton的应用发布平台的架构如下：
这里的流程大致是：
用户把需要部署的应用先按照一套标准的应用定义写成YAML文件（类似HelmChart）；
用户把应用定义YAML推送到Git仓库里；
TektonCD（一个KubernetesOperator）会监听到相应的改动，根据不同条件生成不同的TektonPipelines。
TektonCD里的操作具体分为以下几种情况：
如果Git改动里有一个应用YAML且该应用不存在，那么将渲染和生成TektonPipelines用来创建应用。
如果Git改动里有一个应用YAML且该应用存在，那么将渲染和生成TektonPipelines用来升级应用。这里我们会根据应用定义YAML里的策略来做升级，比如做金丝雀发布、灰度升级。
如果Git改动里有一个应用YAML且该应用存在且标记了“被删除”，那么将渲染和生成TektonPipelines用来删除应用。确认应用被删除后，我们才从Git里删除这个应用的YAML。
接下来，我们看一个创建应用的简单例子：
这个例子里面我们生成了一个TektonPipeline。运行这个Pipeline就可以将应用发布到Kubernetes集群上。
过程状态：TektonPipeline本身就是KubernetesAPIobject，我们通过汇总Status将过程状态信息透出给前端。
日志和监控：由于TektonPipeline启动的都是KubernetesPod，我们可以复用原有的基础设施去收集，然后做一遍汇总。
经验总结上面给大家介绍了Tekton项目的基本原理、以及使用Tekton做底座进行应用发布的主要流程。在这里总结一些经验体会：
复用开源技术。少去做造轮子的事情就意味着能够多专注更具价值的事情。
Kubernetes应用层接下来将会加速发展。帮助开发者在Kubernetes上更好地开发、部署、管理应用，把相关流程标准化，是未来的重要趋势。
另外，Tekton2019发展规划中还包括了conditionalexecution，cancellingorpausingaworkflow，resumingapausedorfailedworkflow，enforcingtimeoutsonTasksandPipelines等功能。站在巨人的肩膀上，未来的应用发布平台将会更加强大。
