背景
近年来,伴随着云原生社区 (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?客官别急,容我们先来梳理一下这个平台底座的要求:
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。
接下来我们在几个候选项目之间做比较:
可以看到,Tekton 在灵活实现定制化功能、k8s 原生性、以及社区里的受欢迎程度等方面可以说还是优势明显的。这也是为什么,我们团队在负责阿里中间件复杂有状态应用的交付工作时,选择了在 Tekton 之上构建应用交付体系。
实践案例:使用 Tekton 自动化应用发布
接下来我们将分享使用 Tekton 自动化应用发布的实践案例。
一个基于 Tekton 的应用发布平台的架构如下:
这里的流程大致是:
用户把需要部署的应用先按照一套标准的应用定义写成 YAML 文件(类似 Helm Chart);
用户把应用定义 YAML 推送到 Git 仓库里;
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 做底座进行应用发布的主要流程。在这里总结一些经验体会:
复用开源技术。少去做造轮子的事情就意味着能够多专注更具价值的事情。
不要只着眼于眼前的需求,还要关注定制化和扩展性,多考虑未来的场景。
K8s 应用层接下来将会加速发展。帮助开发者在 k8s 上更好地开发、部署、管理应用,把相关流程标准化,是未来的重要趋势。
另外,Tekton 2019 发展规划中还包括了 conditional execution, cancelling or pausing a workflow, resuming a paused or failed workflow, enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上,未来的应用发布平台将会更加强大。
相关文章:
初探云原生应用管理(二): 为什么你必须尽快转向 Helm v3
作者介绍:
邓洪超,阿里云容器平台工程师, K8s Operator 第二人,云原生应用标准交付与管理领域知名技术专家。
评论 1 条评论