前面我们讲解了使用 Jenkins 流水线来实现 Kubernetes 应用的 CI/CD，现在我们来将这个流水线迁移到 Tekton 上面来，其实整体思路都是一样的，就是把要整个工作流划分成不同的任务来执行，前面工作流的阶段划分了以下几个阶段：Clone 代码 -> 单元测试 -> Golang 编译打包 -> Docker 镜像构建/推送 -> Kubectl 部署服务。

在 Tekton 中我们就可以将这些阶段直接转换成 Task 任务，Clone 代码在 Tekton 中不需要我们主动定义一个任务，只需要在执行的任务上面指定一个输入的代码资源即可。下面我们就来将上面的工作流一步一步来转换成 Tekton 流水线，代码仓库同样还是 http://git.k8s.local/course/devops-demo.git。

Clone 代码

虽然我们可以不用单独定义一个 Clone 代码的任务，直接使用 git 类型的输入资源即可，由于这里涉及到的任务较多，而且很多时候都需要先 Clone 代码然后再进行操作，所以最好的方式是将代码 Clone 下来过后通过 Workspace 共享给其他任务，这里我们可以直接使用 Catalog git-clone 来实现这个任务，我们可以根据自己的需求做一些定制，对应的 Task 如下所示：

# task-clone.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: git-clone spec:   workspaces:     – name: output       description: The git repo will be cloned onto the volume backing this Workspace.     – name: basic-auth       optional: true       description: |         A Workspace containing a .gitconfig and .git-credentials file. These         will be copied to the users home before any git commands are run. Any         other files in this Workspace are ignored. It is strongly recommended         to use ssh-directory over basic-auth whenever possible and to bind a         Secret to this Workspace over other volume types.   params:     – name: url       description: Repository URL to clone from.       type: string     – name: revision       description: Revision to checkout. (branch, tag, sha, ref, etc…)       type: string       default: “”     – name: refspec       description: Refspec to fetch before checking out revision.       default: “”     – name: submodules       description: Initialize and fetch git submodules.       type: string       default: “true”     – name: depth       description: Perform a shallow clone, fetching only the most recent N commits.       type: string       default: “1”     – name: sslVerify       description: Set the `http.sslVerify` global git config. Setting this to `false` is not advised unless you are sure that you trust your git remote.       type: string       default: “true”     – name: subdirectory       description: Subdirectory inside the `output` Workspace to clone the repo into.       type: string       default: “”     – name: sparseCheckoutDirectories       description: Define the directory patterns to match or exclude when performing a sparse checkout.       type: string       default: “”     – name: deleteExisting       description: Clean out the contents of the destination directory if it already exists before cloning.       type: string       default: “true”     – name: verbose       description: Log the commands that are executed during `git-clone`s operation.       type: string       default: “true”     – name: gitInitImage       description: The image providing the git-init binary that this Task runs.       type: string       default: “cnych/tekton-git-init:v0.24.1”     – name: userHome       description: |         Absolute path to the users home directory. Set this explicitly if you are running the image as a non-root user or have overridden         the gitInitImage param with an image containing custom user configuration.       type: string       default: “/root”   results:     – name: commit       description: The precise commit SHA that was fetched by this Task.     – name: url       description: The precise URL that was fetched by this Task.   steps:     – name: clone       image: “$(params.gitInitImage)”       env:       – name: HOME         value: “$(params.userHome)”       – name: PARAM_URL         value: $(params.url)       – name: PARAM_REVISION         value: $(params.revision)       – name: PARAM_REFSPEC         value: $(params.refspec)       – name: PARAM_SUBMODULES         value: $(params.submodules)       – name: PARAM_DEPTH         value: $(params.depth)       – name: PARAM_SSL_VERIFY         value: $(params.sslVerify)       – name: PARAM_SUBDIRECTORY         value: $(params.subdirectory)       – name: PARAM_DELETE_EXISTING         value: $(params.deleteExisting)       – name: PARAM_VERBOSE         value: $(params.verbose)       – name: PARAM_SPARSE_CHECKOUT_DIRECTORIES         value: $(params.sparseCheckoutDirectories)       – name: PARAM_USER_HOME         value: $(params.userHome)       – name: WORKSPACE_OUTPUT_PATH         value: $(workspaces.output.path)       – name: WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND         value: $(workspaces.basic-auth.bound)       – name: WORKSPACE_BASIC_AUTH_DIRECTORY_PATH         value: $(workspaces.basic-auth.path)       script: |         #!/usr/bin/env sh         set -eu          if [ “${PARAM_VERBOSE}” = “true” ] ; then           set -x         fi          if [ “${WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND}” = “true” ] ; then           cp “${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.git-credentials” “${PARAM_USER_HOME}/.git-credentials”           cp “${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.gitconfig” “${PARAM_USER_HOME}/.gitconfig”           chmod 400 “${PARAM_USER_HOME}/.git-credentials”           chmod 400 “${PARAM_USER_HOME}/.gitconfig”         fi          CHECKOUT_DIR=”${WORKSPACE_OUTPUT_PATH}/${PARAM_SUBDIRECTORY}”          cleandir() {           # Delete any existing contents of the repo directory if it exists.           #           # We dont just “rm -rf ${CHECKOUT_DIR}” because ${CHECKOUT_DIR} might be “/”           # or the root of a mounted volume.           if [ -d “${CHECKOUT_DIR}” ] ; then             # Delete non-hidden files and directories             rm -rf “${CHECKOUT_DIR:?}”/*             # Delete files and directories starting with . but excluding ..             rm -rf “${CHECKOUT_DIR}”/.[!.]*             # Delete files and directories starting with .. plus any other character             rm -rf “${CHECKOUT_DIR}”/..?*           fi         }          if [ “${PARAM_DELETE_EXISTING}” = “true” ] ; then           cleandir         fi          /ko-app/git-init            -url=”${PARAM_URL}”            -revision=”${PARAM_REVISION}”            -refspec=”${PARAM_REFSPEC}”            -path=”${CHECKOUT_DIR}”            -sslVerify=”${PARAM_SSL_VERIFY}”            -submodules=”${PARAM_SUBMODULES}”            -depth=”${PARAM_DEPTH}”            -sparseCheckoutDirectories=”${PARAM_SPARSE_CHECKOUT_DIRECTORIES}”         cd “${CHECKOUT_DIR}”         RESULT_SHA=”$(git rev-parse HEAD)”         EXIT_CODE=”$?”         if [ “${EXIT_CODE}” != 0 ] ; then           exit “${EXIT_CODE}”         fi         printf “%s” “${RESULT_SHA}” > “$(results.commit.path)”         printf “%s” “${PARAM_URL}” > “$(results.url.path)”

一般来说我们只需要提供 output 这个个用于持久化代码的 workspace，然后还包括 url 和 revision 这两个参数，其他使用默认的即可。

单元测试

单元测试阶段比较简单，正常来说也是只是单纯执行一个测试命令即可，我们这里没有真正执行单元测试，所以简单测试下即可，编写一个如下所示的 Task：

# task-test.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: test spec:   steps:     – name: test       image: golang:1.14-alpine       command: [echo]       args: [this is a test task]  编译打包

然后第二个阶段是编译打包阶段，因为我们这个项目的 Dockerfile 不是使用的多阶段构建，所以需要先用一个任务去将应用编译打包成二进制文件，然后将这个编译过后的文件传递到下一个任务进行镜像构建。

我们已经明确了这个阶段要做的事情，编写任务也就简单了，创建如下所的 Task 任务，首先需要通过定义一个 workspace 把 clone 任务里面的代码关联过来：

# task-build.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: build spec:   workspaces:     – name: go-repo       mountPath: /workspace/repo   steps:     – name: build       image: golang:1.14-alpine       workingDir: /workspace/repo       script: |         go build -v -o app       env:         – name: GOPROXY           value: https://goproxy.cn         – name: GOOS           value: linux         – name: GOARCH           value: amd64

这个构建任务也很简单，只是我们将需要用到的环境变量直接通过 env 注入了，当然直接写入到 script 中也是可以的，或者直接使用 command 来执行任务都可以，然后构建生成的 app 这个二进制文件保留在代码根目录，这样也就可以通过 workspace 进行共享了。

Docker 镜像

接下来就是构建并推送 Docker 镜像了，前面我们介绍过使用 Kaniko、DooD、DinD 3种模式的镜像构建方式，这里我们直接使用 DinD 这种模式，我们这里要构建的镜像 Dockerfile 非常简单:

FROM alpine WORKDIR /home  # 修改alpine源为阿里云 RUN sed -i s/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g /etc/apk/repositories &&    apk update &&    apk upgrade &&    apk add ca-certificates && update-ca-certificates &&    apk add –update tzdata &&    rm -rf /var/cache/apk/*  COPY app /home/ ENV TZ=Asia/Shanghai  EXPOSE 8080  ENTRYPOINT ./app

就行直接将编译好的二进制文件拷贝到镜像中即可，所以我们这里同样需要通过 Workspace 去获取上一个构建任务的制品，当然要使用 DinD 模式构建镜像，需要用到 sidecar 功能，创建一个如下所示的任务：

# task-docker.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: docker spec:   workspaces:     – name: go-repo   params:     – name: image       description: Reference of the image docker will produce.     – name: registry_mirror       description: Specific the docker registry mirror       default: “”     – name: registry_url       description: private docker images registry url   steps:     – name: docker-build # 构建步骤       image: docker:stable       env:         – name: DOCKER_HOST # 用 TLS 形式通过 TCP 链接 sidecar           value: tcp://localhost:2376         – name: DOCKER_TLS_VERIFY # 校验 TLS           value: “1”         – name: DOCKER_CERT_PATH # 使用 sidecar 守护进程生成的证书           value: /certs/client         – name: DOCKER_PASSWORD           valueFrom:             secretKeyRef:               name: harbor-auth               key: password         – name: DOCKER_USERNAME           valueFrom:             secretKeyRef:               name: harbor-auth               key: username       workingDir: $(workspaces.go-repo.path)       script: | # docker 构建命令         docker login $(params.registry_url) -u $DOCKER_USERNAME -p $DOCKER_PASSWORD         docker build –no-cache -f ./Dockerfile -t $(params.image) .         docker push $(params.image)       volumeMounts: # 声明挂载证书目录         – mountPath: /certs/client           name: dind-certs   sidecars: # sidecar 模式，提供 docker daemon服务，实现真正的 DinD 模式     – image: docker:dind       name: server       args:         – –storage-driver=vfs         – –userland-proxy=false         – –debug         – –insecure-registry=$(params.registry_url)         – –registry-mirror=$(params.registry_mirror)       securityContext:         privileged: true       env:         – name: DOCKER_TLS_CERTDIR # 将生成的证书写入与客户端共享的路径           value: /certs       volumeMounts:         – mountPath: /certs/client           name: dind-certs       readinessProbe: # 等待 dind daemon 生成它与客户端共享的证书         periodSeconds: 1         exec:           command: [“ls”, “/certs/client/ca.pem”]   volumes: # 使用 emptyDir 的形式即可     – name: dind-certs       emptyDir: {}

这个任务的重点还是要去声明一个 Workspace，当执行任务的时候要使用和前面构建任务同一个 Workspace，这样就可以获得上面编译成的 app 这个二进制文件了。

部署

接下来的部署阶段，我们同样可以参考之前 Jenkins 流水线里面的实现，由于项目中我们包含了 Helm Chart 包，所以直接使用 Helm 来部署即可，要实现 Helm 部署，当然我们首先需要一个包含 helm 命令的镜像，当然完全可以自己去编写一个这样的任务，此外我们还可以直接去 hub.tekton.dev 上面查找 Catalog，因为这上面就有很多比较通用的一些任务了，比如 helm-upgrade-from-source 这个 Task 任务就完全可以满足我们的需求了：

helm tekton

这个 Catalog 下面也包含完整的使用文档了，我们可以将该任务直接下载下来根据我们自己的需求做一些定制修改，如下所示：

# task-deploy.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: deploy spec:   params:     – name: charts_dir       description: The directory in source that contains the helm chart     – name: release_name       description: The helm release name     – name: release_namespace       description: The helm release namespace       default: “”     – name: overwrite_values       description: “Specify the values you want to overwrite, comma separated: autoscaling.enabled=true,replicas=1”       default: “”     – name: values_file       description: “The values file to be used”       default: “values.yaml”     – name: helm_image       description: “helm image to be used”       default: “docker.io/lachlanevenson/k8s-helm:v3.3.4@sha256:e1816be207efbd342cba9d3d32202e237e3de20af350617f8507dc033ea66803” #tag: v3.3.4   workspaces:     – name: source   results:     – name: helm-status       description: Helm deploy status   steps:     – name: upgrade       image: $(params.helm_image)       workingDir: /workspace/source       script: |         echo current installed helm releases         helm list –namespace “$(params.release_namespace)”          echo installing helm chart…         helm upgrade –install –wait –values “$(params.charts_dir)/$(params.values_file)” –create-namespace –namespace “$(params.release_namespace)” $(params.release_name) $(params.charts_dir) –debug –set “$(params.overwrite_values)”          status=`helm status $(params.release_name) –namespace “$(params.release_namespace)” | awk /STATUS/ {print $2}`         echo ${status} | tr -d ” ” | tee $(results.helm-status.path)

因为我们的 Helm Chart 模板就在代码仓库中，所以不需要从 Chart Repo 仓库中获取，只需要指定 Chart 路径即可，其他可配置的参数都通过 params 参数暴露出去了，非常灵活，最后我们还获取了 Helm 部署的状态，写入到了 Results 中，方便后续任务处理。

回滚

最后应用部署完成后可能还需要回滚，因为可能部署的应用有错误，当然这个回滚动作最好是我们自己去触发，但是在某些场景下，比如 helm 部署已经明确失败了，那么我们当然可以自动回滚了，所以就需要判断当部署失败的时候再执行回滚，也就是这个任务并不是一定会发生的，只在某些场景下才会出现，我们可以在流水线中通过使用 WhenExpressions 来实现这个功能，之前版本中是使用 Conditions，不过已经废弃了。要只在满足某些条件时运行任务，可以使用 when 字段来保护任务执行，when 字段允许你列出对 WhenExpressions 的一系列引用。

WhenExpressions 由 Input、Operator 和 Values 几部分组成：

Input 是 WhenExpressions 的输入，它可以是一个静态的输入或变量(Params 或 Results)，如果未提供输入，则默认为空字符串 Operator 是一个运算符，表示 Input 和 Values 之间的关系，有效的运算符包括 in、notin Values 是一个字符串数组，必须提供一个非空的 Values 数组，它同样可以包含静态值或者变量(Params、Results 或者 Workspaces 绑定)

当在一个 Task 任务中配置了 WhenExpressions，在执行 Task 之前会评估声明的 WhenExpressions，如果结果为 True，则执行任务，如果为 False，则不会执行该任务。

我们这里创建的回滚任务如下所示：

# task-rollback.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: rollback spec:   params:     – name: release_name       description: The helm release name     – name: release_namespace       description: The helm release namespace       default: “”     – name: helm_image       description: “helm image to be used”       default: “docker.io/lachlanevenson/k8s-helm:v3.3.4@sha256:e1816be207efbd342cba9d3d32202e237e3de20af350617f8507dc033ea66803” #tag: v3.3.4   steps:     – name: rollback       image: $(params.helm_image)       script: |         echo rollback current installed helm releases         helm rollback $(params.release_name) –namespace $(params.release_namespace)  流水线

现在我们的整个工作流任务都已经创建完成了，接下来我们就可以将这些任务全部串联起来组成一个 Pipeline 流水线了，将上面定义的几个 Task 引用到 Pipeline 中来，当然还需要声明 Task 中用到的 resources 或者 workspaces 这些数据：

# pipeline.yaml apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata:   name: pipeline spec:   workspaces: # 声明 workspaces     – name: go-repo-pvc   params:     # 定义代码仓库     – name: git_url     – name: revision       type: string       default: “master”     # 定义镜像参数     – name: image     – name: registry_url       type: string       default: “harbor.k8s.local”     – name: registry_mirror       type: string       default: “https://ot2k4d59.mirror.aliyuncs.com/”     # 定义 helm charts 参数     – name: charts_dir     – name: release_name     – name: release_namespace       default: “default”     – name: overwrite_values       default: “”     – name: values_file       default: “values.yaml”   tasks: # 添加task到流水线中     – name: clone       taskRef:         name: git-clone       workspaces:         – name: output           workspace: go-repo-pvc       params:         – name: url           value: $(params.git_url)         – name: revision           value: $(params.revision)     – name: test       taskRef:         name: test     – name: build # 编译二进制程序       taskRef:         name: build       runAfter: # 测试任务执行之后才执行 build task         – test         – clone       workspaces: # 传递 workspaces         – name: go-repo           workspace: go-repo-pvc     – name: docker # 构建并推送 Docker 镜像       taskRef:         name: docker       runAfter:         – build       workspaces: # 传递 workspaces         – name: go-repo           workspace: go-repo-pvc       params: # 传递参数         – name: image           value: $(params.image)         – name: registry_url           value: $(params.registry_url)         – name: registry_mirror           value: $(params.registry_mirror)     – name: deploy # 部署应用       taskRef:         name: deploy       runAfter:         – docker       workspaces:         – name: source           workspace: go-repo-pvc       params:         – name: charts_dir           value: $(params.charts_dir)         – name: release_name           value: $(params.release_name)         – name: release_namespace           value: $(params.release_namespace)         – name: overwrite_values           value: $(params.overwrite_values)         – name: values_file           value: $(params.values_file)     – name: rollback # 回滚       taskRef:         name: rollback       when:         – input: “$(tasks.deploy.results.helm-status)”           operator: in           values: [“failed”]       params:         – name: release_name           value: $(params.release_name)         – name: release_namespace           value: $(params.release_namespace)

整体流程比较简单，就是在 Pipeline 需要先声明使用到的 Workspace、Resource、Params 这些资源，然后将声明的数据传递到 Task 任务中去，需要注意的是最后一个回滚任务，我们需要根据前面的 deploy 任务的结果来判断是否需要执行该任务，所以这里我们使用了 when 属性，通过 $(tasks.deploy.results.helm-status) 获取部署状态。

执行流水线

现在我们就可以来执行下我们的流水线，看是否符合我们自身的要求，首先我们需要先创建关联的其他资源对象，比如 Workspace 对应的 PVC、还有 GitLab、Harbor 的认证信息：

# other.yaml apiVersion: v1 kind: Secret metadata:   name: gitlab-auth   annotations:     tekton.dev/git-0: http://git.k8s.local type: kubernetes.io/basic-auth stringData:   username: root   password: admin321  —  apiVersion: v1 kind: Secret metadata:   name: harbor-auth   annotations:     tekton.dev/docker-0: http://harbor.k8s.local type: kubernetes.io/basic-auth stringData:     username: admin     password: Harbor12345  — apiVersion: v1 kind: ServiceAccount metadata:   name: tekton-build-sa secrets:   – name: harbor-auth   – name: gitlab-auth  —  apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: tekton-clusterrole-binding roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: edit subjects: – kind: ServiceAccount   name: tekton-build-sa   namespace: default  — apiVersion: v1 kind: PersistentVolumeClaim metadata:   name: go-repo-pvc spec:   resources:     requests:       storage: 1Gi   volumeMode: Filesystem   storageClassName: nfs-storage  # 使用 StorageClass 自动生成 PV   accessModes:     – ReadWriteOnce

这些关联的资源对象创建完成后，还需要为上面的 ServiceAccount 绑定一个权限，因为在 Helm 容器中我们要去操作一些集群资源，必然需要先做权限声明，这里我们可以将 tekton-build-sa 绑定到 edit 这个 ClusterRole 上去。

我们接下来就可以创建一个 PipelineRun 资源对象来触发我们的流水线构建了：

# pipelinerun.yaml apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata:   name: pipelinerun spec:   serviceAccountName: tekton-build-sa   pipelineRef:     name: pipeline   workspaces:     – name: go-repo-pvc       persistentVolumeClaim:         claimName: go-repo-pvc   params:     – name: git_url       value: http://git.k8s.local/course/devops-demo.git     – name: image       value: “harbor.k8s.local/course/devops-demo:v0.1.0”     – name: charts_dir       value: “./helm”     – name: release_name       value: devops-demo     – name: release_namespace       value: “kube-ops”     – name: overwrite_values       value: “image.repository=harbor.k8s.local/course/devops-demo,image.tag=v0.1.0”     – name: values_file       value: “my-values.yaml”

直接创建上面的资源对象就可以执行我们的 Pipeline 流水线了:

$ kubectl apply -f pipelinerun.yaml $ tkn pr describe pipelinerun Name:              pipelinerun Namespace:         default Pipeline Ref:      pipeline Service Account:   tekton-build-sa Timeout:           1h0m0s Labels:  tekton.dev/pipeline=pipeline