Tekton 面试题
36 道题- 分类
- DevOps
- 题目数
- 36 道
1 Tekton 的核心架构组件
答案:
Tekton 以 Kubernetes CRD 为核心,由以下组件构成:
- Tekton Pipelines:提供 Task、Pipeline、TaskRun、PipelineRun 等核心 CRD,定义 CI/CD 流水线的编排能力。
- Tekton Triggers:提供 EventListener、Trigger、TriggerTemplate、TriggerBinding 等 CRD,实现外部事件驱动的流水线触发。
- Tekton Chains:提供 SignedTaskRun、SignedPipelineRun 等 CRD,实现构建产物和流水线的签名与 attestation。
- Tekton Dashboard:提供 Web UI,支持流水线的可视化查看与操作。
- Tekton Hub / Catalog:提供社区维护的可复用 Task 和 Pipeline 集合。
- Tekton Operator:管理 Tekton 组件在 Kubernetes 集群上的安装、升级与生命周期。
| 组件 | 核心 CRD | 职责 |
|---|---|---|
| Pipelines | Task, Pipeline, TaskRun, PipelineRun | 流水线编排与执行 |
| Triggers | EventListener, Trigger, TriggerTemplate, TriggerBinding | 事件驱动触发 |
| Chains | SignedTaskRun, SignedPipelineRun | 签名与 attestation |
| Dashboard | — | Web 管理界面 |
| Operator | TektonConfig, TektonPipeline, TektonTrigger | 组件生命周期管理 |
2 Task 和 TaskRun 的关系
答案:
Task 定义一组有序执行的 Step 容器,TaskRun 是 Task 的一次具体执行实例。
- Task:声明式定义模板,包含 Steps、Params、Results、Workspaces、Sidecars 等字段,描述"做什么"。
- TaskRun:引用 Task 并注入运行时参数,记录执行状态和日志,对应一个 Kubernetes Pod。
- 生命周期:TaskRun 创建后自动调度到集群,Step 容器依次执行,执行完成后 Pod 保留一段可配置时间用于日志查看。
- 复用性:多个 TaskRun 可引用同一个 Task,仅注入不同的参数和 Workspace。
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: build-image
spec:
params:
- name: IMAGE
type: string
steps:
- name: build
image: docker
script: |
docker build -t $(params.IMAGE) .
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: build-image-run
spec:
taskRef:
name: build-image
params:
- name: IMAGE
value: registry.example.com/app:v1
3 Pipeline 和 PipelineRun 的关系
答案:
Pipeline 编排多个 Task 为有向无环图,PipelineRun 是 Pipeline 的一次具体执行实例。
- Pipeline:定义 Task 执行顺序、依赖关系、参数传递和 Workspace 映射,支持并行和串行阶段。
- PipelineRun:引用 Pipeline 并注入运行时参数,自动为每个 Task 创建对应的 TaskRun,管理整体执行状态。
- DAG 调度:PipelineRun 根据 Pipeline 中定义的
runAfter或from字段自动解析依赖图,并行执行无依赖的 Task。 - 状态传播:任一 Task 失败,PipelineRun 整体标记为失败,下游 Task 根据
When条件或默认策略决定是否执行。
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: ci-pipeline
spec:
workspaces:
- name: shared-workspace
tasks:
- name: clone
taskRef:
name: git-clone
workspaces:
- name: output
workspace: shared-workspace
- name: test
taskRef:
name: unit-test
runAfter:
- clone
workspaces:
- name: source
workspace: shared-workspace
- name: build
taskRef:
name: build-image
runAfter:
- test
workspaces:
- name: source
workspace: shared-workspace
4 Params 的参数类型与传递方式
答案:
Tekton 支持三种参数类型,通过替换机制注入到 Step 容器中。
| 类型 | 说明 | 示例值 |
|---|---|---|
string | 字符串值,支持默认值 | "v1.0.0" |
array | 字符串数组,多值场景 | ["build", "test"] |
object | 键值对对象 | {key: "version", value: "1.0"} |
传递方式:
- Task 级别:
$(params.PARAM_NAME)或$(params.PARAM_NAME[*])引用。 - Pipeline 级别:Task 通过
params字段引用 Pipeline 参数或硬编码值。 - 参数作用域:Pipeline 参数向下游 Task 传递需要在 Task 中显式声明同名参数。
- 默认值:Param 定义时可设置
default,未传入值时使用默认值。
参数约束:
string类型参数通过变量替换注入到 Step 的args、command、script中。array类型参数通过$(params.ARRAY_PARAM[*])展开为多个命令行参数。object类型参数支持通过$(params.OBJECT_PARAM.key)访问特定字段。
5 Results 的使用场景与传递机制
答案:
Results 允许 Task 将执行结果输出,供下游 Task 或 PipelineRun 使用。
- 定义位置:Task 的
results字段声明输出结果的名称和类型(string/array/object)。 - 写入方式:Step 容器将结果写入指定路径
/tekton/results/RESULT_NAME,支持文件写入或echo输出。 - 读取方式:下游 Task 通过
$(tasks.TASK_NAME.results.RESULT_NAME)引用上游结果。 - 结果大小限制:默认单个 Result 不超过 4096 字节,可通过
results-from环境变量调整。
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: get-commit
spec:
results:
- name: commit-sha
type: string
- name: branch
type: string
steps:
- name: get-sha
image: alpine
script: |
sha=$(git rev-parse HEAD)
echo -n "$sha" > /tekton/results/commit-sha
echo -n "main" > /tekton/results/branch
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: build-image
spec:
params:
- name: COMMIT_SHA
type: string
steps:
- name: build
image: docker
script: |
docker build -t app:$(params.COMMIT_SHA) .
# Pipeline 中传递 Result
spec:
tasks:
- name: get-commit
taskRef:
name: get-commit
- name: build-image
taskRef:
name: build-image
params:
- name: COMMIT_SHA
value: $(tasks.get-commit.results.commit-sha)
runAfter:
- get-commit
6 Workspace 的类型与选择策略
答案:
Workspace 是 Tekton 中 Task 共享数据和挂载外部存储的统一抽象,支持以下类型:
| 类型 | 适用场景 | 注意事项 |
|---|---|---|
PersistentVolumeClaim | 生产级持久化存储,多 Task 共享代码和数据 | 需提前创建 PVC 或通过 volumeClaimTemplate 动态创建 |
EmptyDir | 临时数据,生命周期与 TaskRun 一致 | Pod 删除后数据丢失 |
ConfigMap | 只读配置文件注入 | 不支持写入操作 |
Secret | 敏感信息注入,如 SSH 密钥、凭证 | 自动挂载为只读 |
CSI | 使用 CSI 驱动提供的存储 | 需集群支持 CSI |
Projected | 合并多个 Secret/ConfigMap/ServiceAccount | 复杂组合场景 |
选择策略:
- 多 Task 共享工作区使用 PVC。
- 临时数据交换使用 EmptyDir。
- 配置文件使用 ConfigMap。
- 凭据使用 Secret。
- 动态 PVC 通过
volumeClaimTemplate声明 PVC 规格,PipelineRun 自动创建和回收。
workspaces:
- name: source
persistentvolumeclaim:
claimName: workspace-pvc
- name: temp
emptyDir: {}
- name: configs
configmap:
name: build-config
- name: ssh-keys
secret:
secretName: git-ssh-key
7 Step 和 Sidecar 容器的区别与协作
答案:
Step 执行流水线业务逻辑,Sidecar 提供辅助服务。两者运行在同一 Pod 内,共享网络和卷。
| 维度 | Step | Sidecar |
|---|---|---|
| 角色 | 执行业务逻辑的主容器 | 提供辅助服务的辅助容器 |
| 生命周期 | 顺序执行,前一个完成才启动后一个 | 在 TaskRun 整个生命周期内运行 |
| 重启策略 | 失败后可配置重试(retries) | 始终运行,失败时自动重启 |
| 资源设置 | 每个 Step 独立设置 requests/limits | 在 Sidecar 中统一设置 |
| 退出影响 | Step 失败导致 TaskRun 失败 | Sidecar 退出不影响 TaskRun,除非设置为关键(critical) |
协作方式:
- 共享卷:Step 写入数据,Sidecar 读取并提供服务(如 Sidecar 运行 docker daemon,Step 调用 docker build)。
- 网络通信:Sidecar 监听本地端口,Step 通过 localhost 访问。
- 优雅退出:Step 执行完成后,Sidecar 收到 SIGTERM 信号,可执行清理逻辑。
spec:
steps:
- name: docker-build
image: docker
script: |
docker build -t app:latest .
volumeMounts:
- name: docker-socket
mountPath: /var/run/docker.sock
sidecars:
- name: daemon
image: docker:dind
securityContext:
privileged: true
volumeMounts:
- name: docker-socket
mountPath: /var/run/docker.sock
8 When 条件表达式的执行规则
答案:
When 表达式控制 Task 是否执行,支持多条件组合评估。
- 评估时机:TaskRun 创建前评估,所有 When 条件通过后才创建 TaskRun。
- 表达式结构:
input、operator、values三个字段。 - 支持运算符:
| 运算符 | 语义 | 示例 |
|---|---|---|
== | 精确匹配,input 等于任一 values | input: "main", operator: "==", values: ["main", "release"] |
!= | 排除匹配,input 不等于任一 values | input: "hotfix", operator: "!=", values: ["main", "release"] |
in | 集合包含 | input: "v1.0", operator: "in", values: ["v1.0", "v1.1"] |
notin | 集合排除 | input: "v2.0", operator: "notin", values: ["v1.x", "v2.x"] |
组合规则:
- 所有 When 条件之间为逻辑 AND 关系,任一条件不通过则 Task 跳过。
- 全局忽略失败通过
onError: continue实现,此时 When 仍会评估。 - 跳过状态在 PipelineRun 中显示为
Skipped,不影响 PipelineRun 成功状态。
tasks:
- name: deploy-prod
taskRef:
name: deploy
when:
- input: "$(params.branch)"
operator: "=="
values: ["main"]
- input: "$(params.env)"
operator: "in"
values: ["prod", "staging"]
params:
- name: target
value: "$(params.env)"
9 Matrix 矩阵执行的配置与使用
答案:
Matrix 支持在单个 Task 中批量执行多组参数组合,自动并行创建多个 TaskRun。
- 基本矩阵:单个参数取多个值,每个值对应一个 TaskRun。
- 组合矩阵:多个参数形成笛卡尔积,每种组合对应一个 TaskRun。
- 并行控制:通过
maxConcurrency限制同时运行的 TaskRun 数量。 - 纳入参数:通过
include字段添加额外任务。
# 基本矩阵:三个版本各执行一次
tasks:
- name: build-all
taskRef:
name: build
matrix:
params:
- name: VERSION
value:
- "1.0"
- "1.1"
- "2.0"
maxConcurrency: 2
# 组合矩阵:平台 x 架构,共 4 个 TaskRun
tasks:
- name: build-cross
taskRef:
name: build
matrix:
params:
- name: PLATFORM
value:
- "linux"
- "windows"
- name: ARCH
value:
- "amd64"
- "arm64"
# 纳入参数:为特定组合设置额外参数
tasks:
- name: build-with-extra
taskRef:
name: build
matrix:
params:
- name: VERSION
value:
- "1.0"
- "1.1"
include:
- name: extra-build
params:
- name: VERSION
value: "2.0-rc"
- name: EXTRA_FLAG
value: "--enable-experimental"
适用场景:
- 多版本并行构建。
- 多平台交叉编译。
- 多环境并行部署。
- 参数化批量测试。
10 自定义 Task 的创建方式
答案:
将存量构建任务转换为 Tekton Task 主要有三种方式。
| 方式 | 适用场景 | 示例 |
|---|---|---|
| 内嵌脚本 | Shell 脚本可直接在 Step 中执行 | 将 Jenkins 构建脚本直接写入 script 字段 |
| 容器镜像封装 | 业务逻辑封装为自定义镜像 | 将 Python/Node 构建脚本打包为自定义 Step 镜像 |
| Bundles 引用 | Task 打包为 OCI 镜像,跨集群分享 | taskRef.bundle 引用 OCI 镜像仓库 |
内嵌脚本示例:
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: maven-build
spec:
params:
- name: MODULE
type: string
default: ""
workspaces:
- name: source
steps:
- name: compile
image: maven:3.8-openjdk-11
workingDir: $(workspaces.source.path)
script: |
if [ -n "$(params.MODULE)" ]; then
mvn compile -pl $(params.MODULE) -am
else
mvn compile
fi
- name: test
image: maven:3.8-openjdk-11
workingDir: $(workspaces.source.path)
script: |
mvn test
将 Docker Compose 转为 Tekton:
- 每个 service 对应一个独立 Task。
- Compose volumes 映射为 Workspace。
- Compose environment 映射为 Params。
- depends_on 映射为
runAfter。
11 Tekton Triggers 的架构与工作流程
答案:
Tekton Triggers 通过事件驱动方式自动创建 PipelineRun,核心组件如下:
| 组件 | CRD | 职责 |
|---|---|---|
| EventListener | EventListener | 暴露 Kubernetes Service 端点,接收外部事件 |
| Trigger | Trigger | 绑定事件源到 TriggerTemplate |
| TriggerTemplate | TriggerTemplate | 定义创建 PipelineRun 的模板 |
| TriggerBinding | TriggerBinding | 从事件负载中提取参数并绑定到模板 |
| ClusterTriggerBinding | ClusterTriggerBinding | 集群级别的 TriggerBinding |
| Interceptor | Interceptor | 事件过滤、验证和转换 |
工作流程:
- 外部系统(GitHub、GitLab、Jenkins)向 EventListener Service 发送 HTTP 请求。
- EventListener 将请求传递给 Interceptor 链进行过滤和验证。
- 验证通过后,Trigger 匹配并激活 TriggerTemplate。
- TriggerTemplate 结合 TriggerBinding 提取的参数,创建 PipelineRun 或其他资源。
- PipelineRun 开始执行对应 Pipeline。
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
name: github-listener
spec:
triggers:
- name: pr-trigger
interceptors:
- ref:
name: cel
params:
- name: filter
value: >-
header.match('X-GitHub-Event', 'pull_request') &&
body.action == 'opened'
bindings:
- ref: github-pr-binding
template:
ref: pr-template
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
name: pr-template
spec:
params:
- name: git-revision
- name: git-repo-url
resourcetemplates:
- apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
generateName: pr-run-
spec:
pipelineRef:
name: ci-pipeline
params:
- name: REVISION
value: $(tt.params.git-revision)
- name: REPO_URL
value: $(tt.params.git-repo-url)
12 Interceptor 的类型与配置
答案:
Interceptor 在事件进入 Trigger 之前执行过滤、验证和负载处理,支持三种类型。
| 类型 | 功能 | 配置方式 |
|---|---|---|
| CEL Interceptor | 使用 CEL 表达式过滤和提取事件负载 | filter、overlays 字段 |
| GitHub Interceptor | 验证 GitHub Webhook 签名、处理 PR/Issue 事件 | secretRef、eventTypes |
| GitLab Interceptor | 验证 GitLab Webhook 签名、处理 Merge Request | secretRef、eventTypes |
| Bitbucket Interceptor | 验证 Bitbucket Webhook | secretRef、eventTypes |
CEL Interceptor 示例:
interceptors:
- name: validate-and-extract
ref:
name: cel
params:
- name: filter
value: >-
body.ref.startsWith('refs/heads/') &&
body.commits.size() > 0
- name: overlays
value:
- key: branch
expression: "body.ref.split('/')[2]"
- key: commit_sha
expression: "body.head_commit.id"
GitHub Interceptor 签名验证:
interceptors:
- ref:
name: github
params:
- name: secretRef
value:
secretName: github-webhook-secret
secretKey: webhook-secret
- name: eventTypes
value:
- pull_request
- push
13 Tekton Chains 的签名与 Attestation 机制
答案:
Tekton Chains 为构建流水线和产物提供加密签名和可验证的 attestation,满足软件供应链安全要求。
- 签名对象:TaskRun 和 PipelineRun 的执行结果和工作负载。
- Attestation 格式:符合 in-toto 标准,包含构建元数据、材料清单和运行环境信息。
- 存储后端:支持 OCI 镜像仓库(通过
cosign存储签名)和 Kubernetes Secret。 - 签名密钥:支持 x509 证书和密钥对、KMS(Google Cloud KMS、AWS KMS、Azure Key Vault)、Hashicorp Vault。
apiVersion: chains.tekton.dev/v1alpha1
kind: ChainsConfig
metadata:
name: chains-config
spec:
artifacts.taskrun.format: in-toto
artifacts.taskrun.storage: oci
artifacts.pipelinerun.format: in-toto
artifacts.pipelinerun.storage: oci
transparency.enabled: "true"
验证流程:
- PipelineRun/TaskRun 执行完成后,Chains 计算其 digest。
- Chains 使用配置的签名密钥对 digest 签名。
- 签名和 attestation 存储到 OCI 仓库或 Secret 中。
- 消费者通过
cosign verify-attestation验证流水线来源的完整性。
14 Tekton Hub 与社区 Catalog 的使用
答案:
Tekton Hub 提供集中式 Task 和 Pipeline 发现平台,Catalog 是社区维护的可复用资源仓库。
| 概念 | 说明 | URL |
|---|---|---|
| Tekton Hub | Web 门户,浏览、搜索和安装 Tasks/Pipelines | hub.tekton.dev |
| Tekton Catalog | GitHub 仓库,社区贡献的任务和流水线集合 | github.com/tektoncd/catalog |
| CLI 工具 | tkn hub 命令行,从终端安装和搜索 | tkn hub install task git-clone |
| OCI Bundle | 将 Task 和 Pipeline 打包为 OCI 镜像 | taskRef.bundle 引用 |
常用社区 Task:
| Task | 功能 |
|---|---|
git-clone | 克隆 Git 仓库 |
buildah | 使用 Buildah 构建 OCI 镜像 |
kaniko | 使用 Kaniko 在非特权容器中构建镜像 |
skopeo-copy | 跨仓库复制镜像 |
helm-upgrade | 使用 Helm 升级部署 |
kubectl | 执行 Kubernetes 命令 |
gcs-upload | 上传文件到 GCS |
s3-upload | 上传文件到 S3 |
安装方式:
# 通过 tkn hub 安装
tkn hub install task git-clone
tkn hub install task buildah
# 通过 kubectl 从 Catalog 直接安装
kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.9/git-clone.yaml
15 Tekton Operator 的集群管理能力
答案:
Tekton Operator 管理 Tekton 组件在 Kubernetes 集群上的全生命周期,通过 TektonConfig CRD 统一配置。
管理的组件:
| 组件 | CRD | 是否可选 |
|---|---|---|
| Tekton Pipelines | TektonPipeline | 必选 |
| Tekton Triggers | TektonTrigger | 可选 |
| Tekton Chains | TektonChain | 可选 |
| Tekton Dashboard | TektonDashboard | 可选 |
| Tekton Hub | TektonHub | 可选 |
| Tekton Addons | TektonAddon | 可选 |
核心能力:
- 安装与升级:通过 TektonConfig 声明式管理各组件版本和配置。
- 配置管理:统一设置 Feature Flag、资源配额、日志级别、RBAC 规则。
- 节点选择:为 Tekton 组件 Pod 配置节点选择器和容忍度。
- 多集群支持:通过
TektonConfig和TektonPipeline等 CRD 在多个集群上部署。
apiVersion: tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
spec:
profile: all
targetNamespace: tekton-pipelines
pipeline:
running-in-environment-with-injected-sidecars: false
require-git-ssh-secret-known-hosts: false
trigger:
enable-api-fields: alpha
dashboard:
readonly: true
16 Tekton Dashboard 的功能与配置
答案:
Tekton Dashboard 提供 Web 界面,用于查看和管理 Tekton 资源。
核心功能:
- PipelineRun 的实时日志流查看。
- TaskRun、PipelineRun 的执行状态和详情。
- 手动触发 PipelineRun、TaskRun。
- 事件监听器状态查看。
- 导入和查看 YAML 定义的 Tekton 资源。
- 多命名空间切换,支持集群级别资源查看。
- OIDC、Bearer Token、Kubeconfig 等多种认证方式。
部署方式:
# 通过 Operator 部署
kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml
# 通过 TektonConfig 启用
spec:
dashboard:
readonly: true
ingress:
enabled: true
host: tekton.example.com
安全配置:
readonly: true限制 UI 编辑操作。- 集成 OIDC Provider 统一认证。
- 通过 Ingress/Route 暴露时配置 TLS 终结。
17 Pipeline 并发控制与执行队列
答案:
Tekton 通过以下机制控制流水线并发和执行顺序。
| 机制 | 实现方式 | 作用范围 |
|---|---|---|
PipelineRun 并发默认值 | Kubernetes API Server 无限制 | 全局 |
maxConcurrency | PipelineRun Spec 的 maxConcurrency 字段 | 每个 Pipeline 级别 |
taskRunSpecs | PipelineRun 的 taskRunSpecs.maxConcurrency | Task 级别 |
| 资源配额(ResourceQuota) | Kubernetes 原生 ResourceQuota | 命名空间级别 |
| LimitRange | Kubernetes 原生 LimitRange | 命名空间级别 |
| 队列代理 | Tekton 社区方案 / 自建队列控制器 | 外部排队 |
PipelineRun 级别限流:
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: ci-run
spec:
maxConcurrency: 3
pipelineRef:
name: ci-pipeline
命名空间资源配额:
apiVersion: v1
kind: ResourceQuota
metadata:
name: tekton-quota
spec:
hard:
count/tekton.dev/v1.PipelineRun: "5"
requests.cpu: "10"
requests.memory: 20Gi
实践建议:
- PipelineRun 级别设置
maxConcurrency控制并行 Pipeline 数量。 - Task 级别
matrix.maxConcurrency控制矩阵任务并行度。 - 命名空间 ResourceQuota 限制总并发 Pod 数量。
- 外部队列代理处理 PipelineRun 创建请求的排队调度。
18 超时与重试机制
答案:
Tekton 支持 PipelineRun、TaskRun 和 Step 级别的超时与重试配置。
| 级别 | 配置字段 | 默认值 | 说明 |
|---|---|---|---|
| PipelineRun | timeout | 1 小时 | PipelineRun 整体超时 |
| PipelineRun Task | taskRunSpecs.timeout | 继承 PipelineRun | 单个 TaskRun 超时 |
| TaskRun | timeout | 1 小时 | TaskRun 整体超时 |
| Step | timeout | 无限制 | 单个 Step 超时 |
| TaskRun | retries | 0 | TaskRun 失败后的重试次数 |
超时策略:
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: timeout-demo
spec:
timeout: 30m
pipelineSpec:
tasks:
- name: long-task
taskSpec:
steps:
- name: long-step
image: alpine
script: |
sleep 3600
timeout: 5m
retries: 2
重试行为:
retries: N表示最多执行 N+1 次(初始执行 + N 次重试)。- 重试之间无间隔,失败后立即重试。
- 重试创建的 TaskRun 与原始 TaskRun 命名规则一致,后缀递增。
- Pod 清理策略通过
taskRunSpecs.podTemplate控制。
超时终止流程:
- 超时时间到达后,Tekton 向 Pod 发送 SIGTERM 信号。
- 等待
terminationGracePeriodSeconds(默认 30s)。 - 超时后发送 SIGKILL 强制终止。
- TaskRun/PipelineRun 状态更新为
Failed,原因标记为ExceededTimeout。
19 资源配额与节点选择策略
答案:
Tekton 通过 PodTemplate 和 ResourceRequirements 精细控制流水线 Pod 的资源分配与调度。
| 配置项 | 字段 | 作用 |
|---|---|---|
| CPU/Memory 请求 | resources.requests | 容器调度时的资源保障 |
| CPU/Memory 限制 | resources.limits | 容器运行时的资源上限 |
| 节点选择器 | nodeSelector | 强制调度到指定标签节点 |
| 容忍度 | tolerations | 允许调度到有污点的节点 |
| 亲和性 | affinity | 节点亲和性与 Pod 亲和性策略 |
| Service Account | serviceAccountName | Pod 运行的 SA 权限 |
| 优先级类 | priorityClassName | Pod 调度优先级 |
| 安全上下文 | securityContext | Pod 和容器的安全配置 |
TaskRun 级别 PodTemplate 配置:
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: resource-demo
spec:
taskRef:
name: build-image
podTemplate:
nodeSelector:
disk-type: ssd
workload: ci
tolerations:
- key: ci-only
operator: Exists
effect: NoSchedule
priorityClassName: high-priority
securityContext:
runAsNonRoot: true
runAsUser: 1000
taskSpec:
steps:
- name: build
image: docker
resources:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "4"
memory: 8Gi
PipelineRun 级别统一 PodTemplate:
spec:
pipelineRef:
name: ci-pipeline
podTemplate:
serviceAccountName: tekton-builder
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: pool
operator: In
values:
- ci-pool
20 构建缓存优化策略
答案:
Tekton 支持多种缓存策略加速构建过程,减少重复下载和编译时间。
| 策略 | 实现方式 | 缓存后端 |
|---|---|---|
| Docker 镜像层缓存 | 使用 --cache-from 或 BuildKit | 镜像仓库 |
| 包管理缓存 | 持久化 Workspace 挂载 .m2、node_modules、pip cache | PVC |
| Blob 缓存 | 使用 gcs-upload/s3-upload 缓存中间产物 | GCS/S3/MinIO |
| Layer Caching | Kaniko/Buildah 的缓存机制 | 镜像仓库或本地 PVC |
| Buildx 缓存 | Docker Buildx --cache-to/--cache-from | 镜像仓库或 S3 |
Maven 依赖缓存示例:
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: maven-with-cache
spec:
workspaces:
- name: source
- name: maven-cache
steps:
- name: mvn-build
image: maven:3.8-openjdk-11
workingDir: $(workspaces.source.path)
script: |
mkdir -p $(workspaces.maven-cache.path)/.m2
ln -sf $(workspaces.maven-cache.path)/.m2 ~/.m2
mvn clean package -DskipTests
Kaniko 缓存配置:
spec:
steps:
- name: kaniko-build
image: gcr.io/kaniko-project/executor:latest
args:
- --context=$(workspaces.source.path)
- --dockerfile=$(workspaces.source.path)/Dockerfile
- --destination=registry.example.com/app:latest
- --cache=true
- --cache-repo=registry.example.com/cache
最佳实践:
- 使用 PVC 作为依赖缓存持久化存储。
- 为语言生态工具(Maven、npm、pip、Go module)分别建立独立缓存 Workspace。
- 镜像构建使用 Kaniko 或 Buildah 的仓库级缓存层。
- 清理策略通过
volumeClaimTemplate的storageClassName配置回收策略。 - Registry 级别配置镜像层缓存仓库,各构建共享基础层。
21 Git 资源与工作区初始化
答案:
Tekton 通过 git-clone Task 或 PipelineResource 实现 Git 仓库克隆,当前推荐使用社区 git-clone Task。
| 方式 | 状态 | 说明 |
|---|---|---|
git-clone 社区 Task | 推荐 | 功能完整,支持 submodules、深度、分支、SSH 和 HTTP 认证 |
PipelineResource Git 类型 | 废弃 | 功能有限,社区已迁移到 Workspace + git-clone Task |
git-clone Task 核心参数:
| 参数 | 默认值 | 说明 |
|---|---|---|
url | — | Git 仓库 URL |
revision | main | 分支、标签或 commit SHA |
depth | 0(完整克隆) | 浅克隆深度 |
submodules | true | 是否初始化子模块 |
sslVerify | true | 是否验证 SSL |
deleteExisting | true | 目标目录存在时是否删除 |
httpProxy | — | HTTP 代理地址 |
httpsProxy | — | HTTPS 代理地址 |
userHome | /home/git | Git 用户家目录 |
完整配置示例:
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: ci-pipeline
spec:
workspaces:
- name: shared-workspace
tasks:
- name: clone
taskRef:
name: git-clone
workspaces:
- name: output
workspace: shared-workspace
params:
- name: url
value: https://github.com/org/repo.git
- name: revision
value: "$(params.branch)"
- name: depth
value: "1"
- name: submodules
value: "false"
- name: sslVerify
value: "true"
SSH 认证配置:
- 创建包含 SSH 私钥的 Secret。
- Secret 通过 Workspace 注入 git-clone Task。
- Task 自动将 SSH 密钥放置在
~/.ssh/id_rsa。
apiVersion: v1
kind: Secret
metadata:
name: git-ssh-key
annotations:
tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
ssh-privatekey: |
-----BEGIN OPENSSH PRIVATE KEY-----
...
22 Tekton 与 ArgoCD 的集成模式
答案:
Tekton 负责构建和生成部署清单,ArgoCD 负责部署到目标集群,形成完整的 GitOps CI/CD 链路。
集成模式:
| 阶段 | Tekton | ArgoCD |
|---|---|---|
| 代码构建 | 从 Git 克隆代码、构建镜像、运行测试 | — |
| 清单生成 | 生成或更新 Kubernetes 部署清单,推送到 Git 仓库 | — |
| 部署触发 | 推送更新到 Git 仓库(GitOps 仓库) | 检测 Git 仓库变化 |
| 自动同步 | — | 同步应用到目标集群 |
| 健康检查 | — | 监控 Pod、Service 健康状态 |
| 回滚 | — | 通过 Git revert 触发回滚 |
实现方式:
# Pipeline 任务:生成部署清单并推送到 GitOps 仓库
tasks:
- name: update-manifest
taskRef:
name: git-cli
params:
- name: GIT_USER_NAME
value: tekton-bot
- name: GIT_USER_EMAIL
value: tekton@example.com
- name: GIT_SCRIPT
value: |
cd $(workspaces.source.path)/config
sed -i "s|image: .*|image: registry.example.com/app:$(params.TAG)|" deployment.yaml
git add deployment.yaml
git commit -m "Update image tag to $(params.TAG)"
git push origin main
workspaces:
- name: source
workspace: gitops-repo
ArgoCD 自动同步策略:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
spec:
source:
repoURL: https://github.com/org/gitops-repo
path: config
targetRevision: main
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
优势:
- 分离构建和部署职责,Pipeline 只做不可变产物。
- GitOps 仓库作为单一事实来源,所有变更可追溯。
- ArgoCD 提供自动同步和健康检查,减少手动干预。
- 回滚通过 Git revert 实现,与 CI/CD 工具无关。
23 调试方法与日志查看
答案:
Tekton 提供多种调试手段,覆盖运行前、运行时和运行后三个阶段。
| 调试方法 | 适用阶段 | 命令 / 方式 |
|---|---|---|
| 资源验证 | 运行前 | kubectl validate、tkn task describe |
| 一次运行 | 运行前 | tkn task start --dry-run 预览 Pod YAML |
| 实时日志 | 运行时 | tkn taskrun logs -f、tkn pipelinerun logs -f |
| Pod 状态 | 运行时 | kubectl describe pod <taskrun-pod> |
| 进入容器 | 运行时 | kubectl exec -it <pod> -c step-xxx -- sh |
| 运行后日志 | 运行后 | tkn taskrun logs --last、kubectl logs <pod> |
| 事件查看 | 运行后 | kubectl get events --field-selector involvedObject.name=<taskrun> |
常用调试命令:
# 预览 TaskRun 创建后的 Pod YAML
tkn taskrun start my-task --dry-run -o yaml > taskrun-preview.yaml
# 实时跟踪日志
tkn pipelinerun logs -f --last
# 查看指定 Task 的日志
tkn taskrun logs taskrun-name -s step-build
# 查看 Pod 状态和事件
kubectl describe pod $(tkn taskrun list -o name | head -1)
# 进入运行中的构建容器
kubectl exec -it $(kubectl get pod -l tekton.dev/taskRun=my-taskrun -o name) -c step-build -- sh
# 查看 PipelineRun 详情
tkn pipelinerun describe pipelinerun-name
# 列出所有 PipelineRun 及其状态
tkn pipelinerun list --all-namespaces
Pod 保存策略:
TaskRun.Spec.podTemplate.terminationGracePeriodSeconds控制 Pod 在 TaskRun 完成后保留时间。- 默认保留 30 秒,生产环境可延长到 10-30 分钟以便调试。
- 日志存储路径:
/tekton/logs/step-xxx.log(容器内)。
24 Step 执行顺序与容器生命周期
答案:
Task 中 Step 以串行顺序在同一个 Pod 中执行,每个 Step 对应一个 Init Container。
执行机制:
- Tekton 将每个 Step 定义为 Pod 的 Init Container。
- Init Container 按 Task Spec 中 Step 定义顺序依次执行。
- 前一个 Step 退出(exit 0)后下一个 Step 才启动。
- 任一 Step 退出码非零,TaskRun 立即标记为失败,剩余 Step 不执行。
Step 容器特性:
| 特性 | 说明 |
|---|---|
| 共享文件系统 | 所有 Step 共享 Pod 的文件系统 |
| 共享网络 | 所有 Step 通过 localhost 通信 |
| 共享卷 | Workspace 和临时卷对所有 Step 可见 |
| 独立镜像 | 每个 Step 可使用不同的容器镜像 |
| 独立资源 | 每个 Step 可设置独立的 CPU/Memory requests 和 limits |
| 独立命令 | 每个 Step 可设置独立的 command、args 和 script |
| 日志分离 | 每个 Step 的日志独立存储和查看 |
onError 处理:
steps:
- name: check
onError: continue # 即使失败也继续执行后续 Step
script: |
exit 1
- name: cleanup
script: |
echo "Cleanup runs regardless of previous step failure"
Step Exit Handler:
onError: continue:当前 Step 失败不阻塞后续 Step。onError: stopAndFail(默认):当前 Step 失败终止整个 TaskRun。- Step 退出码保留在 TaskRun status 中供调试。
- Sidecar 生命周期独立,Step 执行期间 Sidecar 持续运行。
25 镜像构建策略对比
答案:
Tekton 生态支持多种容器镜像构建工具,各有适用场景。
| 工具 | 特权模式 | 缓存支持 | 适用场景 |
|---|---|---|---|
| Kaniko | 不需要 | 仓库缓存、本地缓存 | 非特权容器、多阶段构建 |
| Buildah | 不需要 | 仓库缓存、本地缓存 | OCI 标准、支持更多构建指令 |
| Docker-in-Docker | 需要 | Docker layer caching | 兼容 Dockerfile 全部特性 |
| BuildKit | 不需要 | 分布式缓存 | 并行构建、多平台 |
| img | 不需要 | 无 | 轻量级、快速启动 |
Kaniko 示例(推荐):
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: kaniko-build
spec:
params:
- name: IMAGE
type: string
- name: CONTEXT
type: string
default: .
workspaces:
- name: source
results:
- name: image-digest
type: string
steps:
- name: build-and-push
image: gcr.io/kaniko-project/executor:v1.9.0
args:
- --context=$(workspaces.source.path)/$(params.CONTEXT)
- --dockerfile=$(workspaces.source.path)/$(params.CONTEXT)/Dockerfile
- --destination=$(params.IMAGE)
- --cache=true
- --cache-repo=$(params.IMAGE)-cache
- --skip-tls-verify=false
- --verbosity=info
env:
- name: DOCKER_CONFIG
value: /tekton/home/.docker
选择依据:
- 集群安全策略禁止特权容器时使用 Kaniko 或 Buildah。
- 需要完整 Docker Buildx 特性时使用 DinD。
- 多平台交叉编译场景使用 BuildKit。
- 已有 Dockerfile 不做修改的场景使用 Kaniko。
26 Custom Task 与 Pipeline Task 的区别
答案:
Custom Task 允许扩展 Tekton 的 Task 体系,支持以 CRD 方式定义新的任务类型。
| 维度 | Pipeline Task | Custom Task |
|---|---|---|
| 实现方式 | 通过 Step 容器执行脚本 | 通过自定义控制器(Controller)处理 |
| 运行时 | 基于 Kubernetes Pod | 基于自定义控制器的 Reconcile 逻辑 |
| 状态管理 | Tekton 自动管理 | 自定义 Controller 报告 |
| 灵活性 | 限于容器内脚本执行 | 可调用外部 API、数据库、消息队列 |
| 复杂度 | 低,YAML 定义即可 | 高,需开发 Controller 和 CRD |
| 典型场景 | 构建、测试、部署 | Approval Gate、外部系统集成 |
CustomRun 资源:
CustomRun是 Custom Task 的执行实例,类似 TaskRun 与 Task 的关系。- Custom Task 通过 CRD 定义,控制器实现 Reconcile 逻辑。
- 状态通过 CustomRun 的
Status字段报告。
示例:Approval Gate Custom Task:
apiVersion: tekton.dev/v1
kind: PipelineRun
spec:
pipelineSpec:
tasks:
- name: approval
taskRef:
apiVersion: approval.example.com/v1
kind: ApprovalTask
name: manual-approve
params:
- name: approver
value: team-lead
- name: deploy
taskRef:
name: deploy-app
runAfter:
- approval
27 私有镜像仓库认证方案
答案:
Tekton 通过 Docker Config Secret 和 Image Pull Secret 实现私有仓库认证。
| 场景 | 认证方式 | 配置位置 |
|---|---|---|
| Step 容器拉取私有镜像 | ImagePullSecrets | TaskRun/PipelineRun PodTemplate |
| 构建后推送镜像 | Docker Config Secret | Step 容器的 env/volume mount |
| TRIGGER 访问私有仓库 | ServiceAccount ImagePullSecrets | EventListener ServiceAccount |
推送认证配置:
apiVersion: v1
kind: Secret
metadata:
name: docker-registry-cred
annotations:
tekton.dev/docker-0: https://registry.example.com
type: kubernetes.io/basic-auth
stringData:
username: robot-user
password: token-xxx
apiVersion: v1
kind: ServiceAccount
metadata:
name: tekton-builder
secrets:
- name: docker-registry-cred
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: push-image
spec:
taskRef:
name: kaniko-build
serviceAccountName: tekton-builder
podTemplate:
imagePullSecrets:
- name: regcred
常见问题:
- Harbor 等私有仓库需要配置
insecure-registry或引入 CA 证书。 - Docker Config 格式需符合
{"auths":{"registry": {}}}结构。 - 多 Registry 认证分别创建 Secret 并加到 ServiceAccount。
28 Pipeline 中的条件分支与循环处理
答案:
Tekton Pipeline 原生不支持传统编程语言的 if/else 和 for 循环,通过以下方式实现分支和重复逻辑。
条件分支实现方式:
| 方式 | 适用场景 | 实现 |
|---|---|---|
| When 表达式 | 2-5 个简单条件分支 | when 字段判断是否执行 Task |
| 参数映射 | 多值触发不同路径 | 外部 Trigger 根据不同 event 传入不同参数 |
| 自定义 Task | 复杂分支逻辑 | 外部控制器根据条件创建不同 PipelineRun |
| 条件运行 | 失败/跳过处理 | onError: continue + When 组合 |
循环重复执行实现方式:
| 方式 | 适用场景 | 说明 |
|---|---|---|
| Matrix | 固定参数列表的并行执行 | 声明式参数矩阵 |
| JSON 解析脚本 | 动态列表 | Step 中解析 JSON 参数并循环处理 |
| 递归 PipelineRun | 未知长度列表 | 一个 Task 判断是否需要再次触发 PipelineRun |
Pipeline Level 条件分支:
tasks:
- name: unit-test
taskRef:
name: test
- name: deploy-dev
taskRef:
name: deploy
params:
- name: env
value: dev
runAfter:
- unit-test
when:
- input: "$(params.branch)"
operator: "!="
values: ["main"]
- name: deploy-prod
taskRef:
name: deploy
params:
- name: env
value: prod
runAfter:
- unit-test
when:
- input: "$(params.branch)"
operator: "=="
values: ["main"]
Step 内循环处理:
steps:
- name: process-services
image: alpine
script: |
services='["api", "web", "worker"]'
for service in $(echo $services | jq -r '.[]'); do
echo "Processing $service"
# 循环执行构建或部署
build-service "$service"
done
29 Tekton 的版本演进与 API 兼容性
答案:
Tekton API 经历从 v1alpha1 到 v1 的演进,理解版本对应关系对迁移和配置至关重要。
| API 版本 | 状态 | 关键特性 |
|---|---|---|
v1alpha1 | 废弃 | 初期版本,PipelineResource 等旧 API |
v1beta1 | 过渡 | Task 和 Pipeline 稳定,参数类型扩展 |
v1 | 稳定 | GA 版本,移除 v1alpha1 资源(如 PipelineResource) |
v1 版本关键变化:
| 变化 | 说明 |
|---|---|
PipelineResource 移除 | Git、Image 等资源类型不再支持,迁移到 Workspace 和参数 |
taskRef.apiVersion 变更 | 从 tekton.dev/v1beta1 升级到 tekton.dev/v1 |
condition 字段移除 | 使用 when 替代 |
param.type 增加 object | 支持结构化参数 |
results.type 增加 | 支持 string、array、object |
迁移注意事项:
- v1beta1 资源仍然可读,但建议新资源使用 v1。
- PipelineResource 必须迁移到 Workspace + git-clone Task。
- Condition CRD 替换为 When 表达式。
- v1 默认开启
alphafeature flag 需要显式配置。
# v1 版本推荐格式
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: example
spec:
params:
- name: version
type: string
steps:
- name: run
image: alpine
script: |
echo $(params.version)
30 多架构镜像构建策略
答案:
Tekton 在多架构构建场景中结合 Buildx/Podman 或使用 Matrix 实现交叉编译。
方案一:Matrix 并行构建后合并
tasks:
- name: build-all-arch
matrix:
params:
- name: ARCH
value:
- amd64
- arm64
- arm/v7
maxConcurrency: 3
taskRef:
name: kaniko-build
params:
- name: IMAGE_TAG
value: "app:$(params.ARCH)"
- name: create-manifest
taskRef:
name: manifest-tool
params:
- name: IMAGE_NAME
value: app
- name: TAG
value: latest
- name: ARCH_LIST
value: "amd64,arm64,arm/v7"
runAfter:
- build-all-arch
方案二:Buildx 单步骤多架构构建
steps:
- name: buildx-multi-arch
image: docker:latest
script: |
docker buildx create --use
docker buildx build \
--platform linux/amd64,linux/arm64,linux/arm/v7 \
--tag registry.example.com/app:latest \
--push \
.
env:
- name: DOCKER_BUILDKIT
value: "1"
| 方案 | 优势 | 劣势 |
|---|---|---|
| Matrix + Kaniko | 各架构独立构建,错误隔离 | 需要额外 manifest 合并步骤 |
| Buildx | 单步骤完成,原生多架构支持 | 需要特权容器 |
| 交叉编译 | 纯软件方案,无需模拟器 | 需要各架构编译工具链 |
31 Task 的幂等性与状态管理
答案:
Tekton Task 通过 TaskRun 的幂等设计保证同一 Task 多次执行的结果一致性,避免重复构建的影响。
幂等性保证机制:
| 机制 | 说明 |
|---|---|
| TaskRun 唯一标识 | 每个 TaskRun 有独立 UID,执行环境相互隔离 |
| Step 容器隔离 | 每次 TaskRun 创建新 Pod,无残留状态 |
| Workspace 依赖 | TaskRun 使用独立的 Workspace 或确保 Workspace 内容可覆盖 |
| 结果幂等性 | 构建产物 tag 使用 commit SHA 确保唯一性 |
最佳实践:
steps:
- name: idempotent-build
image: docker
script: |
# 使用 commit SHA 作为 tag,确保幂等
TAG=$(params.COMMIT_SHA)
IMAGE="registry.example.com/app:${TAG}"
# 检查镜像是否已存在,避免重复构建
if docker manifest inspect "${IMAGE}" > /dev/null 2>&1; then
echo "Image already exists, skipping build"
exit 0
fi
docker build -t "${IMAGE}" .
docker push "${IMAGE}"
# 输出 digest
echo -n "${TAG}" > /tekton/results/image-tag
状态恢复场景:
- 同一 Task 重试时,输出结果可能不同(如
git-clone每次获取最新代码)。 - 设计 Task 时确保输入参数唯一性(如 commit SHA),相同输入产生相同输出。
- 构建 Task 根据 commit SHA 判断镜像是否已存在,跳过重复构建。
32 PipelineRun 的取消与优雅终止
答案:
Tekton 支持优雅取消 PipelineRun,逐步释放资源。
取消方式:
| 方式 | 命令 | 行为 |
|---|---|---|
| 取消 PipelineRun | tkn pipelinerun cancel <name> | 取消整个流水线,终止所有正在运行的 TaskRun |
| 取消 TaskRun | tkn taskrun cancel <name> | 取消单个 TaskRun |
| GracePeriod | — | 等待正在执行的 Step 完成后再终止 |
| 强制终止 | kubectl delete pipelinerun <name> | 立即删除,不等待 Step 完成 |
优雅终止流程:
# 优雅取消 PipelineRun
tkn pipelinerun cancel my-pipelinerun
# 强制取消并删除
kubectl delete pipelinerun my-pipelinerun
# 通过 API 取消
kubectl patch pipelinerun my-pipelinerun \
--type=merge \
-p '{"spec":{"status":"Cancelled"}}'
取消后行为:
- 正在执行的 TaskRun 收到 SIGTERM 信号。
- 等待中的 TaskRun(被
runAfter依赖阻塞)被标记为Cancelled。 - 已完成的下游 TaskRun 状态不受影响。
- PipelineRun 最终状态为
Cancelled。
超时与取消的区别:
| 状态 | 触发原因 | 最终状态 |
|---|---|---|
| 超时 | timeout 字段到达 | Failed(ExceededTimeout) |
| 取消 | 用户手动取消 | Cancelled |
| 停止 | spec.status: Stopped | Stopped |
33 Workspace 的 SubPath 与多路径映射
答案:
Workspace 支持 SubPath 实现单个 Volume 中不同子路径的隔离挂载。
SubPath 配置方式:
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: multi-service
spec:
workspaces:
- name: shared
tasks:
- name: build-api
taskRef:
name: build-service
workspaces:
- name: source
workspace: shared
subPath: services/api
- name: build-web
taskRef:
name: build-service
workspaces:
- name: source
workspace: shared
subPath: services/web
子路径与多 Workspace 对比:
| 策略 | 适用场景 | Volume 数量 | 数据隔离 |
|---|---|---|---|
| 单个 Workspace + SubPath | 共享一个大 Volume,各 Task 使用不同目录 | 1 | 同一 Volume 不同子路径 |
| 多个 Workspace | 不同类型数据(代码、缓存、凭证) | N | 完全隔离 |
| 动态 PVC 模板 | 每个 TaskRun 分配独立 PVC | 每个 Run 一个 | 完全隔离 |
动态 PVC 模板示例:
spec:
workspaces:
- name: source
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: fast-ssd
策略选择:
- 多服务共享代码库使用 SubPath 区分不同模块。
- 构建产物和依赖缓存使用各自 Workspace 便于设置不同 StorageClass 和回收策略。
- 测试场景使用 EmptyDir,生产使用 PVC VolumeClaimTemplate。
34 Tekton 的 RBAC 权限模型
答案:
Tekton 依赖 Kubernetes RBAC 控制资源访问权限,支持细粒度权限配置。
核心资源权限:
| 资源 | API Group | 建议权限 |
|---|---|---|
| Task | tekton.dev | 开发人员:get/list/watch |
| TaskRun | tekton.dev | 开发人员:create/get/list |
| Pipeline | tekton.dev | 开发人员:get/list/watch |
| PipelineRun | tekton.dev | 开发人员:create/get/list |
| EventListener | triggers.tekton.dev | 运维:create/update/delete |
| TriggerTemplate | triggers.tekton.dev | 运维:create/update/delete |
最小权限配置示例:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tekton-developer
rules:
- apiGroups: ["tekton.dev"]
resources: ["tasks", "pipelines"]
verbs: ["get", "list", "watch"]
- apiGroups: ["tekton.dev"]
resources: ["taskruns", "pipelineruns"]
verbs: ["create", "get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tekton-admin
rules:
- apiGroups: ["tekton.dev"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["triggers.tekton.dev"]
resources: ["*"]
verbs: ["*"]
- apiGroups: [""]
resources: ["secrets", "configmaps", "serviceaccounts"]
verbs: ["create", "update", "delete"]
ServiceAccount 绑定:
apiVersion: v1
kind: ServiceAccount
metadata:
name: ci-runner
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ci-runner-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tekton-developer
subjects:
- kind: ServiceAccount
name: ci-runner
namespace: default
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: example
spec:
serviceAccountName: ci-runner
pipelineRef:
name: example-pipeline
35 生产环境 Tekton 部署的最佳实践
答案:
生产环境部署 Tekton 需关注高可用、资源隔离、安全加固和监控告警。
基础设施层面:
| 领域 | 最佳实践 |
|---|---|
| 高可用 | 副本数 >= 2,设置 PodAntiAffinity 跨节点调度 |
| 资源隔离 | 部署在独立命名空间(tekton-pipelines),设置 ResourceQuota |
| 持久化 | PVC 配置合适的 StorageClass,启用回收策略 |
| 网络 | 限制 Metrics 端口只对内网暴露,配置NetworkPolicy |
| 备份 | 定期备份 Tekton CRD 资源定义 |
安全加固:
| 领域 | 配置 |
|---|---|
| Pod Security | Task 使用 runAsNonRoot,禁止特权模式 |
| Secret 管理 | 使用 External Secrets Operator 管理 Registry 凭据 |
| RBAC | 最小权限原则,按角色分配资源权限 |
| Network Policy | 限制 Pod 间通信,只允许必要端口 |
| Chains | 配置签名和 attestation |
Operator 配置建议:
apiVersion: tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
spec:
profile: basic
targetNamespace: tekton-pipelines
pipeline:
metrics.pipelinerun.duration-type: histogram
metrics.taskrun.duration-type: histogram
metrics.count: enabled
default-service-account: tekton-worker
running-in-environment-with-injected-sidecars: false
监控与告警:
# Prometheus 指标采集
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: tekton-metrics
spec:
selector:
matchLabels:
app.kubernetes.io/component: tekton-pipelines-controller
endpoints:
- port: metrics
interval: 15s
关键告警规则:
| 告警项 | PromQL | 说明 |
|---|---|---|
| PipelineRun 失败率 | rate(tekton_pipelinerun_duration_seconds_count{status="failed"}[5m]) > 0 | 5 分钟内有 PipelineRun 失败 |
| TaskRun 长时间运行 | tekton_taskrun_duration_seconds > 1800 | TaskRun 运行超过 30 分钟 |
| EventListener 错误 | rate(tekton_eventlistener_event_count{status="error"}[5m]) > 0 | EventListener 处理事件出错 |
| 队列深度 | PipelineRun Pending 数量超过阈值 | 流水线排队积压 |
日志汇聚:
- Controller 日志通过 Fluentd/Logstash 汇聚到 Elasticsearch 或 Loki。
- TaskRun 日志保持事件关联性,使用
tekton.dev/pipelineRunLabel 关联。 - 设置合理的日志保留周期,避免磁盘占用膨胀。
36 Tekton 与 Jenkins 的架构对比
答案:
Tekton 和 Jenkins 在架构设计和运维模式上存在本质差异。
| 维度 | Tekton | Jenkins |
|---|---|---|
| 架构 | Kubernetes 原生,CRD + Controller | Master-Agent 架构,需独立部署 |
| 存储 | Kubernetes API Server(CRD 资源) | Jenkins Home 目录(文件 + DB) |
| 扩展性 | Kubernetes 原生水平扩展 | Master 单点瓶颈,需额外高可用方案 |
| Pipeline 定义 | YAML 声明式 | Groovy DSL / Declarative Pipeline |
| Agent 管理 | Kubernetes Pod 动态创建 | 固定 Agent 节点池或动态 Agent |
| 插件生态 | Catalog Task + OCI Bundle | 丰富插件市场 |
| 事件驱动 | Tekton Triggers 原生支持 | Webhook + 插件 |
| 安全性 | Kubernetes RBAC + Chains | Jenkins 自建权限体系 |
| 运维复杂度 | CRD 管理,无独立进程 | Jenkins Master 需独立维护和备份 |
迁移模式:
- 并行运行:Tekton 和 Jenkins 同时运行,逐步迁移 Pipeline。
- Gateway 模式:Jenkins Job 调用 Tekton APIServer 执行构建。
- 替换模式:Jenkins Pipeline 逐条迁移为 Tekton Task,最终下线 Jenkins。
- 混合模式:CI(构建)使用 Tekton,CD(部署审批)保留 Jenkins。
迁移要点:
- Jenkins Pipeline 的 Stage 对应 Tekton Pipeline 的 Task。
- Jenkins Agent 的 Label 对应 Tekton 的 PodTemplate 节点选择器。
- Jenkins 共享库对应 Tekton Catalog Task 或 OCI Bundle。
- Jenkins Credentials 映射为 Kubernetes Secret 并通过 Workspace 注入。