背景

近年来，伴随着云原生社区 (CNCF Community) 的迅猛发展，越来越多的应用跑在了 k8s 上。慢慢地，大家的关注点也逐渐从资源层转移到应用层。一方面，我们看到在有越来越多新的 k8s Operators 出现，用来自动化应用的部署和运维。另一方面，随着各路大型云厂商入场，k8s 服务以后就会像家里的水和电一样随心所欲可用，自己再去动手搭建已经没有了意义。于是人们提出了“k8s 将会消失”，这其实指的是以 k8s 为底座来面向全世界任何一个云以及数据中心交付应用，会是接下来的必然趋势。关于这个趋势，我们团队的同学专门在 InfoQ 上写过一篇关于《K8s 多集群/多云技术与发展》的文章，欢迎大家进一步阅读。

相关链接:

• Why Kubernetes will disappear: https://levelup.gitconnected.com/why-kubernetes-will-disappear-10ffcfb39f01
  

• 云原生时代， Kubernetes 多集群架构初探: https://www.infoq.cn/article/sbwSX8ypxgID2-SB723K
  

Tekton 项目有什么特殊之处？

基于 k8s 做应用发布的工具，我们有着许多选择，其中不乏业界知名项目 Jenkins X、Spinnaker，也有创业公司出来的小工具比如 Argo Rollout。不过在这其中，我们团队现在主要使用的是 Tekton。这里也有个重要的背景，那就是我们团队要面向多云/多集群交付的，是复杂有状态的阿里巴巴中间件应用。这因素我马上会详细介绍到。

可能还有部分同学还不了解 Tekton 项目是什么？这里我先简单介绍下。Tekton 是一款 k8s 原生的应用发布框架，主要用来构建 CI/CD 系统。它原本是 knative 项目里面一个叫做 build-pipeline 的子项目，用来作为 knative-build 的下一代引擎。然而，随着 k8s 社区里各种各样的需求涌入，这个子项目慢慢成长为一个通用的框架，能够提供灵活强大的能力去做基于 k8s 的构建发布。

可能不少同学会感到疑惑，有这么多功能丰富、声名远扬的项目，为什么我们选择了灰姑娘般的 Tekton？客官别急，容我们先来梳理一下这个平台底座的要求：

1. K8s 原生：流程和概念，尤其是面向用户的部分，需要融入到 k8s 体系中。此外，最好能跟生态里的其他工具互相连通，成为生态的一环。

2. 举个例子：Spinnaker 这个项目是很强大的，但它的设计初衷，是面向公有云进行应用交付用的（以虚拟机为运行时），Kubernetes 只是它所支持的一种 Provider，并且 Provider 还得用 Groovy 写集成插件。这就使得它跟 K8s 的协作是比较别扭的。

3. 灵活扩展：基本上所有工具都不能够满足我们复杂多变的业务需求。这些工具架构本身需要提供足够灵活的扩展性，来快速定制实现所需功能。

4. 举个例子：Argo Rollout 本身的应用发布，是跟 K8s 的 Workload （比如 Deployment ）耦合在一起的。这就不是一个很具备扩展性的做法。最简单的例子：对于复杂有状态应用来说，大多都是用 Operator 或者 OpenKruise 管理的，这时候 Argo Rollout 该怎么办呢？

5. 轻量级：工具本身不能做得“太重”，即不能有太多的组件或太多的概念。小而轻的项目初期易上手、中期易交付、后期易维护。

6. 举个例子：Spinnaker 虽然功能强大，但是这也就意味着它把所有的事情都帮你做了。而我们团队要发布的应用是复杂有状态的中间件应用， 是需要我们写自己的 Rollout Controller 来控制发布流程的。这个要基于 Spinnaker 来做，还得大量做二次开发了，于是原有的众多功能和组件反而成了负担。

7. 白盒化：运行中的管道、步骤等需要“白盒化”，即对外暴露状态。这样才能跟前端工具联通，给用户展示实时状态信息。

8. 举个例子：Tekton 其实只提供 Pipeline 这个一个功能，Pipeline 会被直接映射成 K8s Pod 等 API 资源。而比如应用发布过程的控制，灰度和上线策略，都是我们自己编写  K8s Controller 来实现的，这个可控度其实是我们比较喜欢的。另外，这种设计，也就意味着 Tekton 不会在 K8s 上盖一个”大帽子“，比如我们想看发布状态、日志，就等是直接通过 K8s 查看这个 Pipeline 对应的 Pod 的状态和日志，不需要再面对另外一个 API。

接下来我们在几个候选项目之间做比较：

可以看到，Tekton 在灵活实现定制化功能、k8s 原生性、以及社区里的受欢迎程度等方面可以说还是优势明显的。这也是为什么，我们团队在负责阿里中间件复杂有状态应用的交付工作时，选择了在 Tekton 之上构建应用交付体系。

实践案例：使用 Tekton 自动化应用发布

接下来我们将分享使用 Tekton 自动化应用发布的实践案例。

一个基于 Tekton 的应用发布平台的架构如下：

这里的流程大致是：

1. 用户把需要部署的应用先按照一套标准的应用定义写成 YAML 文件（类似 Helm Chart）；

2. 用户把应用定义 YAML 推送到 Git 仓库里；

3. Tekton CD (一个 k8s Operator) 会监听到相应的改动，根据不同条件生成不同的 Tekton Pipelines；

Tekton CD 里的操作具体分为以下几种情况：

• 如果 Git 改动里有一个应用 YAML 且该应用不存在，那么将渲染和生成 Tekton Pipelines 用来创建应用。

• 如果 Git 改动里有一个应用 YAML 且该应用存在，那么将渲染和生成 Tekton Pipelines 用来升级应用。这里我们会根据应用定义 YAML 里的策略来做升级，比如做金丝雀发布、灰度升级。

• 如果 Git 改动里有一个应用 YAML 且该应用存在且标记了“被删除”，那么将渲染和生成 Tekton Pipelines 用来删除应用。确认应用被删除后，我们才从 Git 里删除这个应用的 YAML。

接下来，我们看一个创建应用的简单例子:

这个例子里面我们生成了一个 Tekton Pipeline。运行这个 pipeline 就可以将应用发布到 k8s 集群上。

用户操作的边界就是 Git，之后所有流程都是自动化的。那么整个过程中用户怎么得到反馈信息呢？这里主要有：

• 过程状态：Tekton Pipeline 本身就是 k8s API object，我们通过汇总 Status 将过程状态信息透出给前端。

• 日志和监控：由于 Tekton Pipeline 启动的都是 k8s Pod，我们可以复用原有的基础设施去收集，然后做一遍汇总。

经验总结

上面给大家介绍了 Tekton 项目的基本原理、以及使用 Tekton 做底座进行应用发布的主要流程。在这里总结一些经验体会：

1. 复用开源技术。少去做造轮子的事情就意味着能够多专注更具价值的事情。

2. 不要只着眼于眼前的需求，还要关注定制化和扩展性，多考虑未来的场景。

3. K8s 应用层接下来将会加速发展。帮助开发者在 k8s 上更好地开发、部署、管理应用，把相关流程标准化，是未来的重要趋势。

另外，Tekton 2019 发展规划中还包括了 conditional execution, cancelling or pausing a workflow, resuming a paused or failed workflow, enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上，未来的应用发布平台将会更加强大。

相关文章：

初探云原生应用管理（一）: Helm 与 App Hub

初探云原生应用管理（二）: 为什么你必须尽快转向 Helm v3

作者介绍:

邓洪超，阿里云容器平台工程师， K8s Operator 第二人，云原生应用标准交付与管理领域知名技术专家。