可能是最适合自定义的 Pipeline：Tekton

Thu, 03 Oct 2019 20:37:11 +0800

持续集成是云原生应用的支柱技术之一，因此在交付基于云原生的一些支撑产品的时候，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 项目提供一定的帮助。

tekton | 伪架构师

可能是最适合自定义的 Pipeline：Tekton

安装

概念

Hello world

下载文件并显示内容

文件传递

结果