基于 K8s 做应用发布的工具那么多, 阿里为啥选择灰姑娘般的 Tekton ？( 三 )_：基于K8s做应用发布的工具那么多,阿里

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

K8s 原生：流程和概念，尤其是面向用户的部分，需要融入到 k8s 体系中。此外，最好能跟生态里的其他工具互相连通，成为生态的一环。举个例子：Spinnaker 这个项目是很强大的，但它的设计初衷，是面向公有云进行应用交付用的（以虚拟机为运行时），Kubernetes 只是它所支持的一种 Provider，并且 Provider 还得用 Groovy 写集成插件。这就使得它跟 K8s 的协作是比较别扭的。灵活扩展：基本上所有工具都不能够满足我们复杂多变的业务需求。这些工具架构本身需要提供足够灵活的扩展性，来快速定制实现所需功能。举个例子：Argo Rollout 本身的应用发布，是跟 K8s 的 Workload （比如 Deployment ）耦合在一起的。这就不是一个很具备扩展性的做法。最简单的例子：对于复杂有状态应用来说，大多都是用 Operator 或者 OpenKruise 管理的，这时候 Argo Rollout 该怎么办呢？轻量级：工具本身不能做得“太重”，即不能有太多的组件或太多的概念。小而轻的项目初期易上手、中期易交付、后期易维护。举个例子：Spinnaker 虽然功能强大，但是这也就意味着它把所有的事情都帮你做了。而我们团队要发布的应用是复杂有状态的中间件应用，是需要我们写自己的 Rollout Controller 来控制发布流程的。这个要基于 Spinnaker 来做，还得大量做二次开发了，于是原有的众多功能和组件反而成了负担。白盒化：运行中的管道、步骤等需要“白盒化”，即对外暴露状态。这样才能跟前端工具联通，给用户展示实时状态信息。举个例子：Tekton 其实只提供 Pipeline 这个一个功能，Pipeline 会被直接映射成 K8s Pod 等 API 资源。而比如应用发布过程的控制，灰度和上线策略，都是我们自己编写 K8s Controller 来实现的，这个可控度其实是我们比较喜欢的。另外，这种设计，也就意味着 Tekton 不会在K8s 上盖一个”大帽子“，比如我们想看发布状态、日志，就等是直接通过 K8s 查看这个 Pipeline 对应的 Pod 的状态和日志，不需要再面对另外一个 API。接下来我们在几个候选项目之间做比较：