跳转到内容

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
DashboardWeb 管理界面
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 中定义的 runAfterfrom 字段自动解析依赖图,并行执行无依赖的 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 的 argscommandscript 中。
  • 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。
  • 表达式结构inputoperatorvalues 三个字段。
  • 支持运算符
运算符语义示例
==精确匹配,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 表达式过滤和提取事件负载filteroverlays 字段
GitHub Interceptor验证 GitHub Webhook 签名、处理 PR/Issue 事件secretRefeventTypes
GitLab Interceptor验证 GitLab Webhook 签名、处理 Merge RequestsecretRefeventTypes
Bitbucket Interceptor验证 Bitbucket WebhooksecretRefeventTypes

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"

验证流程

  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 配置节点选择器和容忍度。
  • 多集群支持:通过 TektonConfigTektonPipeline 等 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 挂载 .m2node_modulespip 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 的仓库级缓存层。
  • 清理策略通过 volumeClaimTemplatestorageClassName 配置回收策略。
  • 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 核心参数

参数默认值说明
urlGit 仓库 URL
revisionmain分支、标签或 commit SHA
depth0(完整克隆)浅克隆深度
submodulestrue是否初始化子模块
sslVerifytrue是否验证 SSL
deleteExistingtrue目标目录存在时是否删除
httpProxyHTTP 代理地址
httpsProxyHTTPS 代理地址
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: [email protected]
      - 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 validatetkn task describe
一次运行运行前tkn task start --dry-run 预览 Pod YAML
实时日志运行时tkn taskrun logs -ftkn pipelinerun logs -f
Pod 状态运行时kubectl describe pod <taskrun-pod>
进入容器运行时kubectl exec -it <pod> -c step-xxx -- sh
运行后日志运行后tkn taskrun logs --lastkubectl 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 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 增加支持 stringarrayobject

迁移注意事项

  • 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 注入。