Tekton Pipeline 教程

前言

☞ 开学季买书大优惠，错过等一年 ☜

Tekton Pipeline 是一个 k8s native 的 pipeline, 任务跑在 pod 中，经过自定义 CRD 去管理任务与工做流等等，我看完 tekton 以后感受是功能很强大，可是有点过分设计了，没有 drone 的简约大方灵活之感。

1.

Task

Tekton Pipeline 的主要目标是单独运行您的任务或做为管道的一部分运行。每一个任务都在 Kubernetes 集群上做为 Pod 运行，每一个步骤都做为本身的容器。这点深得 drone 思想精髓，其实 drone 也有计划将 kubernetes 做为任务执行引擎。

Task 定义了须要执行的工做，例如如下是一个简单的任务：

steps 是一系列由任务顺序执行的命令。这个 steps 内的配置几乎与 drone 一模一样。

Task 定义好了以后并不会被执行，建立 TaskRun 时才会执行。这是合理的，至关因而一个触发。

$ kubectl apply -f < name-of-file.yaml >

查看 TaskRun：

状态 Succeeded = True 显示任务已成功运行。

2.

任务输入和输出

在更常见的场景中，任务须要多个步骤来处理输入和输出资源。例如，Task 能够从 GitHub 存储库获取源代码并从中构建 Docker 镜像。

PipelinesResources 用于定义任务的输入(如代码)与输出(如 Docker 镜像)。有一些系统定义的资源类型可供使用，如下是一般须要的两个资源示例。

该 git 资源能够是你要编译的代码：

该 image 资源表明要被任务编译成的镜像：

如下是 Task 输入和输出。输入资源是 GitHub 存储库，输出是从该源生成的图像。任务命令的参数支持模板化，所以任务的定义是常量，参数的值能够在运行时更改。

TaskRun 将输入和输出绑定到已定义的 PipelineResources 值，除了执行任务步骤外，还将值设置为用于模板化的参数。

inputs 和 outputs 应当不限制死必须叫这两个名字，只要是能支持参数就好。好比定义一个叫 build 的资源去指定 docker build 的镜像：

Task 里：

我是以为须要能进行这样的扩展了, 仅是 inputs 和 outputs 就狭义了。

获取 pipeline所有信息：

$ kubectl get build-pipeline
NAME                                                   AGE
taskruns/build-docker-image-from-git-source-task-run   30s

NAME                                          AGE
pipelineresources/skaffold-git                6m
pipelineresources/skaffold-image-leeroy-web   7m

NAME                                       AGE
tasks/build-docker-image-from-git-source   7m

要查看 TaskRun 的输出，请使用如下命令：

类型的状态 Succeeded = True 显示 Task 已成功运行，你还能够验证 Docker 镜像是否生成。

3.

Pipeline

Pipeline 定义要按顺序执行的任务列表，同时还经过使用该 from 字段指示是否应将任何输出用做后续任务的输入，并指示执行的顺序（使用 runAfter 和 from 字段）。你在任务中使用的相同模板也能够在管道中使用。

以上 Pipeline 是引用一个 Task deploy-using-kubectl：

要运行 Pipeline，请建立 PipelineRun 以下：

执行与查看 pipeline:

$ kubectl apply -f < name-of-file.yaml >
$ kubectl get pipelineruns tutorial-pipeline-run-1 -o yaml

总结

初学者会以为有点绕，可是这种设计也是为了解耦合，我我的以为优劣以下：

优点：

• 能够把k8s集群做为任务执行引擎，这样能够更好的利用资源，好比把线上夜间闲置资源用来跑任务，构建镜像 离线分析 甚至机器学习。

• 解耦作的比较好，任务模板能够拿来复用，而不须要你们都去重复定义。

• 输入输出理念，一个任务的输入做为另个任务的输出不错

劣势：

• 有点过分设计，一些简单的场景可能以为配置起来有点绕了。

• 输入输出依赖分布式系统，对比 drone 一个 pipeline 中的容器是共享了一个数据卷的，这样上个任务产生的文件很方便的给下个任务用，而基于集群的任务就可能得依赖 git docker 镜像仓库等作输入输出，有点麻烦，好的解决办法是利用 k8s 分布试存储给 pipeline 设置一个共享卷，方便任务间传输数据。

整体来讲路子是对的，并且仍是有不少场景能够用的。

● 之后别人再问你什么是 Istio，就把这篇文章甩给他

● Kubectl 的替代品：kubeman

● Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量

云原生是一种信仰 🤘

扫码关注公众号

回复 「电子书」下载 Kubernetes 指南

点击 "阅读原文" 获取更多资源！

         
 
 
          
 
           
 
            
 
             
 
              
 
               
 
                ❤️ 
                给个 
                「在看」 
                ，是对我最大的支持❤️ 
               
 
              
 
             
 
            
 
           
 
          
 

         

本文分享自微信公众号 - 云原生实验室（cloud_native_yang）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。