初探云原生应用管理之：聊聊 Tekton 项目

【编者的话】“人间四月芳菲尽，山寺桃花始怒放。” 愈来愈多专门给 Kubernetes 作应用发布的工具开始缤纷呈现，帮助你们管理和发布不断增多的 Kubernetes 应用。在作技术选型的时候，咱们须要给业务选择一个最好的工具、最稳的底座。那咱们又该如何比较和衡量这些工具的呢？在这篇文章中阿里一线工程师给你们分享本身独特的体验。洗尽铅华，一块儿品味这“山寺桃花”。

背景

近年来，伴随着云原生社区（CNCF Community）的迅猛发展，愈来愈多的应用跑在了 Kubernetes 上。慢慢地，你们的关注点也逐渐从资源层转移到应用层。一方面，咱们看到在有愈来愈多新的 Kubernetes Operators 出现，用来自动化应用的部署和运维。另外一方面，随着各路大型云厂商入场，Kubernetes 服务之后就会像家里的水和电同样为所欲为可用，本身再去动手搭建已经没有了意义。因而人们提出了“Kubernetes 将会消失”，这其实指的是以 Kubernetes 为底座来面向全世界任何一个云以及数据中心交付应用，会是接下来的必然趋势。关于这个趋势，咱们团队的同窗专门写过一篇关于《云原生时代， 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 的应用发布平台的架构以下：

这里的流程大体是：

1. 用户把须要部署的应用先按照一套标准的应用定义写成 YAML 文件（相似 Helm Chart）；
2. 用户把应用定义 YAML 推送到 Git 仓库里；
3. 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 作底座进行应用发布的主要流程。在这里总结一些经验体会：

1. 复用开源技术。少去作造轮子的事情就意味着可以多专一更具价值的事情。
2. 不要只着眼于眼前的需求，还要关注定制化和扩展性，多考虑将来的场景。
3. 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 默认使用。

活动推荐

【首届云原生应用大赛火热报名中】报名连接：http://t.tb.cn/7aDijN

9月2日前，使用任意语言开发一个能够被容器化、运行在 K8s 上的应用，并把该应用作成 Helm Charts 格式提交便可参赛！苹果 Airpods，Cherry键盘、天猫精灵等丰厚礼品等你拿！