初探云原生应用管理之:聊聊 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键盘、天猫精灵等丰厚礼品等你拿!

原文地址:https://www.cnblogs.com/alisystemsoftware/p/11378157.html

时间: 2024-10-31 18:53:07

初探云原生应用管理之:聊聊 Tekton 项目的相关文章

给 K8s API “做减法”:阿里巴巴云原生应用管理的挑战和实践

作者 | 孙健波(天元)? 阿里巴巴技术专家本文整理自 11 月 21 日社群分享,每月 2 场高质量分享,点击加入社群. 早在 2011 年,阿里巴巴内部便开始了应用容器化,当时最开始是基于 LXC 技术构建容器,然后逐渐切换到 Docker,自研了大规模编排调度系统.到了 2018 年,我们团队依托 K8s 体系开始推进"轻量级容器化",同时投入了工程力量跟开源社区一起解决了诸多规模与性能问题,从而逐步将过去"类虚拟机"的运维链路和阿里巴巴整体应用基础设施架构升

保姆级教程!手把手教你使用Longhorn管理云原生分布式SQL数据库!

作者简介 Jimmy Guerrero,在开发者关系团队和开源社区拥有20多年的经验.他目前领导YugabyteDB的社区和市场团队. 本文来自Rancher Labs Longhorn是Kubernetes的云原生分布式块存储,易于部署和升级,100%开源且持久,由业界采用最为广泛的Kubernetes管理平台创建者Rancher Labs推出,并于去年10月捐献给CNCF.Longhorn的内置增量快照和备份功能可确保volume数据的安全,而其直观的UI可以方便地管理持久卷的计划备份.使用

云原生生态周报 Vol. 13 | Forrester 发布企业级容器平台报告

业界要闻 近日,全球知名市场调研机构 Forrester 发布首个企业级公共云容器平台报告.其中,阿里云容器服务的市场表现全球前三.中国第一,同时创造中国企业最好成绩,进入强劲表现者象限.报告显示,阿里云容器服务市场表现为中国第一,与谷歌云并列全球第三. Forrester 分析师认为:“阿里云容器服务提供了广泛的开发和应用服务支持能力,并且具备丰富的市场生态和合作伙伴体系,是企业在中国寻求完备容器云服务能力的最佳选择. Virtual Kubelet 开源项目发布第一个可商用 1.0 版本,本

CNCF 公布 2020 年 TOC 选举结果 | 云原生生态周报 Vol. 36

作者 | 陈洁.高相林 业界要闻 CNCF TOC 2020 年选举结果公布 2020 年 2 月 3 日,CNCF 进行了 TOC(技术监督委员会)选举,确定了 5 名新增的 TOC 成员,其中 3 名的提名者和投票者来自于 Governing Board,1 名的提名者和投票者来自于维护者,1 名的提名者和投票者来自于最终用户社区. CNCF 发布 2019 年度报告 2019 年 CNCF 新增 173 家成员,增长 50% 以上: KubeCon Shanghai.Barcelona.S

架构师成长系列 | 云原生时代的 DevOps 之道

作者 | 郝树伟(花名:流生)??阿里云高级研发工程师 本文整理自架构师成长系列 2 月17 日直播课程. 关注"阿里巴巴云原生"公众号,回复?"217",即可获取对应直播回放链接及 PPT 下载链接. 导读:DevOps 是一种软件开发人员和 IT人员之间的合作过程,目标是高效地自动执行软件交付和基础架构更改流程.在云原生时代,企业又如何借助 DevOps 实现产品快速.稳定.高效和安全地迭代,释放业务价值呢? 什么是云原生 为了解决传统应用升级缓慢.架构臃肿.不

2020云原生7大趋势预测!

2020云原生7大趋势预测! 过去的几年,是云原生技术和理念得到广泛接受的几年.在这个快速发展的领域,预测未来显得尤其困难,但是我们又有着一些坚定的信念,相信以开放创新为支撑的云原生领域会持续重塑软件生命周期,带来不断的价值. 2019,在众多热门技术趋势中,云原生的关注度居高不下,很多开发者都对由此而兴起的一众技术十分追捧,众多企业开始探索云原生架构转型落地.在中国,开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变. 在筹备阿里云首届云原生实践峰会的过程中,我们展开了对云原生技

云原生应用程序架构的五大特性(上)- 12要素应用

12要素的概念最早诞生于Heroku的工程师手中,说白了,其实就是云原生应用程序架构的模式集合,它描述了一个应用程序的原型,最好地诠释了采纳云原生应用程序架构的原因. 通过突出陈述性配置和水平扩展的无状态/无共享进程,以及整体上与部署环境的松耦合连接,这些模式实现了速度性.安全性和可扩展性.在当下,Cloud Foundry.Heroku和Amazon Elastic Beanstalk等云应用程序平台都已经为部署12要素应用进行了优化. 12要素视应用程序为可独立部署的单元,企业通常将多个可协

微服务架构与实践及云原生等相关概念

微服务架构与实践 笔记:<微服务架构与实践> 王磊 著 一 单块架构 1 定义:对于这种功能集中.代码和数据中心化.一个发布包.部署后运行在同一进程的应用程序,我们通常称之为单块架构应用,并非物理上的分层. 2 单层架构:数据 逻辑 页面 混合 3 三层架构: 1)表示层:数据显示和用户交互 2)业务逻辑层:业务逻辑处理 3)数据访问层:数据存储访问 4 优势: 比较适合小项目 易于开发:开发简单直接,集中式管理,基本不会重复开发,集成工具适合 易于测试:单进程 易于部署:单项目包,功能都在本

开放软件时代,云原生的数字化公司是否会爆发?

(上图为Pivotal公司副总裁.亚太及日本地区常务董事Lionel Lim) 2017年7月4日,福布斯技术委员会发布了新一代爆发公司排行榜,该排行榜试图预测下一个科技巨头,发现那些即将飞跃的公司.在2017爆发公司排行榜里出现了一个不那么耳熟能详的公司名字:Pivotal,仅次于Airbnb.Lyft.NVidia而名列第四位,而后面跟的是Salesforce.Snapchat.Tesla和Uber等公司. Pivotal专注于PaaS平台业务,可以与之相类比的是26年前诞生的Linux.2