Tekton 实战：K8s 原生 CI/CD 流水线

在云原生团队里，CI/CD 流水线是交付的主动脉。Tekton 是一套运行在 Kubernetes 原生 环境上的开源 CI/CD 框架，它用 Kubernetes 的自定义资源（CRD）把“构建、测试、部署”全部声明成 YAML，和集群共用一套调度与权限模型。相比把流水线跑在独立虚拟机上的传统方案，Tekton 让每一次构建都变成一个普通的 Pod，弹性伸缩、资源隔离、日志归集天然就绪。本文从概念到一条可运行的生产级流水线，带你把 Tekton 真正用起来。

它本质上替代了传统 Jenkins 里常驻的构建节点：不再需要为不同语言、不同工具链维护一堆固定 agent，而是“按需起 Pod、用完即焚”。这种模型让构建环境天然可复现，也让你能用 Kubernetes 的 ResourceQuota 对 CI 资源做精细管控，避免某条流水线把整台构建机拖垮。

一、为什么需要 Kubernetes 原生 CI/CD

传统 CI 工具通常维护一套独立节点池，和业务的 Kubernetes 集群是两套世界：凭据要同步两套、节点要单独扩容、构建产物要额外打通存储。当微服务数量上来后，这种割裂会带来三处痛点：构建排队、资源浪费、环境不一致。

Tekton 的思路是“把流水线本身也变成 Kubernetes 负载”。每个 Task 步骤跑在一个 Pod 的一个容器里，由 kube-scheduler 统一调度，天然复用了你已经熟悉的 Kubernetes 的 Pod 与命名空间。构建完即释放，没有常驻节点空转。

二、Tekton 核心概念

Tekton 由四个核心 CRD 组成，理解它们的关系就理解了 Tekton 的骨架。

另外还有 Workspace 承载代码仓库、镜像仓库等输入输出，以及 ClusterTask（集群级共享 Task），让团队资产在命名空间之间复用。

三、环境准备：在集群里装好 Tekton

只需几条 kubectl 命令即可部署核心组件。Tekton 会创建 tekton-pipelines 命名空间并注册 CRD。

# 安装 Pipelines 核心（含 Task/Run CRD）
kubectl apply --filename \
  https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

# 安装 CLI 工具 tkn（macOS）
brew install tektoncd-cli

# 确认控制器就绪
kubectl get pods -n tekton-pipelines

部署完成后，集群就具备了运行 Task 和 Pipeline 的能力。若还不熟悉 Kubernetes 的 Pod 与命名空间，建议先把它作为前置知识补齐；构建镜像通常借助 Docker 镜像构建上下文 与 Kaniko 这类无需 Docker daemon 的工具。

四、写一个 Task：构建并推送镜像

下面定义一个 build-and-push Task：从代码仓库拉取源码，用 Kaniko 在无需特权的情况下构建镜像并推送到镜像仓库。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-and-push
spec:
  params:
    - name: image
      type: string
      description: 目标镜像地址
  workspaces:
    - name: source
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      args:
        - "--context=$(workspaces.source)"
        - "--destination=$(params.image)"
        - "--cache=true"

Workspace 把代码仓库挂进步骤容器，params 让 Task 可被不同镜像复用。注意 Kaniko 用 --cache 复用层缓存，能显著缩短二次构建时间。

五、用 Pipeline 串联多步骤

单个 Task 只做一件事，真正的价值在 Pipeline 把“克隆代码 → 构建镜像 → 更新部署”编排成图。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: ci-cd-pipeline
spec:
  workspaces:
    - name: shared
  params:
    - name: repo-url
    - name: image
  tasks:
    - name: clone
      taskRef:
        name: git-clone   # 社区 Catalog 提供的标准 Task
      params:
        - name: url
          value: $(params.repo-url)
      workspaces:
        - name: output
          workspace: shared
    - name: build
      runAfter: [clone]
      taskRef:
        name: build-and-push
      params:
        - name: image
          value: $(params.image)
      workspaces:
        - name: source
          workspace: shared

runAfter 声明了任务依赖，Tekton 据此生成有向无环图并并行可并行的步骤。社区维护的 Tekton Catalog 提供了 git-clone、buildah、kubeconfig 等大量现成 Task，避免重复造轮子。

六、用 PipelineRun 触发运行

Pipeline 只是蓝图，真正执行要提交一个 PipelineRun，并绑定 Workspace 的存储（通常用 PVC）。

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: ci-cd-run-001
spec:
  pipelineRef:
    name: ci-cd-pipeline
  workspaces:
    - name: shared
      persistentVolumeClaim:
        claimName: workspace-pvc
  params:
    - name: repo-url
      value: https://github.com/your-org/your-app
    - name: image
      value: registry.example.com/your-app:latest

提交后用 tkn 观察进度：

tkn pipelinerun logs ci-cd-run-001 -f
# 精细排查某一步失败
kubectl get taskrun

每次运行都会产生独立的 Pod 与日志，失败时可直接定位到具体步骤。

七、Tekton 与 GitHub Actions、ArgoCD 怎么分工

三者常被拿来比较，其实定位不同，可以组合使用。

典型组合是：用 GitHub Actions 或 Tekton 做构建与测试，产物推送镜像仓库，再由 ArgoCD 以 GitOps 方式把新版本同步到集群。Tekton 擅长“在集群内把代码变成镜像”，ArgoCD 擅长“把镜像按声明同步到环境”，二者一个管构建、一个管部署，边界清晰。

八、生产落地检查清单

九、常见问题排查

• Pod 一直 Pending：多半是节点资源不足或 PVC 未绑定，用 kubectl describe pod <taskrun-pod> 看 Events。

• 步骤报无权推送镜像：检查绑定的 serviceAccount 是否挂了含 registry 凭据的 Secret。

• 缓存不生效：确认 Kaniko 的 --cache-repo 指向一个可写的镜像仓库缓存层。

• 步骤镜像拉取失败（ImagePullBackOff）：检查该步骤镜像是否在集群可访问的仓库，私有仓库需在 namespace 建 imagePullSecret 并绑定到 serviceAccount。

• PVC 空间不足：构建产生大量中间层时会写满 Workspace 卷，给 PVC 设合理的 storage 上限与回收策略，必要时在 Task 末尾加一步清理。

十、事件驱动：用 Tekton Triggers 接 Git Webhook

前面都是手动提交 PipelineRun，生产环境更常见的是“push 即构建”。Tekton Triggers 提供 EventListener、TriggerBinding、TriggerTemplate 三件套，把外部 Webhook 事件翻译成一次 PipelineRun。

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: git-listener
spec:
  serviceType: ClusterIP
  triggers:
    - bindings:
        - ref: push-binding
      template:
        ref: run-template
---
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: push-binding
spec:
  params:
    - name: gitref
      value: $(body.ref)
---
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: run-template
spec:
  params:
    - name: gitref
  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: ci-cd-run-
      spec:
        pipelineRef:
          name: ci-cd-pipeline

Git 平台把 push 事件打到 EventListener 的路由，TriggerBinding 抽取分支名等字段，TriggerTemplate 据此渲染出带 generateName 的 PipelineRun，实现完全事件驱动的交付。配合 Ingress 或 Nginx 反向代理暴露 EventListener 服务，再配一个带密钥校验的 Webhook，就能安全接入代码平台。

结语

Tekton 把 CI/CD 流水线变成了 Kubernetes 的一等公民：用声明式 YAML 描述一切，用集群调度承载弹性，用 CRD 复用团队资产。当你把“构建、测试、部署”都收敛到同一套调度与权限模型里，交付链路的可观测性与一致性都会上一个台阶。下一步，可以把本文的 Pipeline 接到 Git Webhook，或进一步与 ArgoCD 的 GitOps 部署 串成完整的持续交付闭环。