标签:案例 charts 选项 用户操作 ima 历史 复用 object 各路
【编者的话】“人间四月芳菲尽,山寺桃花始盛开。” 越来越多专门给 Kubernetes 做应用发布的工具开始缤纷呈现,帮助大家管理和发布不断增多的 Kubernetes 应用。在做技术选型的时候,我们需要给业务选择一个最好的工具、最稳的底座。那我们又该如何比较和衡量这些工具的呢?在这篇文章中阿里一线工程师给大家分享自己独特的体验。洗尽铅华,一起品味这“山寺桃花”。
近年来,伴随着云原生社区(CNCF Community)的迅猛发展,越来越多的应用跑在了 Kubernetes 上。慢慢地,大家的关注点也逐渐从资源层转移到应用层。一方面,我们看到在有越来越多新的 Kubernetes Operators 出现,用来自动化应用的部署和运维。另一方面,随着各路大型云厂商入场,Kubernetes 服务以后就会像家里的水和电一样随心所欲可用,自己再去动手搭建已经没有了意义。于是人们提出了“Kubernetes 将会消失”,这其实指的是以 Kubernetes 为底座来面向全世界任何一个云以及数据中心交付应用,会是接下来的必然趋势。关于这个趋势,我们团队的同学专门写过一篇关于《云原生时代, Kubernetes 多集群架构初探》的文章,欢迎大家进一步阅读。
基于 Kubernetes 做应用发布的工具,我们有着许多选择,其中不乏业界知名项目 Jenkins X、Spinnaker,也有创业公司出来的小工具比如 Argo Rollout。不过在这其中,我们团队现在主要使用的是 Tekton。这里也有个重要的背景,那就是我们团队要面向多云/多集群交付的,是复杂有状态的阿里巴巴中间件应用。这因素我马上会详细介绍到。
可能还有部分同学还不了解 Tekton 项目是什么?这里我先简单介绍下。Tekton 是一款 Kubernetes 原生的应用发布框架,主要用来构建 CI/CD 系统。它原本是 Knative 项目里面一个叫做 build-pipeline 的子项目,用来作为 knative-build 的下一代引擎。然而,随着 Kubernetes 社区里各种各样的需求涌入,这个子项目慢慢成长为一个通用的框架,能够提供灵活强大的能力去做基于 Kubernetes 的构建发布。
可能不少同学会感到疑惑,有这么多功能丰富、声名远扬的项目,为什么我们选择了灰姑娘般的 Tekton?客官别急,容我们先来梳理一下这个平台底座的要求:
接下来我们在几个候选项目之间做比较:
可以看到,Tekton 在灵活实现定制化功能、Kubernetes 原生性、以及社区里的受欢迎程度等方面可以说还是优势明显的。这也是为什么,我们团队在负责阿里中间件复杂有状态应用的交付工作时,选择了在 Tekton 之上构建应用交付体系。
接下来我们将分享使用 Tekton 自动化应用发布的实践案例。
一个基于 Tekton 的应用发布平台的架构如下:
这里的流程大致是:
Tekton CD 里的操作具体分为以下几种情况:
接下来,我们看一个创建应用的简单例子:
这个例子里面我们生成了一个 Tekton Pipeline。运行这个 Pipeline 就可以将应用发布到 Kubernetes 集群上。
用户操作的边界就是 Git,之后所有流程都是自动化的。那么整个过程中用户怎么得到反馈信息呢?这里主要有:
上面给大家介绍了 Tekton 项目的基本原理、以及使用 Tekton 做底座进行应用发布的主要流程。在这里总结一些经验体会:
另外,Tekton 2019 发展规划中还包括了 conditional execution,cancelling or pausing a workflow,resuming a paused or failed workflow,enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上,未来的应用发布平台将会更加强大。
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键盘、天猫精灵等丰厚礼品等你拿!
标签:案例 charts 选项 用户操作 ima 历史 复用 object 各路
原文地址:https://www.cnblogs.com/alisystemsoftware/p/11378157.html