云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载本文是一份关于 Tekton Pipeline 中 Pod 模板Pod Template的技术指南核心围绕TaskRun与PipelineRun如何通过podTemplate字段复用PodSpec的“样板配置”以及如何通过全局config-defaultsConfigMap 设置默认模板、如何在taskRunSpecs中做参数替换、如何使用imagePullSecrets查找镜像入口点entrypoint。读完本文你将掌握 Pod 模板支持的完整字段清单、全局模板与运行级模板的合并规则以及 Affinity Assistant Pod 模板的用法并能直接在自己的 Tekton 工作负载中落地。什么是 Pod 模板Pod 模板定义了PodSpec的一部分配置对应的 Kubernetes API 为Pod v1 coreTekton 将它作为运行Task与Pipeline时创建 Pod 的“样板boilerplate”使用。也就是说你不必在每个Task/Pipeline内部重复编写调度相关的底层字段而是可以在更外层统一指定。你可以在两类资源上指定 Pod 模板TaskRun模板作用于该次 TaskRun 生成的单个 Pod。PipelineRun模板作用于该 PipelineRun 执行期间创建的所有 Task Pod。此外你还可以在 Tekton 的全局配置config-defaultsConfigMap 中通过default-pod-template键定义一个全局 Pod 模板见 additional-configs.md 中的“Customizing basic execution parameters”。全局模板会与你在TaskRun/PipelineRun中指定的模板进行合并merge合并规则详见下文。指定 Pod 模板的具体示例可参考为TaskRun指定 Pod 模板为PipelineRun指定 Pod 模板一个最小示例在TaskRun中通过podTemplate.securityContext强制容器以非 root 用户运行这是常见的非 root 实践见 taskruns.mdapiVersion: tekton.dev/v1 # 或 tekton.dev/v1beta1 kind: TaskRun metadata: generateName: show-non-root-steps-run- spec: taskRef: name: show-non-root-steps podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001注意如果某个 Task 的 step 自身指定了与 Pod 模板不同的用户那么 step 自身的securityContext会优先生效覆盖 Pod 级别设置。完整的可运行示例见 examples/v1/taskruns/run-steps-as-non-root.yaml。在PipelineRun中Pod 模板同时携带securityContext与volumes也是常见用法例如将 PVC 挂载为缓存卷apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: mypipelinerun spec: pipelineRef: name: mypipeline podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001 volumes: - name: my-cache persistentVolumeClaim: claimName: my-volume-claim自定义任务Custom Tasks不一定使用 Pod 模板需要查阅你所使用的自定义任务文档确认其是否支持。全局默认 Pod 模板与合并策略除了在资源上直接指定你还可以在config-defaultsConfigMap 中通过default-pod-template键设置全局默认模板。该 ConfigMap 的定义见 config/config-defaults.yaml其中_example块对每个键都给出了注释说明apiVersion: v1 kind: ConfigMap metadata: name: config-defaults data: default-service-account: tekton default-timeout-minutes: 20 default-pod-template: | nodeSelector: kops.k8s.io/instancegroup: build-instance-group default-managed-by-label-value: my-tekton-installation default-task-run-workspace-binding: | emptyDir: {} default-max-matrix-combinations-count: 1024 default-resolver-type: git合并规则全局模板与TaskRun/PipelineRun中指定的模板会合并规则如下除env和volumes外的所有字段如果全局模板与运行级模板同时设置了某个字段以TaskRun或PipelineRun中的值为准运行级覆盖全局。env与volumes字段按数组元素中的name进行合并。如果某项name相同则使用TaskRun或PipelineRun中的那一项name不同的项则全部保留。源码层面的合并实现以上规则在源码中有精确对应。pod.Template类型与MergePodTemplateWithDefault函数定义于 pkg/apis/pipeline/pod/template.goMergePodTemplateWithDefault(tpl, defaultTpl *PodTemplate)逐字段判断凡是运行级模板字段为 nil或空字符串/空切片时才回退到全局默认值env与volumes则调用mergeByName按name合并见该文件mergeByName与getName的实现。整体逻辑与上文描述的合并规则完全一致。从源码结构看运行级模板是“高优先级覆盖层”全局模板只是兜底默认值。这也是为什么全局模板主要用于统一团队基线如默认 nodeSelector、默认安全上下文而个别任务再通过运行级模板覆盖。配置解析入口default-pod-template与default-affinity-assistant-pod-template两个键在 pkg/apis/config/default.go 中定义第 6768 行的常量并在NewDefaultsFromMap中通过 YAML 反序列化为pod.Template/pod.AffinityAssistantTemplate结构第 177191 行。若 YAML 解析失败控制器会直接报错拒绝加载配置。对应的解析用例可参考 pkg/apis/config/default_test.go 与测试数据 pkg/apis/config/testdata/config-defaults-with-pod-template.yaml、pkg/apis/config/testdata/config-defaults-pod-template-err.yaml后者用于验证非法配置的报错路径。在 taskRunSpecs 中对 Pod 模板做参数替换当在PipelineRun的taskRunSpecs中使用 Pod 模板时你可以基于 Pipeline 参数动态配置 Pod 模板字段——这对使用Matrix扇出fan out的 PipelineTask 尤其有用因为每个矩阵组合携带不同的参数值。参数替换使用标准 Tekton 语法$(params.paramName)支持所有接受字符串值的 Pod 模板字段。例如taskRunSpecs: - pipelineTaskName: build-task podTemplate: nodeSelector: kubernetes.io/arch: $(params.arch) environment: $(params.env) tolerations: - key: workload-type operator: Equal value: $(params.workload) effect: NoSchedule更完整的示例见 pipelineruns.md 中的“Parameter Substitution in taskRunSpecs”。与 Matrix 结合每个组合一个独立 TaskRun当与 Matrix 配合使用时每个矩阵组合都会创建一个独立的TaskRun并将参数值替换进对应的 Pod 模板。例如spec: taskRunSpecs: - pipelineTaskName: build-and-push-manifest podTemplate: nodeSelector: kubernetes.io/arch: $(params.arch) pipelineSpec: tasks: - name: build-and-push-manifest matrix: params: - name: arch value: [amd64, arm64] taskSpec: params: - name: arch steps: - name: build-and-push image: ubuntu script: | echo building on $(params.arch)上述配置中Matrix 会产生两个TaskRun——一个面向amd64、一个面向arm64各自通过替换后的nodeSelector调度到对应架构的节点。完整示例见 examples/v1/pipelineruns/beta/pipelinerun-with-matrix-and-taskrunspecs-param-substitution.yaml。更多细节参见 pipelineruns.md 中的“Matrix Support with taskRunSpecs”。taskRunSpecs 的覆盖语义taskRunSpecs中的podTemplate会覆盖Pipeline 级别的spec.podTemplate配置而 Pipeline 级别的securityContext等字段仍会保留。例如下面的配置中build-task使用任务级podTemplatenodeSelector: disktypessd同时继承 PipelineRun 级securityContextrunAsUser: 1000、runAsGroup: 2000、fsGroup: 3000并拥有 1 小时 30 分钟的超时spec: podTemplate: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 taskRunSpecs: - pipelineTaskName: build-task serviceAccountName: sa-for-build podTemplate: nodeSelector: disktype: ssd timeout: 1h30mv1beta1 中对应字段名为taskServiceAccountName与taskPodTemplate见 pipelineruns.md。支持的字段清单Pod 模板支持下表所列字段各字段的 Kubernetes 语义详见对应链接字段说明envPod 模板中在TaskRun/PipelineRun级别定义的环境变量优先级高于steps与stepTemplate中定义的环境变量nodeSelector必须为 truePod 才能被调度到对应节点参见 Assigning Pods to Nodestolerations允许但不强制Pod 调度到带匹配污点taints的节点上affinity根据节点上的标签约束 Pod 可被调度的节点集合securityContext指定 Pod 级安全属性与通用容器设置如runAsUser与selinuxvolumes指定 Pod 内容器可挂载的卷列表允许你为Task中的每个volumeMount指定卷类型runtimeClassName指定 Pod 的 RuntimeClassautomountServiceAccountToken默认true。决定 Tekton 是否在容器内预定义路径自动挂载 Pod 所用 ServiceAccount 的 tokendnsPolicy默认ClusterFirst。指定 Pod 的 DNS 策略。合法值为ClusterFirst、Default、None。不支持ClusterFirstWithHostNet因为 Tekton Pod 不能使用 host networkingdnsConfig指定 Pod 的 附加 DNS 配置如 nameserver 与 search domainsenableServiceLinks默认true。决定 Pod 所在命名空间中的 Service 是否像 Docker service links 一样以环境变量形式注入 PodpriorityClassName指定 Pod 的 PriorityClass允许你选择性让低优先级工作负载被抢占schedulerName指定调度 Pod 时使用的 调度器。可以为不同类型的工作负载指定不同调度器例如机器学习负载使用volcano.shimagePullSecrets指定拉取私有镜像时使用的 Secret参见 从私有仓库拉取镜像hostNetwork默认false。决定是否使用宿主机网络命名空间hostUsers默认true。决定是否使用宿主的用户命名空间。设为false时为 Pod 创建新的用户命名空间提供更好的安全隔离有助于缓解容器逃逸漏洞。该字段为 alpha 级别需要在 Kubernetes 集群上启用UserNamespacesSupportfeature gateKubernetes 1.25 可用hostAliases向 Pod 的/etc/hosts添加条目提供 Pod 级主机名覆盖参见 Kubernetes 文档topologySpreadConstraints控制 Pod 在集群拓扑域之间的分布方式上述字段在源码pod.Template结构体pkg/apis/pipeline/pod/template.go中都有对应的 Go 字段与 JSON tag如nodeSelector、env、tolerations、affinity、securityContext、volumes、runtimeClassName、automountServiceAccountToken、dnsPolicy、dnsConfig、enableServiceLinks、priorityClassName、schedulerName、imagePullSecrets、hostAliases、hostNetwork、hostUsers、topologySpreadConstraints可供核对字段名与类型。使用 imagePullSecrets 查找入口点entrypoint当Task中没有配置command且podTemplate中配置了imagePullSecrets时Tekton Controller 会使用这些imagePullSecrets去镜像仓库查找镜像的入口点。Tekton Controller 的 ServiceAccount 默认被授予访问 Secret 的权限参见 config/200-clusterrole.yaml。如果你的 Controller ServiceAccount 没有被授予访问其他命名空间下 Secret 的权限需要通过RoleBinding显式授权例如apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: creds-getter namespace: my-ns rules: - apiGroups: [] resources: [secrets] resourceNames: [creds] verbs: [get]apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: creds-getter-binding namespace: my-ns subjects: - kind: ServiceAccount name: tekton-pipelines-controller namespace: tekton-pipelines apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: creds-getter apiGroup: rbac.authorization.k8s.io源码中的调用链这一行为在源码中有完整的调用链在 pkg/pod/pod.go 的第 273283 行构建 Pod 时取出taskRun.Spec.PodTemplate并将其中的ImagePullSecrets传给resolveEntrypoints。resolveEntrypoints定义在 pkg/pod/entrypoint_lookup.go遍历所有 step凡是没有显式command的容器都会通过EntrypointCache.get()查询镜像元数据入口点命令与 digest并传入namespace、serviceAccountName与imagePullSecrets。查询完成后镜像引用会被改写为按 digest 引用的形式steps[i].Image ref.Context().Digest(...)保证可复现性。EntrypointCache的实际实现见 pkg/pod/entrypoint_lookup_impl.go其单元测试在 pkg/pod/entrypoint_lookup_test.go 与 pkg/pod/entrypoint_lookup_impl_test.go。也就是说imagePullSecrets在这一场景下不仅决定 kubelet 拉镜像时的凭据还直接决定了 Controller 能否成功解析镜像入口点——若 Controller 无权读取对应 Secret任务会因 entrypoint 解析失败而无法启动。Affinity Assistant Pod 模板使用 Workspaces 时Tekton 会创建 Affinity Assistant Pod 来协助调度。你在TaskRun和PipelineRun中指定的 Pod 模板同样适用于这些 Affinity Assistant Pod但只作用于部分字段。Affinity Assistant Pod 支持的字段仅限于tolerations、nodeSelector、securityContext、priorityClassName与imagePullSecrets含义见上表。与全局 Pod 模板类似你也可以在 Tekton 配置中通过default-affinity-assistant-pod-template键定义全局 Affinity Assistant Pod 模板见 additional-configs.md其合并策略与上文描述的default-pod-template一致仅针对上述受支持字段。源码层面的对应实现在 pkg/apis/pipeline/pod/template.go 中Template.ToAffinityAssistantTemplate()方法第 168180 行将完整模板裁剪为仅含NodeSelector、Tolerations、ImagePullSecrets、SecurityContext、PriorityClassName的AffinityAssistantTemplate——这正是“只作用于部分字段”的代码级体现。MergeAAPodTemplateWithDefault实现 Affinity Assistant 模板与全局默认模板的合并规则与MergePodTemplateWithDefault相同运行级覆盖全局级。小结与实践建议职责分层把“集群级基线”默认节点选择、默认安全上下文、默认镜像拉取凭据放进config-defaults的default-pod-template把“任务级特例”写在TaskRun/PipelineRun的podTemplate中运行级字段优先。动态调度利用taskRunSpecs$(params.xxx)参数替换配合 Matrix 实现按架构、按环境动态选择节点与容忍度无需为每个组合手写 Pod 模板。安全默认runAsNonRoot、hostUsers: false需集群启用UserNamespacesSupport、显式imagePullSecrets等都是值得优先纳入模板的字段。权限联动若 Task 镜像不带command且依赖私有镜像请确保 Tekton Controller 的 ServiceAccount 具备读取目标命名空间 Secret 的权限否则 entrypoint 解析会失败。如需进一步深入可继续阅读 docs/taskruns.md、docs/pipelineruns.md、docs/additional-configs.md 与 docs/workspaces.md。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐在 Tekton Pipeline 中使用 Windows 节点TaskRun 与 PipelineRun 的跨平台调度指南在 Tekton Pipeline 中使用 Windows 节点TaskRun 与 PipelineRun 的跨平台调度指南 导读 Tekton Pipeli云原生CI/CDDevOps后端Tekton Pipeline Affinity Assistants 完整指南基于 Pod 亲和性实现 PipelineRun 协同调度与共享卷并行Tekton Pipeline Affinity Assistants 完整指南基于 Pod 亲和性实现 PipelineRun 协同调度与共享卷并行 Aff云原生CI/CDDevOps后端Tekton Pipelines核心概念速览Task、Pipeline、TaskRun与PipelineRun一图读懂Tekton Pipelines核心概念速览Task、Pipeline、TaskRun与PipelineRun一图读懂 刚接触 Tekton Pipeline云原生CI/CDDevOps后端上一篇微信聊天记录永久保存指南如何让珍贵对话永不丢失下一篇react-native-router-flux 路由文档未来沉浸式体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Tekton Pipeline Pod 模板（PodTemplate）完整指南：TaskRun/PipelineRun 调度配置、参数替换与全局默认模板合并策略
云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载本文是一份关于 Tekton Pipeline 中 Pod 模板Pod Template的技术指南核心围绕TaskRun与PipelineRun如何通过podTemplate字段复用PodSpec的“样板配置”以及如何通过全局config-defaultsConfigMap 设置默认模板、如何在taskRunSpecs中做参数替换、如何使用imagePullSecrets查找镜像入口点entrypoint。读完本文你将掌握 Pod 模板支持的完整字段清单、全局模板与运行级模板的合并规则以及 Affinity Assistant Pod 模板的用法并能直接在自己的 Tekton 工作负载中落地。什么是 Pod 模板Pod 模板定义了PodSpec的一部分配置对应的 Kubernetes API 为Pod v1 coreTekton 将它作为运行Task与Pipeline时创建 Pod 的“样板boilerplate”使用。也就是说你不必在每个Task/Pipeline内部重复编写调度相关的底层字段而是可以在更外层统一指定。你可以在两类资源上指定 Pod 模板TaskRun模板作用于该次 TaskRun 生成的单个 Pod。PipelineRun模板作用于该 PipelineRun 执行期间创建的所有 Task Pod。此外你还可以在 Tekton 的全局配置config-defaultsConfigMap 中通过default-pod-template键定义一个全局 Pod 模板见 additional-configs.md 中的“Customizing basic execution parameters”。全局模板会与你在TaskRun/PipelineRun中指定的模板进行合并merge合并规则详见下文。指定 Pod 模板的具体示例可参考为TaskRun指定 Pod 模板为PipelineRun指定 Pod 模板一个最小示例在TaskRun中通过podTemplate.securityContext强制容器以非 root 用户运行这是常见的非 root 实践见 taskruns.mdapiVersion: tekton.dev/v1 # 或 tekton.dev/v1beta1 kind: TaskRun metadata: generateName: show-non-root-steps-run- spec: taskRef: name: show-non-root-steps podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001注意如果某个 Task 的 step 自身指定了与 Pod 模板不同的用户那么 step 自身的securityContext会优先生效覆盖 Pod 级别设置。完整的可运行示例见 examples/v1/taskruns/run-steps-as-non-root.yaml。在PipelineRun中Pod 模板同时携带securityContext与volumes也是常见用法例如将 PVC 挂载为缓存卷apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: mypipelinerun spec: pipelineRef: name: mypipeline podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001 volumes: - name: my-cache persistentVolumeClaim: claimName: my-volume-claim自定义任务Custom Tasks不一定使用 Pod 模板需要查阅你所使用的自定义任务文档确认其是否支持。全局默认 Pod 模板与合并策略除了在资源上直接指定你还可以在config-defaultsConfigMap 中通过default-pod-template键设置全局默认模板。该 ConfigMap 的定义见 config/config-defaults.yaml其中_example块对每个键都给出了注释说明apiVersion: v1 kind: ConfigMap metadata: name: config-defaults data: default-service-account: tekton default-timeout-minutes: 20 default-pod-template: | nodeSelector: kops.k8s.io/instancegroup: build-instance-group default-managed-by-label-value: my-tekton-installation default-task-run-workspace-binding: | emptyDir: {} default-max-matrix-combinations-count: 1024 default-resolver-type: git合并规则全局模板与TaskRun/PipelineRun中指定的模板会合并规则如下除env和volumes外的所有字段如果全局模板与运行级模板同时设置了某个字段以TaskRun或PipelineRun中的值为准运行级覆盖全局。env与volumes字段按数组元素中的name进行合并。如果某项name相同则使用TaskRun或PipelineRun中的那一项name不同的项则全部保留。源码层面的合并实现以上规则在源码中有精确对应。pod.Template类型与MergePodTemplateWithDefault函数定义于 pkg/apis/pipeline/pod/template.goMergePodTemplateWithDefault(tpl, defaultTpl *PodTemplate)逐字段判断凡是运行级模板字段为 nil或空字符串/空切片时才回退到全局默认值env与volumes则调用mergeByName按name合并见该文件mergeByName与getName的实现。整体逻辑与上文描述的合并规则完全一致。从源码结构看运行级模板是“高优先级覆盖层”全局模板只是兜底默认值。这也是为什么全局模板主要用于统一团队基线如默认 nodeSelector、默认安全上下文而个别任务再通过运行级模板覆盖。配置解析入口default-pod-template与default-affinity-assistant-pod-template两个键在 pkg/apis/config/default.go 中定义第 6768 行的常量并在NewDefaultsFromMap中通过 YAML 反序列化为pod.Template/pod.AffinityAssistantTemplate结构第 177191 行。若 YAML 解析失败控制器会直接报错拒绝加载配置。对应的解析用例可参考 pkg/apis/config/default_test.go 与测试数据 pkg/apis/config/testdata/config-defaults-with-pod-template.yaml、pkg/apis/config/testdata/config-defaults-pod-template-err.yaml后者用于验证非法配置的报错路径。在 taskRunSpecs 中对 Pod 模板做参数替换当在PipelineRun的taskRunSpecs中使用 Pod 模板时你可以基于 Pipeline 参数动态配置 Pod 模板字段——这对使用Matrix扇出fan out的 PipelineTask 尤其有用因为每个矩阵组合携带不同的参数值。参数替换使用标准 Tekton 语法$(params.paramName)支持所有接受字符串值的 Pod 模板字段。例如taskRunSpecs: - pipelineTaskName: build-task podTemplate: nodeSelector: kubernetes.io/arch: $(params.arch) environment: $(params.env) tolerations: - key: workload-type operator: Equal value: $(params.workload) effect: NoSchedule更完整的示例见 pipelineruns.md 中的“Parameter Substitution in taskRunSpecs”。与 Matrix 结合每个组合一个独立 TaskRun当与 Matrix 配合使用时每个矩阵组合都会创建一个独立的TaskRun并将参数值替换进对应的 Pod 模板。例如spec: taskRunSpecs: - pipelineTaskName: build-and-push-manifest podTemplate: nodeSelector: kubernetes.io/arch: $(params.arch) pipelineSpec: tasks: - name: build-and-push-manifest matrix: params: - name: arch value: [amd64, arm64] taskSpec: params: - name: arch steps: - name: build-and-push image: ubuntu script: | echo building on $(params.arch)上述配置中Matrix 会产生两个TaskRun——一个面向amd64、一个面向arm64各自通过替换后的nodeSelector调度到对应架构的节点。完整示例见 examples/v1/pipelineruns/beta/pipelinerun-with-matrix-and-taskrunspecs-param-substitution.yaml。更多细节参见 pipelineruns.md 中的“Matrix Support with taskRunSpecs”。taskRunSpecs 的覆盖语义taskRunSpecs中的podTemplate会覆盖Pipeline 级别的spec.podTemplate配置而 Pipeline 级别的securityContext等字段仍会保留。例如下面的配置中build-task使用任务级podTemplatenodeSelector: disktypessd同时继承 PipelineRun 级securityContextrunAsUser: 1000、runAsGroup: 2000、fsGroup: 3000并拥有 1 小时 30 分钟的超时spec: podTemplate: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 taskRunSpecs: - pipelineTaskName: build-task serviceAccountName: sa-for-build podTemplate: nodeSelector: disktype: ssd timeout: 1h30mv1beta1 中对应字段名为taskServiceAccountName与taskPodTemplate见 pipelineruns.md。支持的字段清单Pod 模板支持下表所列字段各字段的 Kubernetes 语义详见对应链接字段说明envPod 模板中在TaskRun/PipelineRun级别定义的环境变量优先级高于steps与stepTemplate中定义的环境变量nodeSelector必须为 truePod 才能被调度到对应节点参见 Assigning Pods to Nodestolerations允许但不强制Pod 调度到带匹配污点taints的节点上affinity根据节点上的标签约束 Pod 可被调度的节点集合securityContext指定 Pod 级安全属性与通用容器设置如runAsUser与selinuxvolumes指定 Pod 内容器可挂载的卷列表允许你为Task中的每个volumeMount指定卷类型runtimeClassName指定 Pod 的 RuntimeClassautomountServiceAccountToken默认true。决定 Tekton 是否在容器内预定义路径自动挂载 Pod 所用 ServiceAccount 的 tokendnsPolicy默认ClusterFirst。指定 Pod 的 DNS 策略。合法值为ClusterFirst、Default、None。不支持ClusterFirstWithHostNet因为 Tekton Pod 不能使用 host networkingdnsConfig指定 Pod 的 附加 DNS 配置如 nameserver 与 search domainsenableServiceLinks默认true。决定 Pod 所在命名空间中的 Service 是否像 Docker service links 一样以环境变量形式注入 PodpriorityClassName指定 Pod 的 PriorityClass允许你选择性让低优先级工作负载被抢占schedulerName指定调度 Pod 时使用的 调度器。可以为不同类型的工作负载指定不同调度器例如机器学习负载使用volcano.shimagePullSecrets指定拉取私有镜像时使用的 Secret参见 从私有仓库拉取镜像hostNetwork默认false。决定是否使用宿主机网络命名空间hostUsers默认true。决定是否使用宿主的用户命名空间。设为false时为 Pod 创建新的用户命名空间提供更好的安全隔离有助于缓解容器逃逸漏洞。该字段为 alpha 级别需要在 Kubernetes 集群上启用UserNamespacesSupportfeature gateKubernetes 1.25 可用hostAliases向 Pod 的/etc/hosts添加条目提供 Pod 级主机名覆盖参见 Kubernetes 文档topologySpreadConstraints控制 Pod 在集群拓扑域之间的分布方式上述字段在源码pod.Template结构体pkg/apis/pipeline/pod/template.go中都有对应的 Go 字段与 JSON tag如nodeSelector、env、tolerations、affinity、securityContext、volumes、runtimeClassName、automountServiceAccountToken、dnsPolicy、dnsConfig、enableServiceLinks、priorityClassName、schedulerName、imagePullSecrets、hostAliases、hostNetwork、hostUsers、topologySpreadConstraints可供核对字段名与类型。使用 imagePullSecrets 查找入口点entrypoint当Task中没有配置command且podTemplate中配置了imagePullSecrets时Tekton Controller 会使用这些imagePullSecrets去镜像仓库查找镜像的入口点。Tekton Controller 的 ServiceAccount 默认被授予访问 Secret 的权限参见 config/200-clusterrole.yaml。如果你的 Controller ServiceAccount 没有被授予访问其他命名空间下 Secret 的权限需要通过RoleBinding显式授权例如apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: creds-getter namespace: my-ns rules: - apiGroups: [] resources: [secrets] resourceNames: [creds] verbs: [get]apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: creds-getter-binding namespace: my-ns subjects: - kind: ServiceAccount name: tekton-pipelines-controller namespace: tekton-pipelines apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: creds-getter apiGroup: rbac.authorization.k8s.io源码中的调用链这一行为在源码中有完整的调用链在 pkg/pod/pod.go 的第 273283 行构建 Pod 时取出taskRun.Spec.PodTemplate并将其中的ImagePullSecrets传给resolveEntrypoints。resolveEntrypoints定义在 pkg/pod/entrypoint_lookup.go遍历所有 step凡是没有显式command的容器都会通过EntrypointCache.get()查询镜像元数据入口点命令与 digest并传入namespace、serviceAccountName与imagePullSecrets。查询完成后镜像引用会被改写为按 digest 引用的形式steps[i].Image ref.Context().Digest(...)保证可复现性。EntrypointCache的实际实现见 pkg/pod/entrypoint_lookup_impl.go其单元测试在 pkg/pod/entrypoint_lookup_test.go 与 pkg/pod/entrypoint_lookup_impl_test.go。也就是说imagePullSecrets在这一场景下不仅决定 kubelet 拉镜像时的凭据还直接决定了 Controller 能否成功解析镜像入口点——若 Controller 无权读取对应 Secret任务会因 entrypoint 解析失败而无法启动。Affinity Assistant Pod 模板使用 Workspaces 时Tekton 会创建 Affinity Assistant Pod 来协助调度。你在TaskRun和PipelineRun中指定的 Pod 模板同样适用于这些 Affinity Assistant Pod但只作用于部分字段。Affinity Assistant Pod 支持的字段仅限于tolerations、nodeSelector、securityContext、priorityClassName与imagePullSecrets含义见上表。与全局 Pod 模板类似你也可以在 Tekton 配置中通过default-affinity-assistant-pod-template键定义全局 Affinity Assistant Pod 模板见 additional-configs.md其合并策略与上文描述的default-pod-template一致仅针对上述受支持字段。源码层面的对应实现在 pkg/apis/pipeline/pod/template.go 中Template.ToAffinityAssistantTemplate()方法第 168180 行将完整模板裁剪为仅含NodeSelector、Tolerations、ImagePullSecrets、SecurityContext、PriorityClassName的AffinityAssistantTemplate——这正是“只作用于部分字段”的代码级体现。MergeAAPodTemplateWithDefault实现 Affinity Assistant 模板与全局默认模板的合并规则与MergePodTemplateWithDefault相同运行级覆盖全局级。小结与实践建议职责分层把“集群级基线”默认节点选择、默认安全上下文、默认镜像拉取凭据放进config-defaults的default-pod-template把“任务级特例”写在TaskRun/PipelineRun的podTemplate中运行级字段优先。动态调度利用taskRunSpecs$(params.xxx)参数替换配合 Matrix 实现按架构、按环境动态选择节点与容忍度无需为每个组合手写 Pod 模板。安全默认runAsNonRoot、hostUsers: false需集群启用UserNamespacesSupport、显式imagePullSecrets等都是值得优先纳入模板的字段。权限联动若 Task 镜像不带command且依赖私有镜像请确保 Tekton Controller 的 ServiceAccount 具备读取目标命名空间 Secret 的权限否则 entrypoint 解析会失败。如需进一步深入可继续阅读 docs/taskruns.md、docs/pipelineruns.md、docs/additional-configs.md 与 docs/workspaces.md。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐在 Tekton Pipeline 中使用 Windows 节点TaskRun 与 PipelineRun 的跨平台调度指南在 Tekton Pipeline 中使用 Windows 节点TaskRun 与 PipelineRun 的跨平台调度指南 导读 Tekton Pipeli云原生CI/CDDevOps后端Tekton Pipeline Affinity Assistants 完整指南基于 Pod 亲和性实现 PipelineRun 协同调度与共享卷并行Tekton Pipeline Affinity Assistants 完整指南基于 Pod 亲和性实现 PipelineRun 协同调度与共享卷并行 Aff云原生CI/CDDevOps后端Tekton Pipelines核心概念速览Task、Pipeline、TaskRun与PipelineRun一图读懂Tekton Pipelines核心概念速览Task、Pipeline、TaskRun与PipelineRun一图读懂 刚接触 Tekton Pipeline云原生CI/CDDevOps后端上一篇微信聊天记录永久保存指南如何让珍贵对话永不丢失下一篇react-native-router-flux 路由文档未来沉浸式体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
