目录
通过这份通俗易懂的 Tekton 教程，你将学会如何在 Kubernetes 上构建第一条 CI/CD 流水线。本指南涵盖核心概念、组件构成、目录结构、动手实操、调试方法与最佳实践。如果你想从零读懂 Tekton 并亲手把它跑起来，这份指南就是为你准备的。
先决条件
要开始使用 Tekton，你需要具备以下条件：
- 一个正在运行的 Kubernetes 集群（建议 1.28 及以上版本）
- 已安装并配置好 kubectl，能够连接集群
- 具备集群管理员权限（或至少能创建 CRD、RBAC 资源）
- 一个可用的容器镜像仓库（Docker Hub、Harbor、ACR 等）
- 具备 Kubernetes 和 YAML 的基础知识
以下为可选，但强烈建议：
- Tekton CLI（tkn）
- Tekton Dashboard（Web UI）
什么是 Tekton？
为了便于解释，我们沿用 CI/CD 里最常见的场景。
假设你的项目有 Dev、QA、Staging、Prod 四套环境。每次代码提交，你都要重复同样的动作：拉取代码、运行测试、构建镜像、推送仓库、更新部署。这些步骤在每次提交后基本不变。
如果全靠手工执行，容易出错；如果写一套自定义 shell 或 Python 脚本去串联，又难以维护和扩展——换一种语言、换一套环境，脚本就得重写。这正是 Tekton 要解决的问题。
Tekton 是一个 Kubernetes 原生的开源 CI/CD 框架。它把 CI/CD 的每一个环节都抽象成 Kubernetes 自定义资源（CRD）：一次"拉取代码"是一个 Task，一条完整的"构建到部署"流程是一个 Pipeline。你用 YAML 声明"要做什么"，Tekton 负责在集群里把它跑起来。
它和传统工具最大的不同在于三点：
- Kubernetes 原生：不是"支持" Kubernetes，而是只能运行在 Kubernetes 上，所有工作负载都以 Pod 形式执行，深度复用 K8s 的调度、存储、RBAC 与可观测能力。
- 声明式 + 容器化：流水线用 YAML 描述，每个步骤运行在独立的容器里，环境干净、可复现、可版本化。
- 可组合、可复用：Task 像积木一样可拼装、可共享，官方与社区维护了大量现成任务。
Tekton 是 CNCF 的孵化级（Incubating）项目，最初源自 Knative 的 build-pipeline 子项目，如今是云原生领域主流的 CI/CD 引擎之一，Jenkins X 也默认用它作为 CI 引擎。它的名字来自希腊语 τέκτων，意为"建造者"。
Tekton 与传统 CI/CD 工具的对比
| 维度 | Jenkins | GitLab CI | Tekton |
|---|---|---|---|
| 运行方式 | Master/Agent，常驻服务 | Runner | 完全 Kubernetes 原生，按需创建 Pod |
| 配置载体 | Jenkinsfile / Web UI | .gitlab-ci.yml | Kubernetes CRD（YAML） |
| 环境隔离 | 依赖 Agent 配置 | 依赖 Runner | 每个 Step 运行在独立容器 |
| 扩展方式 | 插件 | 内置能力 | 自定义 Task / Resolver |
| 可移植性 | 较低 | 绑定 GitLab | 跨云、跨平台、跨语言 |
Tekton 的核心概念
Tekton 的执行模型是层层嵌套的。先把下面这些术语对齐，后面的操作才不会跑偏。
Step、Task、Pipeline 三层结构
| 概念 | 类比 | 作用 |
|---|---|---|
| Step | 一条命令 | 最小执行单元，运行在独立容器里 |
| Task | 一道工序 | 一组有序 Step，运行在同一个 Pod 里 |
| Pipeline | 一条生产流水线 | 多个 Task 组成的 DAG，定义完整交付流程 |
定义与实例分离
| 概念 | 作用 | 类比传统 CI/CD |
|---|---|---|
| Task | 定义"做什么" | 构建步骤模板 |
| TaskRun | Task 的一次执行实例 | 一次构建执行 |
| Pipeline | 定义 Task 的顺序与依赖 | Jenkins Pipeline |
| PipelineRun | Pipeline 的一次执行实例 | 一次流水线执行 |
这里的关键在于：Task 和 Pipeline 只是静态定义，真正执行的是 TaskRun 与 PipelineRun。每执行一次就产生一条记录，携带完整的参数、状态与日志。
支撑概念
| 概念 | 作用 |
|---|---|
| Workspace | 在 Task 之间共享数据的存储卷（通常由 PVC 提供） |
| Params | 流水线参数，用于在不同环境中复用同一份定义 |
| Results | Task 的结构化输出，可传递给下游 Task（如镜像 digest） |
| Resolver | 从 Git、Bundle、Artifact Hub、集群等来源动态拉取 Task/Pipeline |
| Trigger | 基于事件（如 Git Push）自动实例化 PipelineRun |
一次执行的完整链路
Pipeline（定义）
│ 创建 PipelineRun
▼
PipelineRun（一次运行）
│ Tekton 为每个 Task 创建 TaskRun
▼
TaskRun（一个 Task 的一次运行）
│ 每个 TaskRun 启动一个 Pod
▼
Pod
└── Step 容器1 Step 容器2 ...（共享 Workspace）
有一句话值得记住：一个 TaskRun 对应一个 Pod，Task 里的每个 Step 对应 Pod 里的一个容器。理解这一点，后面排查问题会顺畅很多。
Tekton 的组件与生态
Tekton 不是一个单体工具，而是一组可以独立安装的项目：
| 组件 | 作用 |
|---|---|
| Tekton Pipelines | 核心引擎，定义 Task/Pipeline 等 CRD 与控制器 |
| Tekton Triggers | 事件驱动，根据 Git Push、PR 等事件触发流水线 |
| Tekton CLI（tkn） | 命令行工具，管理与查看流水线 |
| Tekton Dashboard | Web UI，可视化查看执行状态与日志 |
| Tekton Catalog | 官方/社区维护的可复用 Task、Pipeline 仓库 |
| Tekton Chains | 供应链安全，为构建产物生成、存储和签名来源信息（provenance） |
| Tekton Operator | 以 Operator 方式安装、升级、卸载 Tekton 组件 |
| Tekton Results | 执行结果的长期存储 |
| Pipelines as Code | 用仓库中的注释或文件直接驱动流水线，贴近 GitOps |
其中，Tekton Pipelines 是必装的核心，其余按需安装。
需要留意：Tekton 曾经的公共组件市场 Tekton Hub（hub.tekton.dev）已于 2026 年 1 月 8 日关停，其仓库随后归档。如今发现和复用社区任务，官方推荐改用 Artifact Hub 以及 Resolvers（git / bundles / cluster / hub）。这一点在"打包、复用与分发 Task"一节还会展开。
Tekton 的结构长什么样
Helm 用 Chart 目录来组织模板，Tekton 则用一组 YAML 清单来组织流水线。一条典型流水线的目录结构大致如下：
hello-tekton/
├── 00-namespace.yaml
├── 01-pvc.yaml # 工作区用的 PVC
├── 02-rbac.yaml # ServiceAccount、Role、RoleBinding
├── 03-secret.yaml # 镜像仓库凭据
├── task/
│ ├── git-clone.yaml # 拉取代码的 Task
│ ├── build-and-push.yaml # 构建并推送镜像的 Task
│ └── run-tests.yaml # 运行测试的 Task
├── pipeline/
│ └── build-and-push.yaml # 编排上述 Task 的 Pipeline
├── pipelinerun/
│ └── build-and-push-run.yaml # 一次具体执行
└── app/ # 被构建的示例应用
├── app.py
├── Dockerfile
└── k8s/
└── deployment.yaml
可以看到，和 Helm 用 values.yaml 区分环境类似，Tekton 通过**参数（Params）与工作区（Workspaces）**让同一份 Pipeline 定义服务于多个环境——你只需要在 PipelineRun 里传入不同的值。
安装 Tekton
Tekton 的安装非常直接，官方已经把所需清单都准备好了。
安装核心组件 Tekton Pipelines
# 安装最新版 Tekton Pipelines
kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml
# 如需安装指定版本（例如 v1.9.3 LTS），把 latest 换成 previous/<版本号>
kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.9.3/release.yaml
安装会创建 tekton-pipelines 命名空间，其中包含控制器与 Webhook 等核心组件。用下面的命令观察安装进度，等到所有 Pod 的 READY 都是 1/1 即可：
kubectl get pods --namespace tekton-pipelines --watch
安装 Triggers（可选，用于事件触发）
kubectl apply --filename https://infra.tekton.dev/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename https://infra.tekton.dev/tekton-releases/triggers/latest/interceptors.yaml
安装 Dashboard（可选，Web UI）
# 默认以只读模式安装
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
如果需要通过 Dashboard 直接创建、修改资源，改用 release-full.yaml（读写模式）。
安装 Tekton CLI（tkn）
# macOS
brew install tektoncd-cli
# Debian / Ubuntu
sudo apt update && sudo apt install -y tektoncd-cli
其他平台可以直接从 github.com/tektoncd/cli 的 Releases 页面下载对应二进制。安装完成后：
tkn version
版本选择提示
Tekton Pipelines 提供多条 LTS 分支。以当前周期为例，v1.9.x 属于 LTS（支持至 2027-01-30），而 v1.6.x、v1.3.x 等较老的 LTS 分支会先后到达 EOL。生产环境建议固定使用某条 LTS 分支，而不是盲目跟 latest。
Tekton 教程的 Github repo
本教程的示例清单建议你放在自己的 Git 仓库中管理（例如 hello-tekton）。除此之外，非常值得参考的官方资源有：
- Tekton 官方文档：https://tekton.dev/docs/
- Tekton 官方示例：github.com/tektoncd/pipeline 的 examples 目录
- 官方可复用任务：github.com/tektoncd-catalog 组织下的 git-clone、kaniko、golang、buildpacks 等
从头开始创建第一个 Task
Task 是 Tekton 里不可再分的最小工作单元。我们从最简单的 Task 开始。
最简单的 Task
创建 task/hello.yaml：
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: hello-tekton
spec:
params:
- name: who
type: string
default: "Tekton"
results:
- name: greeting
description: 生成的问候语
steps:
- name: say-hello
image: alpine:3.20
script: |
#!/bin/sh
set -e
echo "Hello, $(params.who)!"
printf "Hello, %s!" "$(params.who)" > $(results.greeting.path)
说明：
params：声明参数，default提供默认值，调用时用$(params.<name>)引用。results：声明结构化输出，脚本把结果写进$(results.<name>.path)指定的文件。steps：这里的每个 Step 都会运行在自己的容器（image）里。
应用它：
kubectl apply -f task/hello.yaml
kubectl get task
但请注意：只创建 Task 是没有用的。Task 只是一个静态定义，要得到结果，必须借助 TaskRun。
TaskRun：让 Task 跑起来
创建 taskrun/hello-run.yaml：
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
generateName: hello-tekton-run-
spec:
taskRef:
name: hello-tekton
params:
- name: who
value: "Tekton 初学者"
kubectl create -f taskrun/hello-run.yaml
小提示：这里用的是 metadata.generateName（自动生成带随机后缀的名字）而不是 metadata.name，因此必须用 kubectl create；只有带固定 metadata.name 的资源才能用 kubectl apply。
查看执行状态与日志：
tkn taskrun list
tkn taskrun logs --last -f
看到 Hello, Tekton 初学者! 就说明你的第一个 Task 跑通了。
参数、工作区与结果
- 参数（Params）：让同一个 Task 可以服务于不同环境。
- 工作区（Workspaces）：用于在 Task 之间共享数据（如源码、构建产物），底层通常是一个 PVC。
- 结果（Results）：让 Task 把结构化信息（如镜像 digest）传给下游。
这三者是写出可复用流水线的关键，下面会全部用到。
从头开始创建一条完整的 Pipeline
接下来构建一个真实场景：拉取代码 → 构建镜像 → 推送镜像仓库。
第一步：准备工作区（PVC）
多个 Task 之间要传递源码，需要一个共享存储。创建 01-pvc.yaml：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: tekton-source-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
kubectl apply -f 01-pvc.yaml
如果 Task 可能被调度到不同节点，建议把 accessModes 改为 ReadWriteMany，并使用支持它的 StorageClass。
第二步：拉取代码的 Task
创建 task/git-clone.yaml：
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: git-clone
spec:
params:
- name: repo-url
type: string
description: 需要克隆的 Git 仓库地址
- name: revision
type: string
default: main
workspaces:
- name: output
description: 克隆结果输出的工作区
steps:
- name: clone
image: alpine/git:latest
workingDir: $(workspaces.output.path)
script: |
#!/bin/sh
set -e
git clone $(params.repo-url) .
git checkout $(params.revision)
第三步：构建并推送镜像的 Task
这里以 Kaniko 为例——它无需 Docker 守护进程，可在容器内直接构建镜像，非常适合 Kubernetes 环境。
创建 task/build-and-push.yaml：
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: build-and-push
spec:
params:
- name: image
type: string
description: 目标镜像地址，例如 registry.example.com/hello-tekton:latest
workspaces:
- name: source
description: 包含 Dockerfile 的源码工作区
- name: dockerconfig
description: 镜像仓库凭据配置
optional: true
steps:
- name: build-and-push
image: gcr.io/kaniko-project/executor:v1.23.2-debug
env:
- name: DOCKER_CONFIG
value: $(workspaces.dockerconfig.path)
args:
- --dockerfile=$(workspaces.source.path)/Dockerfile
- --context=$(workspaces.source.path)
- --destination=$(params.image)
- --cache=true
关于凭据：dockerconfig 工作区绑定一个包含 config.json 的 Secret（即 docker login 后生成的凭据文件）。如果只是推送到内网公开仓库，也可以先省略它。
备注：Kaniko 的原始仓库已被 Google 归档，社区在
osscontainertools/kaniko继续维护；生产环境也可选用 Buildah、Cloud Native Buildpacks 等，官方 Catalog 均提供对应 Task。
第四步：用 Pipeline 编排 Task
创建 pipeline/build-and-push.yaml：
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: build-and-push-pipeline
spec:
params:
- name: repo-url
type: string
- name: revision
type: string
default: main
- name: image
type: string
workspaces:
- name: source
- name: dockerconfig
tasks:
- name: fetch-source
taskRef:
name: git-clone
workspaces:
- name: output
workspace: source
params:
- name: repo-url
value: $(params.repo-url)
- name: revision
value: $(params.revision)
- name: build-push
runAfter:
- fetch-source
taskRef:
name: build-and-push
workspaces:
- name: source
workspace: source
- name: dockerconfig
workspace: dockerconfig
params:
- name: image
value: $(params.image)
要点：
runAfter明确依赖关系，build-push 必须等 fetch-source 完成后才启动。- 如果不写
runAfter，多个 Task 默认会并行执行，这也正是 Tekton 支持 DAG 编排的体现。 $(params.xxx)在 Pipeline 层接收外部值，再转发给各个 Task，实现"一份定义、多环境复用"。
第五步：用 PipelineRun 执行
创建 pipelinerun/build-and-push-run.yaml：
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
generateName: build-and-push-run-
spec:
pipelineRef:
name: build-and-push-pipeline
params:
- name: repo-url
value: https://github.com/<your-org>/hello-tekton.git
- name: revision
value: main
- name: image
value: registry.example.com/hello-tekton:latest
workspaces:
- name: source
persistentVolumeClaim:
claimName: tekton-source-pvc
- name: dockerconfig
secret:
secretName: docker-config
至此，一条完整的 CI/CD 流水线定义就完成了。最终的文件结构如下：
hello-tekton/
├── 01-pvc.yaml
├── task/
│ ├── git-clone.yaml
│ └── build-and-push.yaml
├── pipeline/
│ └── build-and-push.yaml
└── pipelinerun/
└── build-and-push-run.yaml
验证 Tekton 资源
在真正执行前，先做静态校验，能省下大量排查时间。
用 dry-run 检查语法
kubectl apply -f pipeline/build-and-push.yaml --dry-run=server
--dry-run=server 会走一遍服务端校验，字段拼错、类型不对都会直接报错。
查看已创建的资源
kubectl get tasks
kubectl get pipelines
tkn pipeline describe build-and-push-pipeline
tkn pipeline describe 会列出 Pipeline 的参数、工作区以及各 Task 的依赖关系，是确认编排是否符合预期的好办法。
运行并查看结果
kubectl create -f pipelinerun/build-and-push-run.yaml
查看执行状态
# 列出所有流水线运行
tkn pipelinerun list
# 持续跟踪最近一次运行的日志
tkn pipelinerun logs --last -f
也可以直接用 kubectl 查看相关资源：
kubectl get pipelinerun
kubectl get taskrun
kubectl get pods
你会看到 Tekton 为每个 Task 启动了一个 Pod，Pod 里的多个容器对应 Task 的多个 Step。当镜像成功推送到仓库后，tkn pipelinerun list 中该运行的 SUCCEEDED 会显示为 True。
多环境复用
和 Helm 用不同 values.yaml 服务于多环境一样，Tekton 只需在 PipelineRun 里换一组参数即可：
# 生产环境：换成生产镜像地址与分支
kubectl create -f pipelinerun/build-and-push-run-prod.yaml
把它接入 CI/CD 流水线时，你可以写一段自定义逻辑，按环境传入不同的参数文件。
更新流水线与回滚部署
更新流水线定义
Pipeline、Task 都是 Kubernetes 资源，修改后重新 apply 即可：
# 修改 pipeline/build-and-push.yaml 后
kubectl apply -f pipeline/build-and-push.yaml
需要注意：被 PipelineRun 引用过的 Pipeline，其 spec 在多数情况下是不可变的。若要改变编排，通常的做法是新建版本（如 build-and-push-pipeline-v2），或直接新建一个 PipelineRun 使用新的定义。每一次 PipelineRun 都会保留完整的执行记录，这正是 Tekton 天然的"审计与追溯"能力。
回滚部署
Tekton 负责"构建与交付"，应用本身的回滚交给 Kubernetes 原生的 Deployment 机制：
# 查看历史版本
kubectl rollout history deployment/hello-tekton
# 回滚到上一个版本
kubectl rollout undo deployment/hello-tekton
# 回滚到指定版本
kubectl rollout undo deployment/hello-tekton --to-revision=2
如果你采用 GitOps（例如配合 Argo CD），回滚通常就是把 Git 里的清单改回上一个提交。
打包、复用与分发 Task
复用社区任务
正如前面提到的，Tekton Hub 公共实例已关停，如今复用社区任务主要靠 Resolvers。以下是通过 hub resolver 从 Artifact Hub 拉取任务的写法：
tasks:
- name: fetch-source
taskRef:
resolver: hub
params:
- name: type
value: artifact
- name: catalog
value: tekton-catalog-tasks
- name: kind
value: task
- name: name
value: git-clone
- name: version
value: "0.9"
也可以直接用 Git 作为来源（git resolver），或把任务打包成 OCI 镜像分发（bundles resolver）。这样做的好处是：Task 不被"写死"在集群里，而是按版本从可信来源动态解析，更利于统一治理与版本管理。
把 Task 打包成分发单元
# 将本地 Task 打包并推送到 OCI 仓库
tkn bundle push registry.example.com/tekton-tasks/git-clone:v0.1 -f task/git-clone.yaml
打包之后，别人就可以通过 bundles resolver 直接引用你发布的版本。
用 Triggers 实现自动触发
到这一步，流水线还需要手动创建 PipelineRun。Tekton Triggers 能让它被事件自动唤起。其核心对象如下：
| 对象 | 作用 |
|---|---|
| EventListener | 事件入口，通常通过 HTTP 暴露以接收 Webhook |
| TriggerBinding | 从事件负载中提取字段，存为参数 |
| TriggerTemplate | 用参数实例化资源（如 PipelineRun） |
| Trigger | 把 Binding 与 Template 组合起来，可附带 Interceptor |
| Interceptor | 在 Binding 之前做过滤、校验、转换 |
一个简化的 TriggerBinding 示例：
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
name: github-push-binding
spec:
params:
- name: git-revision
value: $(body.head_commit.id)
- name: git-repo-url
value: $(body.repository.clone_url)
在 GitHub 仓库的 Webhook 中填入 EventListener 暴露的地址，之后每次 push 都会自动实例化一个 PipelineRun——真正实现"代码提交即构建"。
调试 Tekton
Tekton 提供了丰富的调试手段，建议按下面的顺序排查：
tkn pipeline describe <name>：查看 Pipeline 的参数、工作区与依赖关系。tkn pipelinerun describe <name>：查看某次运行的状态与失败原因。tkn pipelinerun logs -f <name>：查看实时日志；--last表示最近一次。tkn taskrun logs -f <name>：单独查看某个 TaskRun 的日志。kubectl describe pod <pod>：当 TaskRun 一直 Pending 时，用它查看调度、拉镜像与存储挂载问题。kubectl get events --sort-by=.lastTimestamp：查看集群事件，定位 PVC、权限等异常。
常见的错误
1. TaskRun 一直处于 Pending
多半是调度或存储问题。检查节点资源、PVC 是否绑定成功、StorageClass 是否可用：
kubectl describe pod <pod-name>
kubectl get pvc
2. 工作区（Workspace）未绑定
如果 PipelineRun 没有为 Pipeline 声明的每个 workspace 绑定来源，运行会直接失败。请确认每个 workspace 都在 PipelineRun 中给出了 persistentVolumeClaim 或 secret。
3. 拉取镜像失败（ErrImagePull / ImagePullBackOff）
常见于集群访问不了镜像仓库（例如 gcr.io）。解决思路是把镜像同步到内网仓库，或改用可访问的镜像地址。官方示例中的镜像有时会带 mirror.gcr.io 等前缀，请按你所在网络环境替换。
4. 权限不足
Task 默认使用 default ServiceAccount。执行 kubectl 类操作、推送镜像等需要相应权限时，要创建专用的 ServiceAccount、Role 和 RoleBinding，并在 PipelineRun 里通过 taskRunTemplate.serviceAccountName 指定。
5. 用 kubectl apply 创建带 generateName 的资源报错
kubectl apply 需要固定的 metadata.name。如果资源用的是 generateName，请改用 kubectl create。
6. 修改后的 Pipeline 无法 apply
如前所述，被引用过的 Pipeline spec 可能不可变。请新建版本或新建 PipelineRun。
Tekton 最佳实践
- 用 Workspace 传递数据，不要让 Task 之间通过隐式的临时目录耦合。
- 凭据统一用 Secret 管理，并遵守最小权限原则，为流水线分配专用 ServiceAccount。
- 每个环境一个命名空间，配合 RBAC 隔离环境与权限。
- 固定引用版本：无论通过 resolver 还是 raw 链接引用 Task，都应锁定具体版本号，而不是使用 latest。
- 为 Step 声明资源限制与超时，避免个别任务拖垮集群。
- 生产环境选用 LTS 版本，并跟随安全更新（Tekton 历史上出现过多起 resolver 相关安全漏洞）。
- 给 Task 和 Pipeline 写清楚 description 与文档，可维护性远比想象中重要。
- 命名规范：资源名使用小写，单词间用连字符（-）分隔。
- YAML 中的字符串尽量加引号，尤其是版本号、布尔样式字符串。
Tekton 命令总结备忘
# ---------- 版本 ----------
tkn version # 查看 tkn 版本
# ---------- Pipeline ----------
tkn pipeline list # 列出 Pipeline
tkn pipeline describe <pipeline-name> # 查看 Pipeline 详情
tkn pipeline start <pipeline-name> # 交互式启动一个 Pipeline
tkn pipeline logs <pipeline-name> -f # 查看日志
# ---------- PipelineRun ----------
tkn pipelinerun list # 列出运行记录
tkn pipelinerun describe <run-name> # 查看某次运行详情
tkn pipelinerun logs --last -f # 跟踪最近一次运行的日志
tkn pipelinerun delete <run-name> # 删除某次运行
# ---------- Task ----------
tkn task list # 列出 Task
tkn task describe <task-name> # 查看 Task 详情
tkn task start <task-name> # 启动一个 Task
# ---------- TaskRun ----------
tkn taskrun list # 列出 TaskRun
tkn taskrun describe <run-name> # 查看 TaskRun 详情
tkn taskrun logs --last -f # 跟踪日志
# ---------- Bundle（打包分发） ----------
tkn bundle push <image> -f <task.yaml> # 把 Task 打包并推送为 OCI 镜像
# ---------- 原生 kubectl ----------
kubectl apply -f <file> # 创建/更新资源（需固定 name）
kubectl create -f <file> # 创建资源（支持 generateName）
kubectl get pipelinerun,taskrun,pods # 查看运行相关资源
kubectl rollout undo deployment/<name> # 回滚应用部署
总结
Tekton 是 Kubernetes 原生的 CI/CD 框架：它把流水线的每个环节都变成 Kubernetes 资源，用声明式 YAML 描述"要做什么"，用 Pod 容器执行"具体怎么做"。在这份 Tekton 教程中，我们梳理了核心概念（Step、Task、TaskRun、Pipeline、PipelineRun、Workspace、Results），认识了组件生态，并从零创建、验证、运行了一条完整的流水线，还涉及了更新回滚、任务复用、事件触发、调试与最佳实践。
如果说 Helm 解决的是"如何把应用打包并部署到 Kubernetes"，那么 Tekton 解决的就是"如何把构建、测试、部署这一整套流程，变成 Kubernetes 里一等公民的自动化流水线"。两者结合，正好覆盖云原生交付的完整链路。
延伸阅读
- Tekton 官方文档：https://tekton.dev/docs/
- Tekton 代码仓库：https://github.com/tektoncd
- 官方可复用任务：https://github.com/tektoncd-catalog
- Artifact Hub（发现 Tekton 资源）：https://artifacthub.io/
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qq_41035650/article/details/167277068
