A Pod template defines a portion of a
configuration that Tekton can use as “boilerplate” for a Pod that runs your
You can specify a Pod template for
PipelineRuns. In the template, you can specify custom values for fields governing
the execution of individual
Tasks or for all
Tasks executed by a given
You also have the option to define a global Pod template in your Tekton config using the key
However, this global template is going to be merged with any templates
you specify in your
PipelineRuns. Any field that is
present in both the global template and the
PipelineRun’s template will be taken from the
See the following for examples of specifying a Pod template:
Affinity Assistant Pod templates
The Pod templates specified in the
PipelineRuns also apply to
the affinity assistant Pods
that are created when using Workspaces, but only on select fields.
The supported fields are:
imagePullSecrets (see the table below for more details).
Similarily to Pod templates, you have the option to define a global affinity
assistant Pod template in your Tekton config
using the key
default-affinity-assistant-pod-template. The merge strategy is
the same as the one described above.
Pod templates support fields listed in the table below.
||Must be true for the Pod to fit on a node.|
||Allows (but does not require) the Pods to schedule onto nodes with matching taints.|
||Allows constraining the set of nodes for which the Pod can be scheduled based on the labels present on the node.|
||Specifies Pod-level security attributes and common container settings such as
||Specifies a list of volumes that containers within the Pod can mount. This allows you to specify a volume type for each
||Specifies the runtime class for the Pod.|
||Specifies additional DNS configuration for the Pod, such as name servers and search domains.|
||Specifies the priority class for the Pod. Allows you to selectively enable preemption on lower-priority workloads.|
||Specifies the scheduler to use when dispatching the Pod. You can specify different schedulers for different types of
workloads, such as
||Specifies the secret to use when pulling a container image.|
||Adds entries to a Pod's `/etc/hosts` to provide Pod-level overrides of hostnames. For further info see [Kubernetes' docs for this field](https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/).|
imagePullSecrets to lookup entrypoint
If no command is configured in
imagePullSecrets is configured in
podTemplate, the Tekton Controller will look up the entrypoint of image with
imagePullSecrets. The Tekton controller’s service account is given access to secrets by default. See this for reference. If the Tekton controller’s service account is not granted the access to secrets in different namespace, you need to grant the access via
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
Was this page helpful?
Thanks! Tell us how we can further improve.
Sorry about that. Tell us how we can further improve.