可能是最适合自定义的 Pipeline：Tekton
持续集成是云原生应用的支柱技术之一，因此在交付基于云原生的一些支撑产品的时候，CICD 是一个无法拒绝的需求。为了满足这种需要，自然而然会想到对 Jenkins(X) 或者 Gitlab 进行集成，然而这两个东西虽说功能强大，却也不是为了做螺丝钉而设计的，其中包含了大量的周边功能，并非我们产品的需要，并且其接口和 Pipeline 设计也不太容易复用和提供给用户进行定制，而 Tekton 这个东西就有趣多了：
- Kubernetes 原生 Tekton 的所有配置都是使用 CRD 方式进行编写存储的，非常易于检索和使用。
- 配置和流程分离 Tekton 的 Pipeline 和配置可以分开编写，使用名称进行引用。
- 轻量级 核心的 Pipeline 非常轻便，适合作为组件进行集成，另外也有周边的 Dashboard、Trigger、CLI 等工具，能够进一步挖掘其潜力。
- 可复用、组合的 Pipeline 构建方式 非常适合在集成过程中对 Pipeline 进行定制。
安装
安装过程非常轻松：
$ kubectl apply -f \
https://storage.googleapis.com/tekton-releases/latest/release.yaml
namespace/tekton-pipelines created
podsecuritypolicy.policy/tekton-pipelines created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-admin created
...
$ kubectl get pods -n tekton-pipelines
NAME READY STATUS RESTARTS AGE
tekton-pipelines-controller-5888756f5c-t5kgx 1/1 Running 0 2m10s
tekton-pipelines-webhook-7494f6f84b-gm92g 1/1 Running 0 2m10s
概念
今天的内容主要涉及几个 CRD：
Task：任务环节。
TaskRun：Task 对象的运行参数。
Pipeline：Task 的组合。
PipelineRun：Pipeline 的运行参数。
Hello world
这里有个比 Hello world 稍稍复杂一点的小例子：
下载一个文件。
传递给下一个环节。
为什么不用官方例子呢？我想糊弄过 CI/CD/DevOps 的同学们应该都清楚，能使用容器、能执行 Shell、能获得输出、能传递文件，这几个能力加起来，足够冒充工具链小能手了。循序渐进并不适合心急的朋友们。
下载文件并显示内容
首先引入的是 Task 对象：
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: get-http-file
spec:
steps:
- name: show
image: dustise/sleep
command:
- curl
args:
- "-s"
- "https://httpbin.org/ip"
这里定义了一个 Task CRD，使用 kubectl apply -f 提交到集群，会看到 task.tekton.dev/get-http-file created 的反馈信息。
要运行这个环节，可以创建一个 TaskRun 对象：
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
name: get-http-file-run
spec:
taskRef:
name: get-http-file
提交之后，可以使用 kubectl get taskrun get-http-file-run -o yaml 来查看任务执行状况：
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
...
status:
...
conditions:
- message: All Steps have completed executing
reason: Succeeded
status: "True"
type: Succeeded
podName: get-http-file-run-pod-51fddd
...
这里能看到很多任务执行信息，还能看到执行这个步骤的 Pod 名称，看看它的日志：
$ kubectl logs -f get-http-file-run-pod-51fddd
{
"origin": "165.22.223.124, 165.22.223.124"
}
看来 CICD 过程中的日志输出和命令执行基本是有保障的，那么如何完成工件的传递呢？
文件传递
通常我们都会想到使用 PVC 来进行文件存储和共享，例如：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: trans
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
首先把上面的步骤命令行改为：
command:
- curl
args:
- "-s"
- "-o"
- "/share/share.json"
- "https://httpbin.org/ip"
volumeMounts:
- name: trans
mountPath: /share
第二个步骤就更加简单，只要显示文件内容即可：
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: display
spec:
steps:
- name: showcontent
image: alpine
command: ["cat"]
args: ["/share/share.json"]
volumeMounts:
- name: trans
mountPath: /share
这里需要使用 Pipeline 对象把步骤连接起来。
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: pipeline1
spec:
tasks:
- name: step1
taskRef:
name: download
- name: step2
runAfter: [step1]
taskRef:
name: display
这里的定义，使用 Pipeline 对象把两个步骤串联起来，其中使用 taskRef 对我们定义的 download 和 display 两个 Task 对象进行引用，并且使用 runAfter 数组定义先后顺序。
和 TaskRun 类似，Pipeline 定义之后，还需要用 PipelineRun 对象来执行一次，上面的 Task 中只定义了 volumeMounts，具体的 Volume 就要在 PipelineRun 中定义：
apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
name: pprun1
spec:
pipelineRef:
name: pipeline1
podTemplate:
volumes:
- name: trans
persistentVolumeClaim:
claimName: trans
把 PipelineRun 提交到集群之后，就可以看到，Pipeline 开始运行，可以使用 kubectl get 和 kubectl logs 来查看运行情况。
结果
这个项目还是很符合它的名字的描述的，真的只有 Pipeline 而已，它的最重要职责就是用 CRD 进行解耦，用 Step->Task->Pipeline 的三级形式对 CICD 中的动作进行抽象和分离；用 Task/TaskRun 以及 Pipeline/PipelineRun/Resource 的组合，把运行环节和输入输出内容进行分离。这样一来，就提供了一个稳定、可重构和组合的过程引擎，以及可定制的执行能力。
Tekton 还提供了一些其它周边项目，例如 Dashboard、Trigger 等，能给 Pipeline 项目提供一定的帮助。