1. CICD 平台的基本功能
常见的 CICD 引擎并不适合直接提供给业务方使用。主要原因在于用户学习成本高、缺乏必要的鉴权、维护升级难度大。
我们通常会基于流程引擎，针对业务进行适配提高易用性，针对场景进行封装收敛复杂度，那么一个 CICD 平台需要具备哪些基本的功能呢？
- 流程编排。基本而又核心的功能，借助开源的编排引擎即可。
- 流程原子。流程原子组装得到流水线，越丰富的流程原子，越能够满足业务方的需求。
- 流程控制。主要包括条件执行、暂停、继续、审批等，允许控制流水线的行为。
- 自动触发。通过 API、Webhook 等方式自动触发流水线，会给使用方带来很大便利。
- 权限控制。作为一个面向用户的平台，权限控制比不可少。
Tekton 作为云原生下的 CICD 引擎，用来构建面向 Kubernetes 基础设施的 CICD 平台，非常适用。本篇主要想和大家分享的是 Tekton 流程控制，特别是审批的功能。
2. Tekton 中的流程控制
2.1 runAfter
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | - name: test-app taskRef: name: make-test resources: inputs: - name: workspace resource: my-repo - name: build-app taskRef: name: kaniko-build runAfter: - test-app resources: inputs: - name: workspace resource: my-repo |
|---|
通过 runAfter 关键字可以控制任务的执行顺序，上面的示例中 build-app 会在 test-app 执行完成之后执行。使用 runAfter 可以实现对流程的编排。
2.2 conditions
这里首先创建一个 Condition 对象，检查代码仓库中是否存在指定文件。
1 2 3 4 5 6 7 8 9 10 11 12 13 | apiVersion: tekton.dev/v1alpha1 kind: Condition metadata: name: file-exists spec: params: - name: "path" resources: - name: workspace type: git check: image: alpine script: 'test -f $(resources.workspace.path)/$(params.path)' |
|---|
在创建 Pipeline 时，只需要在 Task 中引用这个 Condition，提供必要的参数即可。下面这个例子中，仅当代码仓库中存在 README.md 文件时，my-task 任务才会执行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: conditional-pipeline spec: resources: - name: source-repo type: git params: - name: "path" default: "README.md" tasks: - name: if-condition-then-run conditions: - conditionRef: "file-exists" params: - name: "path" value: "$(params.path)" resources: - name: workspace resource: source-repo taskRef: name: my-task |
|---|
2.3 PipelineRunCancelled
当 PipelineRun Spec 中的状态处于 PipelineRunCancelled 时，Reconciler 会提前取消全部 Task 并更新状态。
参考代码: https://github.com/tektoncd/pipeline/blob/c8dc797cf5a6f11f90cb742d014470a444fcdc60/pkg/reconciler/pipelinerun/pipelinerun.go#L147
- 查看正在运行的 pipelinerun
1 2 3 4 | kubectl get pipelineruns.tekton.dev NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME cancel-pipelinerun-r-67qsr Unknown Running 51m |
|---|
- 修改 pipelineruns 的 status 为 PipelineRunCancelled
1 | kubectl patch PipelineRun cancel-pipelinerun-r-67qsr --type=merge -p '{"spec":{"status":"PipelineRunCancelled"}}' |
|---|
- 查看取消的 pipelinerun
1 2 3 4 | kubectl get pipelineruns.tekton.dev NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME cancel-pipelinerun-r-67qsr False PipelineRunCancelled 52m 3s |
|---|
2.4 PipelineRunPending
除了上面的 PipelineRunCancelled 状态，pipelinerun 还有一个状态，PipelineRunPending。PipelineRunPending 实现的效果是，创建 PipelineRun 但不立即运行
- 创建一条 PipelineRunPending 状态的流水线
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | --- apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: pending-pipelinerun spec: params: - name: pl-param-x value: "100" - name: pl-param-y value: "500" pipelineRef: name: pending-pipeline status: "PipelineRunPending" |
|---|
- 查看流水线状态
1 2 3 4 | kubectl get pipelineruns.tekton.dev NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME pending-pipelinerun Unknown PipelineRunPending |
|---|
这条流水线没有执行时间，因为它一直处于等待状态。
- 移除 PipelineRunPending 状态
1 | kubectl patch PipelineRun pending-pipelinerun --type=merge -p '{"spec":{"status":""}}' |
|---|
这条流水线开始执行。
- 查看流水线状态
1 2 3 4 | kubectl get pipelineruns.tekton.dev NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME pending-pipelinerun Unknown Running 4s |
|---|
- 无法将正在运行的流水线修改为 PipelineRunPending 状态
在 Tekton v0.24.1 中无法修改状态为 PipelineRunPending，如果运行将可以实现暂停的效果。
1 2 3 4 | kubectl get pipelineruns.tekton.dev NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME cancel-pipelinerun Unknown Running 9s |
|---|
1 2 3 | kubectl patch PipelineRun cancel-pipelinerun --type=merge -p '{"spec":{"status":"PipelineRunPending"}}' Error from server (BadRequest): admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: invalid value: PipelineRun cannot be Pending after it is started: spec.status |
|---|
validation 限制了这次修改操作。
3. 如何实现审批功能
上面提到了 Tekton 中的几个流程控制方法，但是社区并没有提供、也不准备提供审批的功能。因此，在对 Tekton 进行二次开发时，需要 CICD 平台自行实现审批和权限的控制。下面是两种实现方案，以供参考：
3.1 方案一，使用 Trigger
如上图，可以将用户的一条流水线拆解为两条流水线，pipeline-1/2 和 pipeline-2/2。两条流水线之间引入一个 trigger。
- 当流水线 pipeline-1/2 执行完成时，通知审批者。
- 审批者审批通过后，触发 pipeline-2/2 执行。
- pipeline-2/2 执行结束，完成整条流水线。
Tekton 社区提供了一个 triggers 组件，用来自动化触发流水线。如下图:
- 审批之后，推送一个触发事件 Event
- EventController 收到这个事件之后，从 TriggerBinding 提取出事件内的参数 Parameters
- TriggerTemplate 利用传递过来的参数 Parameters，创建流水线 pipeline-2/2 。
3.2 方案二，开发一个审批 Task
开发 Task 是 Tekton 的主要扩展方式，同时开发 Task 只需要掌握基本的 Shell 和 Yaml 知识即可。这里提供另外一个思路就是开发一个审批 Task。
如上图，在一条流水线中，插入一个用于审批控制的 Task-Approve。
- 在使用审批原子时，需要同步创建一个 ConfigMap，用于保存审批的状态 Status=init
- 当流水线执行完成 Task-beforeApprove 任务时，启动 Task-Approve 任务，修改状态 Status=notifying。Task-Approve 任务一直处于等待状态。
- 发送通知给 Approver，修改状态 Status=notified
- 审批者审批流水线，允许执行，修改状态 Status=success
- Task-Approve 检测到 Status=success，立即结束等待状态，完成当前 Task
- 流水线继续执行审批后的任务 Task-afterApprove，直至结束
下面是一个示例:
首先创建一个 ConfigMap 用于保存审批状态。
1 2 3 4 5 6 | apiVersion: v1 kind: ConfigMap metadata: name: approve-cm data: status: init |
|---|
编写一个审批的 Task，默认等待 24 小时审批，否则超时。如果将状态修改为 success 则审批通过，如果将状态修改为 refused 则表示拒绝。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: approve-task spec: workspaces: - name: data params: - name: timeout description: The max seconds to approve type: string default: "86400" steps: - name: sleep-a-while image: bash:latest script: | #!/usr/bin/env bash end=$((SECONDS $(params.timeout))) while [ $SECONDS -lt $end ]; do name=$(cat "$(workspaces.data.path)"/status) if [ "$name" = "success" ] then echo "approved!" exit 0 elif [ "$name" = "refused" ] then echo "refused!" exit 1 fi sleep 2 echo "waiting" done echo "too long not to approve" exit 1 |
|---|
然后，创建一个测试用例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: something annotations: description: | A simple task that do something spec: steps: - name: do-something image: bash:latest script: | #!/usr/bin/env bash uname -a --- apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: approve-pipeline spec: workspaces: - name: workspace tasks: - name: wait-for-approve workspaces: - name: data workspace: workspace taskRef: name: approve-task - name: do-something taskRef: name: something runAfter: - wait-for-approve --- apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: approve-pipelinerun spec: workspaces: - name: workspace configmap: name: approve-cm pipelineRef: name: approve-pipeline |
|---|
- 创建之后查看流水线
日志中会一直输出 waiting。
- 审批通过
1 | kubectl patch ConfigMap approve-cm --type=merge -p '{"data":{"status":"success"}}' |
|---|
- 查看流水线状态
4. 总结
在进行 Tekton 二次开发时，审批是很难绕开的功能，但社区并没有提供相关的特性。本文首先介绍了 Tekton 中流程控制方法，然后提供了两种实现审批功能的方案。下面对方案进行简单的对比和总结:
4.1 使用 Trigger 审批
优点
- 灵活，审批之后的执行，完全由开发者控制，自由度更大。同时也可以使用后台任务替换 Trigger，使用 Tekton Client 创建流水线。
- 可靠，即使重启也不会影响审批。
缺点
- 拆分之后可能不止两条流水线。
- 需要跨流水线传递参数、产物，增加了维护的成本。
- 架构复杂度增加，引入了新的组件、后台处理逻辑
4.2 开发一个审批 Task
优点
- 使用简单。一条 Pipeline 只有一个 DAG，容易理解。
- 更加符合 Tekton 的扩展方式。
缺点
- 审批 Task 因为节点故障失败时，无法恢复
- 占用集群资源，审批 Task 常驻集群等待。
- ConfigMap 状态更新不及时，会有一个延时(默认在秒级)，大约值为 kubelet 的同步周期加上 ConfigMap 在 kubelet 中缓存的 TTL 时间。
5. 参考
- https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-pod-configmap/
原文：https://www.chenshaowen.com/blog/how-to-implement-approval-function-in-tekton.html
