Kubernetes原生CI/CD构建框架Tekton详解

流水线&＃xff08;Pipeline&＃xff09;是把一个重复的过程分解为若干个子过程&＃xff0c;使每个子过程与其他子过程并行进行的技术。本文主要介绍了诞生于云原生时代的流水线框架 Tekton。

什么是流水线&＃xff1f;

在计算机中&＃xff0c;流水线是把一个重复的过程分解为若干个子过程&＃xff0c;使每个子过程与其他子过程并行进行的技术&＃xff0c;也叫 Pipeline。由于这种 s工作方式与工厂中的生产流水线十分相似&＃xff0c; 因此也被称为流水线技术。从本质上讲&＃xff0c;流水线技术是一种时间并行技术。以“构建镜像”过程为例&＃xff1a;

一次构建镜像中&＃xff0c;我们都需要拉下代码仓库中的代码&＃xff0c;进行代码编译&＃xff0c;构建镜像&＃xff0c;最后推往镜像仓库。在每一次代码更改过后&＃xff0c;这一过程都是不变的。使用流水线工具可以极大的提升这一过程的效率&＃xff0c;只需要进行简单的配置便可以轻松的完成重复性的工作。这样的过程也被称之为 CI。

上图流程中使用的是 Jenkins。Jenkins 作为老牌流水线框架被大家所熟知。在云原生时代&＃xff0c;Jenkins 也推出了 Jenkins X 作为基于 Kubernetes 的新一代流水线&＃xff0c;但今天本文主要介绍诞生于云原生时代的流水线框架——Tekton。

Tekton

Tekton 是一个基于 Kubernetes 的云原生 CI/CD 开源框架&＃xff0c;属于 CD 基金会的项目之一。Tekton 通过定义 CRD 的方式&＃xff0c;让用户以灵活的自定义流水线以满足自身 CI/CD 需求。

基本概念

四个基本概念

Tekton 最主要的四个概念为&＃xff1a;Task、TaskRun、Pipeline 以及 PipelineRun。

• Task&＃xff1a;Task 为构建任务&＃xff0c;是 Tekton 中不可分割的最小单位&＃xff0c;正如同 Pod 在 Kubernetes 中的概念一样。在 Task 中&＃xff0c;可以有多个 Step&＃xff0c;每个 Step 由一个 Container 来执行。

• Pipeline&＃xff1a;Pipeline 由一个或多个 Task 组成。在 Pipeline 中&＃xff0c;用户可以定义这些 Task 的执行顺序以及依赖关系来组成 DAG&＃xff08;有向无环图&＃xff09;。

• PipelineRun&＃xff1a;PipelineRun 是 Pipeline 的实际执行产物&＃xff0c;当用户定义好 Pipeline 后&＃xff0c;可以通过创建 PipelineRun 的方式来执行流水线&＃xff0c;并生成一条流水线记录。

• TaskRun&＃xff1a;PipelineRun 被创建出来后&＃xff0c;会对应 Pipeline 里面的 Task 创建各自的 TaskRun。一个 TaskRun 控制一个 Pod&＃xff0c;Task 中的 Step 对应 Pod 中的 Container。当然&＃xff0c;TaskRun 也可以单独被创建。

综上可知&＃xff1a;Pipeline 由多个 Task 组成&＃xff0c;每次执行对应生成一条 PipelineRun&＃xff0c;其控制的 TaskRun 将创建实际运行的 Pod。下面以一个简单例子来展示这些概念。

首先&＃xff0c;创建一个最简单的 Task&＃xff0c;里面仅有一个 Step。在一个 ubuntu 镜像中执行 ls 命令。

接着创建一个 Pipeline&＃xff0c;里面引用第一步中创建的 Task。

在 Pipeline 存在的前提下&＃xff0c;就可以通过创建 PipelineRun 来运行 Pipeline。

这样就完成了一个最简单的 Tekton 流水线案例。每一个 PipelineRun 的创建&＃xff0c;都会遵循 Pipeline 中的顺序规则去启动 Task 的 Pod。下面引入另外一个概念 PipelineResource 来完成一个稍微复杂的例子&＃xff0c;也是 DevOps 中最常见的场景&＃xff1a;从代码仓库拉取镜像、进行代码构建、并最终将构建好的镜像推往镜像仓库。

PipelineResource

PipelineResource 代表着一系列的资源&＃xff0c;主要承担作为 Task 的输入或者输出的作用。它有以下几种类型&＃xff1a;

• Git&＃xff1a;代表一个 Git 仓库&＃xff0c;包含了需要被构建的源代码。将 Git 资源作为 Task 的 Input&＃xff0c;会自动 clone 此 Git 仓库。

• pullRequest&＃xff1a;表示来自配置的 url&＃xff08;通常是一个 Git 仓库&＃xff09;的 pull request 事件。将 pull request 资源作为 Task 的 Input&＃xff0c;将自动下载 pull request 相关元数据的文件&＃xff0c;如 base/head commit、comments 以及 labels。

• Image&＃xff1a;代表镜像仓库中的镜像&＃xff0c;通常作为 Task 的 Output&＃xff0c;用于生成镜像。

• Cluster&＃xff1a;表示一个除了当前集群外的 Kubernetes 集群。可以使用 Cluster 资源在不同的集群上部署应用。

• Dtorage&＃xff1a;表示 blob 存储&＃xff0c;它包含一个对象或目录。将 Storage 资源作为 Task 的 Input 将自动下载存储内容&＃xff0c;并允许 Task 执行操作。目前仅支持 GCS。

• cloud event&＃xff1a;会在 TaskRun z执行完成后发送事件信息&＃xff08;包含整个 TaskRun&＃xff09; 到指定的 URI 地址&＃xff0c;在与第三方通信的时候十分有用。

以上为 Tekton 目前支持的六大 PipelineResource 类型&＃xff0c;具体的配置及使用方法详见 PipelineResource 文档。

文档地址&＃xff1a;https://github.com/tektoncd/pipeline/blob/master/docs/resources.md

继续分析较复杂的流水线案例&＃xff1a;从代码仓库拉取镜像、进行代码构建、并将构建好的镜像推往镜像仓库。从已有的 PipelineResource 类型可判断&＃xff0c;可以使用 git 类型作为代码资源作为输入&＃xff0c;再用 image 类型作为镜像资源作为输出。有了输入输出后&＃xff0c;我们可以直接使用 Kaniko 来构建镜像。

Kaniko 是 Google 开源的项目之一&＃xff0c;可在 Kubernetes 上无需特权模式地构建 Docker 镜像。

首先创建这两个 PipelineResource。在这个例子中&＃xff0c;git-input 对应输入&＃xff0c;image-output 对应输出。params 中的参数均为该资源类型的固定参数&＃xff1a;如 Git 中可以通过 revision 指定版本号&＃xff0c;Image 中可以通过 url 指定镜像仓库地址。

Git-input&＃xff1a;

Image-output&＃xff1a;

在配置 PipelineResource 时&＃xff0c;如果使用了私有仓库&＃xff0c;还需要配置 Service Account&＃xff0c;详见 configuring-authentication-for-docker。

configuring-authentication-for-docker 地址&＃xff1a;https://github.com/tektoncd/pipeline/blob/master/docs/auth.md#configuring-authentication-for-docker

产物传递

创建完 PipelineResource 后&＃xff0c;需要在 Task 中引入它们作为输入输出。那么&＃xff0c;这些资源是如何在 Task 间传递的呢&＃xff1f;

在 Tekton 的分区下&＃xff0c;我们可以看到一个叫做 config-artifact-pvc 和一个叫做 config-artifact-bucket 的 Config Map。从命名就可以看出&＃xff0c;这二者分别代表了产物存储的两种配置方式—— PVC 和存储桶&＃xff08;目前支持 GCS 和 S3&＃xff09;。

以 PVC 为例&＃xff0c;修改 config-artifact-pvc 需要填写两个值&＃xff1a;size 以及 storageClassName。size 默认为 5GiB&＃xff0c;storage class name 默认为 default。这也意味着当我们使用 PipelineResource 进行资源传递时&＃xff0c;会自动创建一个 5GiB 的存储卷挂载在 Task 上&＃xff0c;供 PipelineResource 使用。

在需要进行 Task 间的资源传递时&＃xff0c;这个存储卷会被挂载在 Task 的 /pvc 目录下。当 Task 执行完成并且需要进行资源传递&＃xff08;通过 inputs/outputs 指定&＃xff09;后&＃xff0c;TaskRun controller 会自动添加一个拷贝文件的步骤容器&＃xff0c;并将输出产物统一放到 /pvc/task_name/resource_name 命名规范的目录下。

上面是针对产物需要进行传递的情况下&＃xff0c;对于目前例子而言&＃xff0c;由于只需要一个 Task&＃xff0c;虽然指定了 Inputs 和 Outputs&＃xff0c;但并没有另一个 Task 来引用这些结果。因此&＃xff0c;在这个例子中并不会去挂载 PVC。

对于 Git 以及 storage 类型的 input&＃xff0c;资源下载后会被 放在 /workspace/task_resource_name 下&＃xff1b;对于 output 则会放在 /workspace/output/resource_name 下。image 类型的资源则会直接上传到镜像仓库。

了解了这些前置知识后&＃xff0c;我们可以来创建 Task 了。Kaniko 需要三个参数来完成镜像构建&＃xff1a;Dockerfile 的地址&＃xff0c;context 的地址以及镜像仓库的地址。在下面这个例子中&＃xff0c;我们大量使用了 params 以及 Tekton 中的变量替换。Params 用于在 TaskRun 和 Task 中传递参数&＃xff0c;而变量替换的格式为 $(xxx)。使用这些变量可以让 Tekton 在运行过程中根据规则进行赋值。值得注意的是&＃xff0c;Tekton 并不会提前去检查这些变量的内容&＃xff0c;这就要求着我们在写的时候需要多加注意。具体的变量编写规则详见&＃xff1a;Tekton variables。

Tekton variables 地址&＃xff1a;https://github.com/tektoncd/pipeline/blob/master/docs/variables.md

有了 Task 后&＃xff0c;就能创建 TaskRun 来执行 Task。注意&＃xff0c;在 spec 中申明了 serviceAccountName 用于指定私有仓库的权限。

至此&＃xff0c;一个更为复杂的流水线也构建完成了。

DAG

在 Tekton 中&＃xff0c;DAG&＃xff08;有向无环图&＃xff09;的功能是原生支持的。只需要通过申明 runAfter 及 from 便可以便利的使 Pipeline 以 DAG 方式运行。

• from&＃xff1a;当 Task 的 Inputs 依赖于上一个 Task 的 Outputs 时&＃xff0c;可以通过 from 参数来指定

• runAfter&＃xff1a;当 Task 间没有资源依赖&＃xff0c;但需要使一个 Task 在另外一个 Task 之后运行的话&＃xff0c;可以使用 runAfter 来指定

例如在上面的例子中&＃xff0c;任务会以下顺序运行&＃xff1a;

• lint-repo 和 test-app 中的 Task 没有 from 或 runAfter 关键字&＃xff0c;会同时开始执行。

• 一旦 test-app 完成&＃xff0c;build-app 和 build-frontend 都会开始同时执行&＃xff0c;因为它们 runAfter 于 test-app。

• deploy-all 会在 build-app 和 build-frontend 都完成后才执行&＃xff0c;因为它需要的资源 from 于这二者。

再来看看 Tekton 是怎么样来实现这段逻辑的&＃xff1a;

在 Pipeline 的 Controller 中&＃xff0c;一旦监听到 Pipeline 的创建&＃xff0c;在创建对应的 TaskRun 之前&＃xff0c;会先检测 Pipeline 中的依赖顺序并构建 DAG 图&＃xff1a;

Step 执行顺序

Pipeline 中可以进行对 Task 的顺序控制&＃xff0c;那么 Task 中呢&＃xff1f;

在 Kubernetes 中&＃xff0c;Pod 里的 Container 是并行启动的。而在 Tekton 中&＃xff0c;虽然 Task 对应 Pod&＃xff0c;Task 中的 Step 对应 Container&＃xff0c;但 Task 中的 Step 却是顺序执行的。要了解 Tekton 是怎么完成这样的顺序控制&＃xff0c;首先我们来看一下一个 Tekton 的 Pod。

在这个 Pod 中&＃xff0c;除了用户需要运行的 Container&＃xff0c;还被注入了一个 InitContainer&＃xff1a;

这个 InitContainer copy 了一个 entrypoint 的二进制到 Pod 中。再看下用户的 container&＃xff0c;我们可以看到 Pod 的执行命令被 Tekton 改写了一下&＃xff1a;

可以看到 command 被改写为了 entrypoint 命令&＃xff0c;这个二进制包在 initContainer 中被导入&＃xff0c;另外还有一些启动参数&＃xff1a;

• -post_file&＃xff1a;指定了 Step 完成后的文件写入路径。如果 Step 失败&＃xff0c;则写入到 {{post_file}}.err。可以看到上面的写入路径为 /tekton/tools/0&＃xff0c;最后的这个数字即为 Step 的编号。

• -wait_file&＃xff1a;指定了在启动下一个 Step 之前要查看的文件路径。它将监听 {{wait_file}} 和 {{wait_file}}.err。若有错误则跳过执行写入 {{post_file}}.err 并返回错误&＃xff08;exitCode >&＃61; 0&＃xff09;&＃xff1b;若无错误则执行下一个 Step。如上例子为第一个 step&＃xff0c;若为第二个 step&＃xff0c;wait_ file 的地址会是 /tekton/tools/0&＃xff0c;也就是上一个 step 的 post_file 地址。

资源控制

在 Kubernetes 中&＃xff0c;一个 Pod 被调度需要节点满足 Pod 中的所有 Container 的资源。如下图&＃xff1a;

这个 Pod 有 4 个容器&＃xff0c;总共需要 9 个 CPU。Kubernetes 将把这个 Pod 调度到一个拥有 9 个可用 CPU 的节点上。如果没有节点有 9 个可用 CPU&＃xff0c;Pod 将被调度失败并无法启动。

而对于 Tekton 而言&＃xff0c;因为 Pod 中的 Container 会顺序执行&＃xff0c;所以只需要满足这个 Pod 中资源最大的 Container 即可。对于同一个TaskRun&＃xff0c;Tekton 会获取最大请求&＃xff0c;并让一个 Container 去请求这些资源&＃xff0c;其他都设为 0。

如下&＃xff0c;该 Pod 请求 4 个 CPU&＃xff0c;而不是 9 个。这样的资源控制方式更为合理且所有的 Step 容器仍保留所需要的资源。

在有 LimitRange 限制 Container 必须有资源的的情况下&＃xff0c;每个 Container 最小会设置为 LimitRange 的设置。

源码部分逻辑如下&＃xff1a;

数据传递

除了 PipelineResource 以外&＃xff0c;Tekton 还提供了其他数据传递的方式。

PipelineResource 仍处于 Alpha 版本&＃xff0c;它有可能会被重新设计、替换、弃用或者完全删除。Tekton 社区鼓励用户用 Task 代替 PipelineResources。

Workspace

Workspace 与 Kubernetes 中 Volume 概念几乎保持一致&＃xff0c;只不过并不是 Pod 层级的而是作用于 Tekton 资源层级的。Workspace 在 Pipeline 中使用时是一个抽象的概念&＃xff0c;实际的存储类型需要在 PipelineRun 中指定。详见&＃xff1a;Workspaces&＃xff0c;地址&＃xff1a;https://github.com/tektoncd/pipeline/blob/master/docs/workspaces.md

Results

Tekton 提供了一个固定目录用于存放 Task 的输出&＃xff1a;/tekton/results

如上&＃xff0c;该 task 将日期输出到了 /tekton/results/current-date 中。同时&＃xff0c;也会被作为 Results 字段加到 TaskRun 的 Status 中。这样&＃xff0c;其他的 Task 便可以通过 $(tasks..results.) 来获取到该 Task 的 results。&＃xff08;变量替换将会实际从 TaskRun 中获取到 Results 的值&＃xff09;

其他流程控制功能

条件判断

低版本可以使用 Conditions&＃xff0c;高版本推荐使用 WhenExpressions&＃xff08;Conditions 将在不久后废弃&＃xff0c;完全替换为 WhenExpressions&＃xff09;。WhenExpressions 由 Input、Operator、Values 三部分组成&＃xff0c;其中 Input 可以使用 Tekton 的 Parameter 或者 Results&＃xff0c;Operator 目前仅支持 in 和 notin&＃xff1a;

错误重尝

通过 retries 来指定任务失败后重新尝试的次数&＃xff1a;

退出处理

通过 finally 指定在 pipeline 结束时执行的 task&＃xff0c;无论 pipeline 的结果是成功或失败。

取消执行

要取消当前正在执行的 PipelineRun&＃xff0c;可以在其 Spec 中更新 Status 为取消。当 PipelineRun 被取消时&＃xff0c;所有相关的 Pods 都被删除。例如&＃xff1a;

Pipeline 暂停的逻辑与之类似&＃xff0c;但暂停 PR 尚未合入&＃xff0c;暂停功能也在 Tekton 今年的 Roadmap 中。

Runs

Runs 是一个进行中的 feature&＃xff0c;Run 允许实例化和执行一个 Custom Task&＃xff0c;这个 Custom Task 可以通过用户自定义的 controller 来执行。这对于用户来说是一个非常实际的功能&＃xff0c;可以通过自己写的 Controller 来定义 Task 的逻辑&＃xff0c;而不再拘泥于 Tekton 定义的 Task。

文章来源&＃xff1a;K8sMeetup社区&＃xff0c;点击查看原文。

Kubernetes管理员认证&＃xff08;CKA&＃xff09;培训

本次CKA培训在北京开班&＃xff0c;基于最新考纲&＃xff0c;通过线下授课、考题解读、模拟演练等方式&＃xff0c;帮助学员快速掌握Kubernetes的理论知识和专业技能&＃xff0c;并针对考试做特别强化训练&＃xff0c;让学员能从容面对CKA认证考试&＃xff0c;使学员既能掌握Kubernetes相关知识&＃xff0c;又能通过CKA认证考试&＃xff0c;学员可多次参加培训&＃xff0c;直到通过认证。点击下方图片或者阅读原文链接查看详情。