跳转到内容

Tekton 面试题

36 道题
分类
DevOps
题目数
36 道
已阅读 0 / 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职责
PipelinesTask, Pipeline, TaskRun, PipelineRun流水线编排与执行
TriggersEventListener, Trigger, TriggerTemplate, TriggerBinding事件驱动触发
ChainsSignedTaskRun, SignedPipelineRun签名与 attestation
Dashboard—Web 管理界面
OperatorTektonConfig, 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 内,共享网络和卷。

维度StepSidecar
角色执行业务逻辑的主容器提供辅助服务的辅助容器
生命周期顺序执行,前一个完成才启动后一个在 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 等于任一 valuesinput: "main", operator: "==", values: ["main", "release"]
!=排除匹配,input 不等于任一 valuesinput: "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职责
EventListenerEventListener暴露 Kubernetes Service 端点,接收外部事件
TriggerTrigger绑定事件源到 TriggerTemplate
TriggerTemplateTriggerTemplate定义创建 PipelineRun 的模板
TriggerBindingTriggerBinding从事件负载中提取参数并绑定到模板
ClusterTriggerBindingClusterTriggerBinding集群级别的 TriggerBinding
InterceptorInterceptor事件过滤、验证和转换

工作流程:

  1. 外部系统(GitHub、GitLab、Jenkins)向 EventListener Service 发送 HTTP 请求。
  2. EventListener 将请求传递给 Interceptor 链进行过滤和验证。
  3. 验证通过后,Trigger 匹配并激活 TriggerTemplate。
  4. TriggerTemplate 结合 TriggerBinding 提取的参数,创建 PipelineRun 或其他资源。
  5. 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 RequestsecretRef、eventTypes
Bitbucket Interceptor验证 Bitbucket WebhooksecretRef、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: v1
kind: ConfigMap
metadata:
  name: chains-config
  namespace: tekton-chains
data:
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: oci
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: oci
  transparency.enabled: "true"

验证流程:

  1. PipelineRun/TaskRun 执行完成后,Chains 计算其 digest。
  2. Chains 使用配置的签名密钥对 digest 签名。
  3. 签名和 attestation 存储到 OCI 仓库或 Secret 中。
  4. 消费者通过 cosign verify-attestation 验证流水线来源的完整性。
14 Tekton Hub 与社区 Catalog 的使用

答案:

Tekton Hub 提供集中式 Task 和 Pipeline 发现平台,Catalog 是社区维护的可复用资源仓库。

概念说明URL
Tekton HubWeb 门户,浏览、搜索和安装 Tasks/Pipelineshub.tekton.dev
Tekton CatalogGitHub 仓库,社区贡献的任务和流水线集合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 PipelinesTektonPipeline必选
Tekton TriggersTektonTrigger可选
Tekton ChainsTektonChain可选
Tekton DashboardTektonDashboard可选
Tekton HubTektonHub可选
Tekton AddonsTektonAddon可选

核心能力:

  • 安装与升级:通过 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 无限制全局
maxConcurrencyPipelineRun Spec 的 maxConcurrency 字段每个 Pipeline 级别
taskRunSpecsPipelineRun 的 taskRunSpecs.maxConcurrencyTask 级别
资源配额(ResourceQuota)Kubernetes 原生 ResourceQuota命名空间级别
LimitRangeKubernetes 原生 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 级别的超时与重试配置。

级别配置字段默认值说明
PipelineRuntimeout1 小时PipelineRun 整体超时
PipelineRun TasktaskRunSpecs.timeout继承 PipelineRun单个 TaskRun 超时
TaskRuntimeout1 小时TaskRun 整体超时
Steptimeout无限制单个 Step 超时
TaskRunretries0TaskRun 失败后的重试次数

超时策略:

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 控制。

超时终止流程:

  1. 超时时间到达后,Tekton 向 Pod 发送 SIGTERM 信号。
  2. 等待 terminationGracePeriodSeconds(默认 30s)。
  3. 超时后发送 SIGKILL 强制终止。
  4. TaskRun/PipelineRun 状态更新为 Failed,原因标记为 ExceededTimeout。
19 资源配额与节点选择策略

答案:

Tekton 通过 PodTemplate 和 ResourceRequirements 精细控制流水线 Pod 的资源分配与调度。

配置项字段作用
CPU/Memory 请求resources.requests容器调度时的资源保障
CPU/Memory 限制resources.limits容器运行时的资源上限
节点选择器nodeSelector强制调度到指定标签节点
容忍度tolerations允许调度到有污点的节点
亲和性affinity节点亲和性与 Pod 亲和性策略
Service AccountserviceAccountNamePod 运行的 SA 权限
优先级类priorityClassNamePod 调度优先级
安全上下文securityContextPod 和容器的安全配置

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 cachePVC
Blob 缓存使用 gcs-upload/s3-upload 缓存中间产物GCS/S3/MinIO
Layer CachingKaniko/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
revisionmain分支、标签或 commit SHA
depth0(完整克隆)浅克隆深度
submodulestrue是否初始化子模块
sslVerifytrue是否验证 SSL
deleteExistingtrue目标目录存在时是否删除
httpProxy—HTTP 代理地址
httpsProxy—HTTPS 代理地址
userHome/home/gitGit 用户家目录

完整配置示例:

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 链路。

集成模式:

阶段TektonArgoCD
代码构建从 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 对应一个 Regular Container。

执行机制:

  • Tekton 通过 entrypoint 二进制拦截 Step 容器的启动入口,按 Task Spec 中 Step 定义顺序依次启动容器。
  • 前一个 Step 退出(exit 0)后在共享 /tekton/run/ 目录写入完成标记,下一个 Step 的 entrypoint 检测到标记后开始执行。
  • 前一个 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 TaskCustom 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 容器拉取私有镜像ImagePullSecretsTaskRun/PipelineRun PodTemplate
构建后推送镜像Docker Config SecretStep 容器的 env/volume mount
TRIGGER 访问私有仓库ServiceAccount ImagePullSecretsEventListener 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 默认开启 alpha feature 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,逐步释放资源。

取消方式:

方式命令行为
取消 PipelineRuntkn pipelinerun cancel <name>取消整个流水线,终止所有正在运行的 TaskRun
取消 TaskRuntkn 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: StoppedStopped
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建议权限
Tasktekton.dev开发人员:get/list/watch
TaskRuntekton.dev开发人员:create/get/list
Pipelinetekton.dev开发人员:get/list/watch
PipelineRuntekton.dev开发人员:create/get/list
EventListenertriggers.tekton.dev运维:create/update/delete
TriggerTemplatetriggers.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 SecurityTask 使用 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]) > 05 分钟内有 PipelineRun 失败
TaskRun 长时间运行tekton_taskrun_duration_seconds > 1800TaskRun 运行超过 30 分钟
EventListener 错误rate(tekton_eventlistener_event_count{status="error"}[5m]) > 0EventListener 处理事件出错
队列深度PipelineRun Pending 数量超过阈值流水线排队积压

日志汇聚:

  • Controller 日志通过 Fluentd/Logstash 汇聚到 Elasticsearch 或 Loki。
  • TaskRun 日志保持事件关联性,使用 tekton.dev/pipelineRun Label 关联。
  • 设置合理的日志保留周期,避免磁盘占用膨胀。
36 Tekton 与 Jenkins 的架构对比

答案:

Tekton 和 Jenkins 在架构设计和运维模式上存在本质差异。

维度TektonJenkins
架构Kubernetes 原生,CRD + ControllerMaster-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 + ChainsJenkins 自建权限体系
运维复杂度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 注入。