tekton Compute Resources in Tekton Compute Resources Limits weight 408 Background Resource Requirements in Kubernetes

Answer:
<!--
---
linkTitle: "Compute Resources Limits"
weight: 408
---
-->

# Compute Resources in Tekton

## Background: Resource Requirements in Kubernetes

Kubernetes allows users to specify CPU, memory, and ephemeral storage constraints
for [containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
Resource requests determine the resources reserved for a pod when it's scheduled,
and affect likelihood of pod eviction. Resource limits constrain the maximum amount of
a resource a container can use. A container that exceeds its memory limits will be killed,
and a container that exceeds its CPU limits will be throttled.

A pod's [effective resource requests and limits](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources)
are the higher of:
- the sum of all app containers request/limit for a resource
- the effective init container request/limit for a resource

This formula exists because Kubernetes runs init containers sequentially and app containers
in parallel. (There is no distinction made between app containers and sidecar containers
in Kubernetes; a sidecar is used in the following example to illustrate this.)

For example, consider a pod with the following containers:

| Container           | CPU request | CPU limit |
| ------------------- | ----------- | --------- |
| init container 1    | 1           | 2         |
| init container 2    | 2           | 3         |
| app container 1     | 1           | 2         |
| app container 2     | 2           | 3         |
| sidecar container 1 | 3           | no limit  |

The sum of all app container CPU requests is 6 (including the sidecar container), which is
greater than the maximum init container CPU request (2). Therefore, the pod's effective CPU
request will be 6.

Since the sidecar container has no CPU limit, this is treated as the highest CPU limit.
Therefore, the pod will have no effective CPU limit.

## Task-level Compute Resources Configuration

**([beta](https://github.com/tektoncd/pipeline/blob/main/docs/additional-configs.md#beta-features))**

Tekton allows users to specify resource requirements of [`Steps`](./tasks.md#defining-steps),
which run sequentially. However, the pod's effective resource requirements are still the
sum of its containers' resource requirements. This means that when specifying resource
requirements for `Step` containers, they must be treated as if they are running in parallel.

Tekton adjusts `Step` resource requirements to comply with [LimitRanges](#limitrange-support).
[ResourceQuotas](#resourcequota-support) are not currently supported.

Instead of specifying resource requirements on each `Step`, users can choose to specify resource requirements at the Task-level. If users specify a Task-level resource request, it will ensure that the kubelet reserves only that amount of resources to execute the `Task`'s `Steps`.
If users specify a Task-level resource limit, no `Step` may use more than that amount of resources.

Each of these details is explained in more depth below.

Some points to note:

- Task-level resource requests and limits do not apply to sidecars which can be configured separately.
- If only limits are configured in task-level, it will be applied as the task-level requests.
- Resource requirements configured in `Step` or `StepTemplate` of the referenced `Task` will be overridden by the task-level requirements.
- `TaskRun` configured with both `StepOverrides` and task-level requirements will be rejected.

### Configure Task-level Compute Resources

Task-level resource requirements can be configured in `TaskRun.ComputeResources`, or `PipelineRun.TaskRunSpecs.ComputeResources`.

e.g.

```yaml
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: foo
spec:
  computeResources:
    requests:
      cpu: 1
    limits:
      cpu: 2
```

The following TaskRun will be rejected, because it configures both stepOverrides and task-level compute resource requirements:

```yaml
kind: TaskRun
spec:
  stepOverrides:
    - name: foo
      resources:
        requests:
          cpu: 1
  computeResources:
    requests:
      cpu: 2
```

```yaml
kind: PipelineRun
spec:
  taskRunSpecs:
    - pipelineTaskName: foo
      stepOverrides:
        - name: foo
          resources:
            requests:
              cpu: 1
      computeResources:
        requests:
          cpu: 2
```

### Configure Resource Requirements with Sidecar

Users can specify compute resources separately for a sidecar while configuring task-level resource requirements on TaskRun.

e.g.

```yaml
kind: TaskRun
spec:
  sidecarOverrides:
    - name: sidecar
      resources:
        requests:
          cpu: 750m
        limits:
          cpu: 1
  computeResources:
    requests:
      cpu: 2
```

## LimitRange Support

Kubernetes allows users to configure [LimitRanges]((https://kubernetes.io/docs/concepts/policy/limit-range/)),
which constrain compute resources of pods, containers, or PVCs running in the same namespace.

LimitRanges can:
- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace.
- Enforce a ratio between request and limit for a resource in a namespace.
- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.

Tekton applies the resource requirements specified by users directly to the containers
in a `Task's` pod, unless there is a LimitRange present in the namespace.
Tekton supports LimitRange minimum, maximum, and default resource requirements for containers,
but does not support LimitRange ratios between requests and limits ([#4230](https://github.com/tektoncd/pipeline/issues/4230)).
LimitRange types other than "Container" are not considered for purposes of resource requirements.

Tekton doesn't allow users to configure init containers for a `Task`, but any `default` and `defaultRequest` from a LimitRange
will be applied to the init containers that Tekton injects into a `TaskRun`'s pod.

### Requests

If a Step container does not have requests defined, Tekton will divide a LimitRange's `defaultRequests` by the number of Step containers and apply these requests to the Steps.
This results in a TaskRun with overall requests equal to LimitRange `defaultRequests`.
If this value is less than the LimitRange minimum, the LimitRange minimum will be used instead.
LimitRange `defaultRequests` are applied as-is to init containers or Sidecar containers that don't specify requests.

Containers that do specify requests will not be modified. If these requests are lower than LimitRange minimums, Kubernetes will reject the resulting TaskRun's pod.

### Limits

Tekton does not adjust container limits, regardless of whether a container is a Step, Sidecar, or init container.
If a container does not have limits defined, Kubernetes will apply the LimitRange `default` to the container's limits.
If a container does define limits, and they are less than the LimitRange `default`, Kubernetes will reject the resulting TaskRun's pod.

### Examples

Consider the following LimitRange:

```
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-example
spec:
  limits:
  - default:  # The default limits
      cpu: 2
    defaultRequest:  # The default requests
      cpu: 1
    max:  # The maximum limits
      cpu: 3
    min:  # The minimum requests
      cpu: 300m
    type: Container
```

A `Task` with 2 `Steps` and no resources specified would result in a pod with the following containers:

| Container    | CPU request | CPU limit |
| ------------ | ----------- | --------- |
| container 1  | 500m        | 2         |
| container 2  | 500m        | 2         |

Here, the default CPU request was divided among the step containers, and this value was used since it was greater
than the minimum request specified by the LimitRange.
The CPU limits are 2 for each container, as this is the default limit specifed in the LimitRange.

If we had a `Task` with 2 `Steps` and 1 `Sidecar` with no resources specified would result in a pod with the following containers:

| Container    | CPU request | CPU limit |
| ------------ | ----------- | --------- |
| container 1  | 500m        | 2         |
| container 2  | 500m        | 2         |
| container 3  | 1           | 2         |

For the first two containers, the default CPU request was divided among the step containers, and this value was used since it was greater
than the minimum request specified by the LimitRange. The third container is a sidecar and since it is not a step container gets the full
default CPU request of 1. AS before the CPU limits are 2 for each container, as this is the default limit specifed in the LimitRange.

Now, consider a `Task` with the following `Step`s:

| Step   | CPU request | CPU limit |
| ------ | ----------- | --------- |
| step 1 | 200m        | 2         |
| step 2 | 1           | 4         |

The resulting pod would have the following containers:

| Container    | CPU request | CPU limit |
| ------------ | ----------- | --------- |
| container 1  | 300m        | 2         |
| container 2  | 1           | 3         |

Here, the first `Step's` request was less than the LimitRange minimum, so the output request is the minimum (300m).
The second `Step's` request is unchanged. The first `Step's` limit is less than the maximum, so it is unchanged,
while the second `Step's` limit is greater than the maximum, so the maximum (3) is used.

### Support for multiple LimitRanges

Tekton supports running `TaskRuns` in namespaces with multiple LimitRanges.
For a given resource, the minumum used will be the largest of any of the LimitRanges' minimum values,
and the maximum used will be the smallest of any of the LimitRanges' maximum values.

The minimum resource requirement used will be the largest of any minimum for that resource,
and the maximum resource requirement will be the smallest of any of the maximum values defined.
The default value will be the minimum of any default values defined.
If the resulting default value is less than the resulting minimum value, the default value will be the minimum value.

It's possible for multiple LimitRanges to be defined which are not compatible with each other, preventing pods from being scheduled.

#### Example

Consider a namespaces with the following LimitRanges defined:

```
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-1
spec:
  limits:
  - default:  # The default limits
      cpu: 2
    defaultRequest:  # The default requests
      cpu: 750m
    max:  # The maximum limits
      cpu: 3
    min:  # The minimum requests
      cpu: 500m
    type: Container
```

```
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-2
spec:
  limits:
  - default:  # The default limits
      cpu: 1.5
    defaultRequest:  # The default requests
      cpu: 1
    max:  # The maximum limits
      cpu: 2.5
    min:  # The minimum requests
      cpu: 300m
    type: Container
```

A namespace with limitrange-1 and limitrange-2 would be treated as if it contained only the following LimitRange:

```
apiVersion: v1
kind: LimitRange
metadata:
  name: aggregate-limitrange
spec:
  limits:
  - default:  # The default limits
      cpu: 1.5
    defaultRequest:  # The default requests
      cpu: 750m
    max:  # The maximum limits
      cpu: 2.5
    min:  # The minimum requests
      cpu: 300m
    type: Container
```

Here, the minimum of the "max" values is the output "max" value, and likewise for "default" and "defaultRequest".
The maximum of the "min" values is the output "min" value.

## ResourceQuota Support

Kubernetes allows users to define [ResourceQuotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/),
which restrict the maximum resource requests and limits of all pods running in a namespace.

To deploy Tekton TaskRuns or PipelineRuns in namespaces with ResourceQuotas, compute resource requirements
must be set for all containers in a `TaskRun`'s pod, including the init containers injected by Tekton.
`Step` and `Sidecar` resource requirements can be configured directly through the API, as described in
[Task Resource Requirements](#task-resource-requirements). To configure resource requirements for Tekton's init containers,
deploy a LimitRange in the same namespace. The LimitRange's `default` and `defaultRequest` will be applied to the init containers,
and divided among the `Steps` and `Sidecars`, as described in [LimitRange Support](#limitrange-support).

[#2933](https://github.com/tektoncd/pipeline/issues/2933) tracks support for running `TaskRuns` in a namespace with a ResourceQuota
without having to use LimitRanges.

ResourceQuotas consider the effective resource requests and limits of a pod, which Kubernetes determines by summing the resource requirements
of its containers (under the assumption that they run in parallel). When using LimitRanges to set compute resources for `TaskRun` pods,
LimitRange default requests are divided among `Step` containers, meaning that the pod's effective requests reflect the actual requests
that the pod needs. However, LimitRange default limits are not divided among containers, meaning the pod's effective limits are much larger
than the limits applied during execution of any given `Step`. For example, if a ResourceQuota restricts a namespace to a limit of 10 CPU,
and a user creates a TaskRun with 20 steps with a limit of 1 CPU each, the pod would not be schedulable even though it is
limited to 1 CPU at each point in time. Therefore, it is recommended to use ResourceQuotas to restrict only requests of `TaskRun` pods,
not limits (tracked in [#4976](https://github.com/tektoncd/pipeline/issues/4976)).

## Quality of Service (QoS)

By default, pods that run Tekton TaskRuns will have a [Quality of Service (QoS)](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)
of "BestEffort". If compute resource requirements are set for any Step or Sidecar, the pod will have a "Burstable" QoS.
To get a "Guaranteed" QoS, a TaskRun pod must have compute resources set for all of its containers, including init containers which are
injected by Tekton, and all containers must have their requests equal to their limits.
This can be achieved by using LimitRanges to apply default requests and limits.

# References

- [LimitRange in k8s docs](https://kubernetes.io/docs/concepts/policy/limit-range/)
- [Configure default memory requests and limits for a Namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
- [Configure default CPU requests and limits for a Namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
- [Configure Minimum and Maximum CPU constraints for a Namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
- [Configure Minimum and Maximum Memory constraints for a Namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
- [Managing Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)
- [Kubernetes best practices: Resource requests and limits](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits)
- [Restrict resource consumption with limit ranges](https://docs.openshift.com/container-platform/4.8/nodes/clusters/nodes-cluster-limit-ranges.html)

linkTitle   Compute Resources Limits  weight  408            Compute Resources in Tekton     Background  Resource Requirements in Kubernetes  Kubernetes allows users to specify CPU  memory  and ephemeral storage constraints for  containers  https   kubernetes io docs concepts configuration manage resources containers    Resource requests determine the resources reserved for a pod when it s scheduled  and affect likelihood of pod eviction  Resource limits constrain the maximum amount of a resource a container can use  A container that exceeds its memory limits will be killed  and a container that exceeds its CPU limits will be throttled   A pod s  effective resource requests and limits  https   kubernetes io docs concepts workloads pods init containers  resources  are the higher of    the sum of all app containers request limit for a resource   the effective init container request limit for a resource  This formula exists because Kubernetes runs init containers sequentially and app containers in parallel   There is no distinction made between app containers and sidecar containers in Kubernetes  a sidecar is used in the following example to illustrate this    For example  consider a pod with the following containers     Container             CPU request   CPU limit                                                       init container 1      1             2             init container 2      2             3             app container 1       1             2             app container 2       2             3             sidecar container 1   3             no limit     The sum of all app container CPU requests is 6  including the sidecar container   which is greater than the maximum init container CPU request  2   Therefore  the pod s effective CPU request will be 6   Since the sidecar container has no CPU limit  this is treated as the highest CPU limit  Therefore  the pod will have no effective CPU limit      Task level Compute Resources Configuration      beta  https   github com tektoncd pipeline blob main docs additional configs md beta features      Tekton allows users to specify resource requirements of   Steps     tasks md defining steps   which run sequentially  However  the pod s effective resource requirements are still the sum of its containers  resource requirements  This means that when specifying resource  requirements for  Step  containers  they must be treated as if they are running in parallel   Tekton adjusts  Step  resource requirements to comply with  LimitRanges   limitrange support    ResourceQuotas   resourcequota support  are not currently supported   Instead of specifying resource requirements on each  Step   users can choose to specify resource requirements at the Task level  If users specify a Task level resource request  it will ensure that the kubelet reserves only that amount of resources to execute the  Task  s  Steps   If users specify a Task level resource limit  no  Step  may use more than that amount of resources   Each of these details is explained in more depth below   Some points to note     Task level resource requests and limits do not apply to sidecars which can be configured separately    If only limits are configured in task level  it will be applied as the task level requests    Resource requirements configured in  Step  or  StepTemplate  of the referenced  Task  will be overridden by the task level requirements     TaskRun  configured with both  StepOverrides  and task level requirements will be rejected       Configure Task level Compute Resources  Task level resource requirements can be configured in  TaskRun ComputeResources   or  PipelineRun TaskRunSpecs ComputeResources    e g      yaml apiVersion  tekton dev v1beta1 kind  TaskRun metadata    name  foo  spec    computeResources      requests        cpu  1      limits        cpu  2      The following TaskRun will be rejected  because it configures both stepOverrides and task level compute resource requirements      yaml kind  TaskRun spec    stepOverrides        name  foo       resources          requests            cpu  1   computeResources      requests        cpu  2          yaml kind  PipelineRun spec    taskRunSpecs        pipelineTaskName  foo       stepOverrides            name  foo            resources              requests                cpu  1        computeResources          requests            cpu  2          Configure Resource Requirements with Sidecar  Users can specify compute resources separately for a sidecar while configuring task level resource requirements on TaskRun   e g      yaml kind  TaskRun spec    sidecarOverrides        name  sidecar       resources          requests            cpu  750m         limits            cpu  1   computeResources      requests        cpu  2         LimitRange Support  Kubernetes allows users to configure  LimitRanges   https   kubernetes io docs concepts policy limit range     which constrain compute resources of pods  containers  or PVCs running in the same namespace   LimitRanges can    Enforce minimum and maximum compute resources usage per Pod or Container in a namespace    Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace    Enforce a ratio between request and limit for a resource in a namespace    Set default request limit for compute resources in a namespace and automatically inject them to Containers at runtime   Tekton applies the resource requirements specified by users directly to the containers in a  Task s  pod  unless there is a LimitRange present in the namespace  Tekton supports LimitRange minimum  maximum  and default resource requirements for containers  but does not support LimitRange ratios between requests and limits    4230  https   github com tektoncd pipeline issues 4230    LimitRange types other than  Container  are not considered for purposes of resource requirements   Tekton doesn t allow users to configure init containers for a  Task   but any  default  and  defaultRequest  from a LimitRange will be applied to the init containers that Tekton injects into a  TaskRun  s pod       Requests  If a Step container does not have requests defined  Tekton will divide a LimitRange s  defaultRequests  by the number of Step containers and apply these requests to the Steps  This results in a TaskRun with overall requests equal to LimitRange  defaultRequests   If this value is less than the LimitRange minimum  the LimitRange minimum will be used instead  LimitRange  defaultRequests  are applied as is to init containers or Sidecar containers that don t specify requests   Containers that do specify requests will not be modified  If these requests are lower than LimitRange minimums  Kubernetes will reject the resulting TaskRun s pod       Limits  Tekton does not adjust container limits  regardless of whether a container is a Step  Sidecar  or init container  If a container does not have limits defined  Kubernetes will apply the LimitRange  default  to the container s limits  If a container does define limits  and they are less than the LimitRange  default   Kubernetes will reject the resulting TaskRun s pod       Examples  Consider the following LimitRange       apiVersion  v1 kind  LimitRange metadata    name  limitrange example spec    limits      default     The default limits       cpu  2     defaultRequest     The default requests       cpu  1     max     The maximum limits       cpu  3     min     The minimum requests       cpu  300m     type  Container      A  Task  with 2  Steps  and no resources specified would result in a pod with the following containers     Container      CPU request   CPU limit                                                container 1    500m          2              container 2    500m          2            Here  the default CPU request was divided among the step containers  and this value was used since it was greater than the minimum request specified by the LimitRange  The CPU limits are 2 for each container  as this is the default limit specifed in the LimitRange   If we had a  Task  with 2  Steps  and 1  Sidecar  with no resources specified would result in a pod with the following containers       Container      CPU request   CPU limit                                                container 1    500m          2             container 2    500m          2             container 3    1             2            For the first two containers  the default CPU request was divided among the step containers  and this value was used since it was greater than the minimum request specified by the LimitRange  The third container is a sidecar and since it is not a step container gets the full  default CPU request of 1  AS before the CPU limits are 2 for each container  as this is the default limit specifed in the LimitRange    Now  consider a  Task  with the following  Step s     Step     CPU request   CPU limit                                          step 1   200m          2             step 2   1             4            The resulting pod would have the following containers     Container      CPU request   CPU limit                                                container 1    300m          2             container 2    1             3            Here  the first  Step s  request was less than the LimitRange minimum  so the output request is the minimum  300m   The second  Step s  request is unchanged  The first  Step s  limit is less than the maximum  so it is unchanged  while the second  Step s  limit is greater than the maximum  so the maximum  3  is used       Support for multiple LimitRanges  Tekton supports running  TaskRuns  in namespaces with multiple LimitRanges  For a given resource  the minumum used will be the largest of any of the LimitRanges  minimum values  and the maximum used will be the smallest of any of the LimitRanges  maximum values   The minimum resource requirement used will be the largest of any minimum for that resource  and the maximum resource requirement will be the smallest of any of the maximum values defined  The default value will be the minimum of any default values defined  If the resulting default value is less than the resulting minimum value  the default value will be the minimum value   It s possible for multiple LimitRanges to be defined which are not compatible with each other  preventing pods from being scheduled        Example  Consider a namespaces with the following LimitRanges defined       apiVersion  v1 kind  LimitRange metadata    name  limitrange 1 spec    limits      default     The default limits       cpu  2     defaultRequest     The default requests       cpu  750m     max     The maximum limits       cpu  3     min     The minimum requests       cpu  500m     type  Container          apiVersion  v1 kind  LimitRange metadata    name  limitrange 2 spec    limits      default     The default limits       cpu  1 5     defaultRequest     The default requests       cpu  1     max     The maximum limits       cpu  2 5     min     The minimum requests       cpu  300m     type  Container      A namespace with limitrange 1 and limitrange 2 would be treated as if it contained only the following LimitRange       apiVersion  v1 kind  LimitRange metadata    name  aggregate limitrange spec    limits      default     The default limits       cpu  1 5     defaultRequest     The default requests       cpu  750m     max     The maximum limits       cpu  2 5     min     The minimum requests       cpu  300m     type  Container      Here  the minimum of the  max  values is the output  max  value  and likewise for  default  and  defaultRequest   The maximum of the  min  values is the output  min  value      ResourceQuota Support  Kubernetes allows users to define  ResourceQuotas  https   kubernetes io docs concepts policy resource quotas    which restrict the maximum resource requests and limits of all pods running in a namespace   To deploy Tekton TaskRuns or PipelineRuns in namespaces with ResourceQuotas  compute resource requirements must be set for all containers in a  TaskRun  s pod  including the init containers injected by Tekton   Step  and  Sidecar  resource requirements can be configured directly through the API  as described in  Task Resource Requirements   task resource requirements   To configure resource requirements for Tekton s init containers  deploy a LimitRange in the same namespace  The LimitRange s  default  and  defaultRequest  will be applied to the init containers  and divided among the  Steps  and  Sidecars   as described in  LimitRange Support   limitrange support      2933  https   github com tektoncd pipeline issues 2933  tracks support for running  TaskRuns  in a namespace with a ResourceQuota without having to use LimitRanges   ResourceQuotas consider the effective resource requests and limits of a pod  which Kubernetes determines by summing the resource requirements of its containers  under the assumption that they run in parallel   When using LimitRanges to set compute resources for  TaskRun  pods  LimitRange default requests are divided among  Step  containers  meaning that the pod s effective requests reflect the actual requests that the pod needs  However  LimitRange default limits are not divided among containers  meaning the pod s effective limits are much larger than the limits applied during execution of any given  Step   For example  if a ResourceQuota restricts a namespace to a limit of 10 CPU  and a user creates a TaskRun with 20 steps with a limit of 1 CPU each  the pod would not be schedulable even though it is limited to 1 CPU at each point in time  Therefore  it is recommended to use ResourceQuotas to restrict only requests of  TaskRun  pods  not limits  tracked in   4976  https   github com tektoncd pipeline issues 4976         Quality of Service  QoS   By default  pods that run Tekton TaskRuns will have a  Quality of Service  QoS   https   kubernetes io docs tasks configure pod container quality service pod   of  BestEffort   If compute resource requirements are set for any Step or Sidecar  the pod will have a  Burstable  QoS  To get a  Guaranteed  QoS  a TaskRun pod must have compute resources set for all of its containers  including init containers which are injected by Tekton  and all containers must have their requests equal to their limits  This can be achieved by using LimitRanges to apply default requests and limits     References     LimitRange in k8s docs  https   kubernetes io docs concepts policy limit range      Configure default memory requests and limits for a Namespace  https   kubernetes io docs tasks administer cluster manage resources memory default namespace      Configure default CPU requests and limits for a Namespace  https   kubernetes io docs tasks administer cluster manage resources cpu default namespace      Configure Minimum and Maximum CPU constraints for a Namespace  https   kubernetes io docs tasks administer cluster manage resources cpu constraint namespace      Configure Minimum and Maximum Memory constraints for a Namespace  https   kubernetes io docs tasks administer cluster manage resources memory constraint namespace      Managing Resources for Containers  https   kubernetes io docs concepts configuration manage resources containers      Kubernetes best practices  Resource requests and limits  https   cloud google com blog products containers kubernetes kubernetes best practices resource requests and limits     Restrict resource consumption with limit ranges  https   docs openshift com container platform 4 8 nodes clusters nodes cluster limit ranges html


tekton Pod templates A Pod template defines a portion of a weight 409 Pod templates

Answer:
# Pod templates

A Pod template defines a portion of a [`PodSpec`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#pod-v1-core)
configuration that Tekton can use as "boilerplate" for a Pod that runs your `Tasks` and `Pipelines`.

You can specify a Pod template for `TaskRuns` and `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 `PipelineRun`.

You also have the option to define a global Pod template [in your Tekton config](./additional-configs.md#customizing-basic-execution-parameters) using the key `default-pod-template`.
However, this global template is going to be merged with any templates you specify in your `TaskRuns` and `PipelineRuns`.

Except for the `env` and `volumes` fields, other fields that exist in both the global template and the `TaskRun`'s or
`PipelineRun`'s template will be taken from the `TaskRun` or `PipelineRun`.
The `env` and `volumes` fields are merged by the `name` value in the array elements. If the item's `name` is the same, the item from `TaskRun` or `PipelineRun` will be used.

See the following for examples of specifying a Pod template:
- [Specifying a Pod template for a `TaskRun`](./taskruns.md#specifying-a-pod-template)
- [Specifying a Pod template for a `PipelineRun`](./pipelineruns.md#specifying-a-pod-template)

## Supported fields

Pod templates support fields listed in the table below.

		Field
		Description

			env
			Environment variables defined in the Pod template at TaskRun and PipelineRun level take precedence over the ones defined in steps and stepTemplate

			nodeSelector
			Must be true for the Pod to fit on a node.

			tolerations
			Allows (but does not require) the Pods to schedule onto nodes with matching taints.

			affinity
			Allows constraining the set of nodes for which the Pod can be scheduled based on the labels present on the node.

			securityContext
			Specifies Pod-level security attributes and common container settings such as runAsUser and selinux.

			volumes
			Specifies a list of volumes that containers within the Pod can mount. This allows you to specify a volume type for each volumeMount in a Task.

			runtimeClassName
			Specifies the runtime class for the Pod.

			automountServiceAccountToken
			Default: true. Determines whether Tekton automatically provides the token for the service account used by the Pod inside containers at a predefined path.

			dnsPolicy
			Default: ClusterFirst. Specifies the DNS policy
                for the Pod. Legal values are ClusterFirst, Default, and None. Does not support ClusterFirstWithHostNet
                because Tekton Pods cannot run with host networking.

			dnsConfig
			Specifies additional DNS configuration for the Pod, such as name servers and search domains.

			enableServiceLinks
			Default: true. Determines whether services in the Pod's namespace are exposed as environment variables to the Pod, similarly to Docker service links.

			priorityClassName
			Specifies the priority class for the Pod. Allows you to selectively enable preemption on lower-priority workloads.

			schedulerName
			Specifies the scheduler to use when dispatching the Pod. You can specify different schedulers for different types of
                workloads, such as volcano.sh for machine learning workloads.

			imagePullSecrets
			Specifies the secret to use when
                pulling a container image.

			hostNetwork
			Default: false. Determines whether to use the host network namespace.

			hostAliases
			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/).

            topologySpreadConstraints
            Specify how Pods are spread across your cluster among topology domains.

## Use `imagePullSecrets` to lookup entrypoint

If no command is configured in `task` and `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](https://github.com/tektoncd/pipeline/blob/main/config/200-clusterrole.yaml) 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 `RoleBinding`:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: creds-getter
  namespace: my-ns
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["creds"]
  verbs: ["get"]
```

```yaml
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
```

# Affinity Assistant Pod templates

The Pod templates specified in the `TaskRuns` and `PipelineRuns `also apply to
the [affinity assistant Pods](#./workspaces.md#specifying-workspace-order-in-a-pipeline-and-affinity-assistants)
that are created when using Workspaces, but only on selected fields.

The supported fields for affinity assistant pods are: `tolerations`, `nodeSelector`, `securityContext`,
`priorityClassName` and `imagePullSecrets` (see the table above for more details about the fields).

Similarly to global Pod Template, you have the option to define a global affinity
assistant Pod template [in your Tekton config](./additional-configs.md#customizing-basic-execution-parameters)
using the key `default-affinity-assistant-pod-template`. The merge strategy is
the same as the one described above for the supported fields.

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

linkTitle   Pod templates  weight  409            Pod templates  A Pod template defines a portion of a   PodSpec   https   kubernetes io docs reference generated kubernetes api v1 18  pod v1 core  configuration that Tekton can use as  boilerplate  for a Pod that runs your  Tasks  and  Pipelines    You can specify a Pod template for  TaskRuns  and  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  PipelineRun    You also have the option to define a global Pod template  in your Tekton config    additional configs md customizing basic execution parameters  using the key  default pod template   However  this global template is going to be merged with any templates you specify in your  TaskRuns  and  PipelineRuns   br  Except for the  env  and  volumes  fields  other fields that exist in both the global template and the  TaskRun  s or  PipelineRun  s template will be taken from the  TaskRun  or  PipelineRun   The  env  and  volumes  fields are merged by the  name  value in the array elements  If the item s  name  is the same  the item from  TaskRun  or  PipelineRun  will be used   See the following for examples of specifying a Pod template     Specifying a Pod template for a  TaskRun     taskruns md specifying a pod template     Specifying a Pod template for a  PipelineRun     pipelineruns md specifying a pod template      Supported fields  Pod templates support fields listed in the table below    table    thead     th Field  th     th Description  th     thead    tbody     tr      td  code env  code   td      td Environment variables defined in the Pod template at  code TaskRun  code  and  code PipelineRun  code  level take precedence over the ones defined in  code steps  code  and  code stepTemplate  code   td      tr     tr      td  code nodeSelector  code   td      td Must be true for  a href https   kubernetes io docs concepts configuration assign pod node  the Pod to fit on a node  a    td      tr     tr      td  code tolerations  code   td      td Allows  but does not require  the Pods to schedule onto nodes with matching taints   td      tr     tr      td  code affinity  code   td      td Allows constraining the set of nodes for which the Pod can be scheduled based on the labels present on the node   td      tr     tr      td  code securityContext  code   td      td Specifies Pod level security attributes and common container settings such as  code runAsUser  code  and  code selinux  code    td      tr     tr      td  code volumes  code   td      td Specifies a list of volumes that containers within the Pod can mount  This allows you to specify a volume type for each  code volumeMount  code  in a  code Task  code    td      tr     tr      td  code runtimeClassName  code   td      td Specifies the  a href https   kubernetes io docs concepts containers runtime class  runtime class  a  for the Pod   td      tr     tr      td  code automountServiceAccountToken  code   td      td  b Default   b   code true  code   Determines whether Tekton automatically provides the token for the service account used by the Pod inside containers at a predefined path   td      tr     tr      td  code dnsPolicy  code   td      td  b Default   b   code ClusterFirst  code   Specifies the  a href https   kubernetes io docs concepts services networking dns pod service  pod s dns policy DNS policy  a                  for the Pod  Legal values are  code ClusterFirst  code    code Default  code   and  code None  code   Does  b not  b  support  code ClusterFirstWithHostNet  code                  because Tekton Pods cannot run with host networking   td      tr     tr      td  code dnsConfig  code   td      td Specifies  a href https   kubernetes io docs concepts services networking dns pod service  pod s dns config additional DNS configuration for the Pod  a   such as name servers and search domains   td      tr     tr      td  code enableServiceLinks  code   td      td  b Default   b   code true  code   Determines whether services in the Pod s namespace are exposed as environment variables to the Pod  similarly to Docker service links   td      tr     tr      td  code priorityClassName  code   td      td Specifies the  a href https   kubernetes io docs concepts configuration pod priority preemption  priority class  a  for the Pod  Allows you to selectively enable preemption on lower priority workloads   td      tr     tr      td  code schedulerName  code   td      td Specifies the  a href https   kubernetes io docs tasks administer cluster configure multiple schedulers  scheduler  a  to use when dispatching the Pod  You can specify different schedulers for different types of                 workloads  such as  code volcano sh  code  for machine learning workloads   td      tr     tr      td  code imagePullSecrets  code   td      td Specifies the  a href https   kubernetes io docs concepts configuration secret  secret  a  to use when  a href https   kubernetes io docs tasks configure pod container pull image private registry                   pulling a container image  a    td      tr     tr      td  code hostNetwork  code   td      td  b Default   b   code false  code   Determines whether to use the host network namespace   td      tr     tr      td  code hostAliases  code   td      td 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     td      tr           tr               td  code topologySpreadConstraints  code   td               td Specify how Pods are spread across your cluster among topology domains   td            tr     tbody    table      Use  imagePullSecrets  to lookup entrypoint  If no command is configured in  task  and  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  https   github com tektoncd pipeline blob main config 200 clusterrole yaml  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  RoleBinding       yaml apiVersion  rbac authorization k8s io v1 kind  Role metadata    name  creds getter   namespace  my ns rules    apiGroups         resources    secrets     resourceNames    creds     verbs    get           yaml 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        Affinity Assistant Pod templates  The Pod templates specified in the  TaskRuns  and  PipelineRuns  also apply to the  affinity assistant Pods     workspaces md specifying workspace order in a pipeline and affinity assistants  that are created when using Workspaces  but only on selected fields   The supported fields for affinity assistant pods are   tolerations    nodeSelector    securityContext     priorityClassName  and  imagePullSecrets   see the table above for more details about the fields    Similarly to global Pod Template  you have the option to define a global affinity assistant Pod template  in your Tekton config    additional configs md customizing basic execution parameters  using the key  default affinity assistant pod template   The merge strategy is the same as the one described above for the supported fields        Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  https   creativecommons org licenses by 4 0    and code samples are licensed under the  Apache 2 0 License  https   www apache org licenses LICENSE 2 0


tekton Resolver Type weight 308 Bundles Resolver Bundles Resolver

Answer:
<!--
---
linkTitle: "Bundles Resolver"
weight: 308
---
-->

# Bundles Resolver

## Resolver Type

This Resolver responds to type `bundles`.

## Parameters

| Param Name       | Description                                                                   | Example Value                                              |
|------------------|-------------------------------------------------------------------------------|------------------------------------------------------------|
| `secret` | The name of the secret to use when constructing registry credentials | `default`                                                  |
| `bundle`         | The bundle url pointing at the image to fetch                                 | `gcr.io/tekton-releases/catalog/upstream/golang-build:0.1` |
| `name`           | The name of the resource to pull out of the bundle                            | `golang-build`                                             |
| `kind`           | The resource kind to pull out of the bundle                                   | `task`                                                     |

## Requirements

- A cluster running Tekton Pipeline v0.41.0 or later.
- The [built-in remote resolvers installed](./install.md#installing-and-configuring-remote-task-and-pipeline-resolution).
- The `enable-bundles-resolver` feature flag in the `resolvers-feature-flags` ConfigMap
  in the `tekton-pipelines-resolvers` namespace set to `true`.
- [Beta features](./additional-configs.md#beta-features) enabled.

## Configuration

This resolver uses a `ConfigMap` for its settings. See
[`../config/resolvers/bundleresolver-config.yaml`](../config/resolvers/bundleresolver-config.yaml)
for the name, namespace and defaults that the resolver ships with.

### Options

| Option Name               | Description                                                  | Example Values        |
|---------------------------|--------------------------------------------------------------|-----------------------|
| `default-kind`            | The default layer kind in the bundle image.                  | `task`, `pipeline`    |

## Usage

### Task Resolution

```yaml
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: remote-task-reference
spec:
  taskRef:
    resolver: bundles
    params:
    - name: bundle
      value: docker.io/ptasci67/example-oci@sha256:053a6cb9f3711d4527dd0d37ac610e8727ec0288a898d5dfbd79b25bcaa29828
    - name: name
      value: hello-world
    - name: kind
      value: task
```

### Pipeline Resolution

Unfortunately the Tekton Catalog does not publish pipelines at the
moment. Here's an example PipelineRun that talks to a private registry
but won't work unless you tweak the `bundle` field to point to a
registry with a pipeline in it:

```yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: bundle-demo
spec:
  pipelineRef:
    resolver: bundles
    params:
    - name: bundle
      value: 10.96.190.208:5000/simple/pipeline:latest
    - name: name
      value: hello-pipeline
    - name: kind
      value: pipeline
  params:
  - name: username
    value: "tekton pipelines"
```

## `ResolutionRequest` Status
`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
- `uri`: The image repository URI
- `digest`: The map of the algorithm portion -> the hex encoded portion of the image digest.
- `entrypoint`: The resource name in the OCI bundle image.

Example:
- TaskRun Resolution
```yaml
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: remote-task-reference
spec:
  taskRef:
    resolver: bundles
    params:
    - name: bundle
      value: gcr.io/tekton-releases/catalog/upstream/git-clone:0.7
    - name: name
      value: git-clone
    - name: kind
      value: task
  params:
    - name: url
      value: https://github.com/octocat/Hello-World
  workspaces:
    - name: output
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 500Mi
```

- `ResolutionRequest`
```yaml
apiVersion: resolution.tekton.dev/v1beta1
kind: ResolutionRequest
metadata:
  ...
  labels:
    resolution.tekton.dev/type: bundles
  name: bundles-21ad80ec13f3e8b73fed5880a64d4611
  ...
spec:
  params:
  - name: bundle
    value: gcr.io/tekton-releases/catalog/upstream/git-clone:0.7
  - name: name
    value: git-clone
  - name: kind
    value: task
status:
  annotations: ...
  ...
  data: xxx
  observedGeneration: 1
  refSource:
    digest:
      sha256: f51ca50f1c065acba8290ef14adec8461915ecc5f70a8eb26190c6e8e0ededaf
    entryPoint: git-clone
    uri: gcr.io/tekton-releases/catalog/upstream/git-clone
```

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

linkTitle   Bundles Resolver  weight  308            Bundles Resolver     Resolver Type  This Resolver responds to type  bundles       Parameters    Param Name         Description                                                                     Example Value                                                                                secret    The name of the secret to use when constructing registry credentials    default                                                        bundle            The bundle url pointing at the image to fetch                                    gcr io tekton releases catalog upstream golang build 0 1       name              The name of the resource to pull out of the bundle                               golang build                                                   kind              The resource kind to pull out of the bundle                                      task                                                            Requirements    A cluster running Tekton Pipeline v0 41 0 or later    The  built in remote resolvers installed    install md installing and configuring remote task and pipeline resolution     The  enable bundles resolver  feature flag in the  resolvers feature flags  ConfigMap   in the  tekton pipelines resolvers  namespace set to  true      Beta features    additional configs md beta features  enabled      Configuration  This resolver uses a  ConfigMap  for its settings  See      config resolvers bundleresolver config yaml      config resolvers bundleresolver config yaml  for the name  namespace and defaults that the resolver ships with       Options    Option Name                 Description                                                    Example Values                                                                                default kind               The default layer kind in the bundle image                      task    pipeline           Usage      Task Resolution     yaml apiVersion  tekton dev v1beta1 kind  TaskRun metadata    name  remote task reference spec    taskRef      resolver  bundles     params        name  bundle       value  docker io ptasci67 example oci sha256 053a6cb9f3711d4527dd0d37ac610e8727ec0288a898d5dfbd79b25bcaa29828       name  name       value  hello world       name  kind       value  task          Pipeline Resolution  Unfortunately the Tekton Catalog does not publish pipelines at the moment  Here s an example PipelineRun that talks to a private registry but won t work unless you tweak the  bundle  field to point to a registry with a pipeline in it      yaml apiVersion  tekton dev v1beta1 kind  PipelineRun metadata    name  bundle demo spec    pipelineRef      resolver  bundles     params        name  bundle       value  10 96 190 208 5000 simple pipeline latest       name  name       value  hello pipeline       name  kind       value  pipeline   params      name  username     value   tekton pipelines           ResolutionRequest  Status  ResolutionRequest Status RefSource  field captures the source where the remote resource came from  It includes the 3 subfields   url    digest  and  entrypoint      uri   The image repository URI    digest   The map of the algorithm portion    the hex encoded portion of the image digest     entrypoint   The resource name in the OCI bundle image   Example    TaskRun Resolution    yaml apiVersion  tekton dev v1beta1 kind  TaskRun metadata    name  remote task reference spec    taskRef      resolver  bundles     params        name  bundle       value  gcr io tekton releases catalog upstream git clone 0 7       name  name       value  git clone       name  kind       value  task   params        name  url       value  https   github com octocat Hello World   workspaces        name  output       volumeClaimTemplate          spec            accessModes                ReadWriteOnce           resources              requests                storage  500Mi         ResolutionRequest     yaml apiVersion  resolution tekton dev v1beta1 kind  ResolutionRequest metadata          labels      resolution tekton dev type  bundles   name  bundles 21ad80ec13f3e8b73fed5880a64d4611       spec    params      name  bundle     value  gcr io tekton releases catalog upstream git clone 0 7     name  name     value  git clone     name  kind     value  task status    annotations              data  xxx   observedGeneration  1   refSource      digest        sha256  f51ca50f1c065acba8290ef14adec8461915ecc5f70a8eb26190c6e8e0ededaf     entryPoint  git clone     uri  gcr io tekton releases catalog upstream git clone           Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  https   creativecommons org licenses by 4 0    and code samples are licensed under the  Apache 2 0 License  https   www apache org licenses LICENSE 2 0


tekton Use resolver type Hub Resolver weight 311 Hub Resolver

Answer:
<!--
---
linkTitle: "Hub Resolver"
weight: 311
---
-->

# Hub Resolver

Use resolver type `hub`.

## Parameters

| Param Name       | Description                                                                   | Example Value                                              |
|------------------|-------------------------------------------------------------------------------|------------------------------------------------------------|
| `catalog`        | The catalog from where to pull the resource (Optional)                        | Default:  `tekton-catalog-tasks` (for `task` kind);  `tekton-catalog-pipelines` (for `pipeline` kind)                                        |
| `type`           | The type of Hub from where to pull the resource (Optional). Either `artifact` or `tekton` | Default:  `artifact`                                         |
| `kind`           | Either `task` or `pipeline` (Optional)                                        | Default: `task`                                                     |
| `name`           | The name of the task or pipeline to fetch from the hub                        | `golang-build`                                             |
| `version`        | Version or a Constraint (see [below](#version-constraint) of a task or a pipeline to pull in from. Wrap the number in quotes!   | `"0.5.0"`, `">= 0.5.0"`                                                    |

The Catalogs in the Artifact Hub follows the semVer (i.e.` <major-version>.<minor-version>.0`) and the Catalogs in the Tekton Hub follows the simplified semVer (i.e. `<major-version>.<minor-version>`). Both full and simplified semantic versioning will be accepted by the `version` parameter. The Hub Resolver will map the version to the format expected by the target Hub `type`.

## Requirements

- A cluster running Tekton Pipeline v0.41.0 or later.
- The [built-in remote resolvers installed](./install.md#installing-and-configuring-remote-task-and-pipeline-resolution).
- The `enable-hub-resolver` feature flag in the `resolvers-feature-flags` ConfigMap in the
  `tekton-pipelines-resolvers` namespace set to `true`.
- [Beta features](./additional-configs.md#beta-features) enabled.

## Configuration

This resolver uses a `ConfigMap` for its settings. See
[`../config/resolvers/hubresolver-config.yaml`](../config/resolvers/hubresolver-config.yaml)
for the name, namespace and defaults that the resolver ships with.

### Options

| Option Name                 | Description                                          | Example Values         |
|-----------------------------|------------------------------------------------------|------------------------|
| `default-tekton-hub-catalog`| The default tekton hub catalog from where to pull the resource.| `Tekton`               |
| `default-artifact-hub-task-catalog`| The default artifact hub catalog from where to pull the resource for task kind.| `tekton-catalog-tasks`               |
| `default-artifact-hub-pipeline-catalog`| The default artifact hub catalog from where to pull the resource for pipeline kind.  | `tekton-catalog-pipelines`               |
| `default-kind`              | The default object kind for references.              | `task`, `pipeline`     |
| `default-type`              | The default hub from where to pull the resource.     | `artifact`, `tekton`   |

### Configuring the Hub API endpoint

The Hub Resolver supports to resolve resources from the [Artifact Hub](https://artifacthub.io/) and the [Tekton Hub](https://hub.tekton.dev/),
which can be configured by setting the `type` field of the resolver.

*(Please note that the [Tekton Hub](https://hub.tekton.dev/) will be deprecated after [migration to the Artifact Hub](https://github.com/tektoncd/hub/issues/667) is done.)*

When setting the `type` field to `artifact`, the resolver will hit the public hub api at https://artifacthub.io/ by default
but you can configure your own (for example to use a private hub
instance) by setting the `ARTIFACT_HUB_API` environment variable in
[`../config/resolvers/resolvers-deployment.yaml`](../config/resolvers/resolvers-deployment.yaml). Example:

```yaml
env
- name: ARTIFACT_HUB_API
  value: "https://artifacthub.io/"
```

When setting the `type` field to `tekton`, the resolver will hit the public
tekton catalog api at https://api.hub.tekton.dev by default but you can configure
your own instance of the Tekton Hub by setting the `TEKTON_HUB_API` environment
variable in
[`../config/resolvers/resolvers-deployment.yaml`](../config/resolvers/resolvers-deployment.yaml). Example:

```yaml
env
- name: TEKTON_HUB_API
  value: "https://api.private.hub.instance.dev"
```

The Tekton Hub deployment guide can be found [here](https://github.com/tektoncd/hub/blob/main/docs/DEPLOYMENT.md).

## Usage

### Task Resolution

```yaml
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: remote-task-reference
spec:
  taskRef:
    resolver: hub
    params:
    - name: catalog # optional
      value: tekton-catalog-tasks
    - name: type # optional
      value: artifact
    - name: kind
      value: task
    - name: name
      value: git-clone
    - name: version
      value: "0.6"
```

### Pipeline Resolution

```yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: hub-demo
spec:
  pipelineRef:
    resolver: hub
    params:
    - name: catalog # optional
      value: tekton-catalog-pipelines
    - name: type # optional
      value: artifact
    - name: kind
      value: pipeline
    - name: name
      value: buildpacks
    - name: version
      value: "0.1"
  # Note: the buildpacks pipeline requires parameters.
  # Resolution of the pipeline will succeed but the PipelineRun
  # overall will not succeed without those parameters.
```

### Version constraint

Instead of a version you can specify a constraint to choose from. The constraint is a string as documented in the [go-version](https://github.com/hashicorp/go-version) library.

Some examples:

```yaml
params:
  - name: name
    value: git-clone
  - name: version
    value: ">=0.7.0"
```

Will only choose the git-clone task that is greater than version `0.7.0`

```yaml
params:
  - name: name
    value: git-clone
  - name: version
    value: ">=0.7.0, < 2.0.0"
```

Will select the **latest** git-clone task that is greater than version `0.7.0` and
less than version `2.0.0`, so if the latest task is the version `0.9.0` it will
be selected.

Other operators for selection are available for comparisons, see the
[go-version](https://github.com/hashicorp/go-version/blob/644291d14038339745c2d883a1a114488e30b702/constraint.go#L40C2-L48)
source code.

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

linkTitle   Hub Resolver  weight  311            Hub Resolver  Use resolver type  hub       Parameters    Param Name         Description                                                                     Example Value                                                                                catalog           The catalog from where to pull the resource  Optional                           Default    tekton catalog tasks   for  task  kind     tekton catalog pipelines   for  pipeline  kind                                              type              The type of Hub from where to pull the resource  Optional   Either  artifact  or  tekton    Default    artifact                                               kind              Either  task  or  pipeline   Optional                                           Default   task                                                           name              The name of the task or pipeline to fetch from the hub                           golang build                                                   version           Version or a Constraint  see  below   version constraint  of a task or a pipeline to pull in from  Wrap the number in quotes        0 5 0         0 5 0                                                         The Catalogs in the Artifact Hub follows the semVer  i e    major version   minor version  0   and the Catalogs in the Tekton Hub follows the simplified semVer  i e    major version   minor version     Both full and simplified semantic versioning will be accepted by the  version  parameter  The Hub Resolver will map the version to the format expected by the target Hub  type       Requirements    A cluster running Tekton Pipeline v0 41 0 or later    The  built in remote resolvers installed    install md installing and configuring remote task and pipeline resolution     The  enable hub resolver  feature flag in the  resolvers feature flags  ConfigMap in the    tekton pipelines resolvers  namespace set to  true      Beta features    additional configs md beta features  enabled      Configuration  This resolver uses a  ConfigMap  for its settings  See      config resolvers hubresolver config yaml      config resolvers hubresolver config yaml  for the name  namespace and defaults that the resolver ships with       Options    Option Name                   Description                                            Example Values                                                                                default tekton hub catalog   The default tekton hub catalog from where to pull the resource    Tekton                     default artifact hub task catalog   The default artifact hub catalog from where to pull the resource for task kind    tekton catalog tasks                     default artifact hub pipeline catalog   The default artifact hub catalog from where to pull the resource for pipeline kind      tekton catalog pipelines                     default kind                 The default object kind for references                  task    pipeline           default type                 The default hub from where to pull the resource         artifact    tekton            Configuring the Hub API endpoint  The Hub Resolver supports to resolve resources from the  Artifact Hub  https   artifacthub io   and the  Tekton Hub  https   hub tekton dev    which can be configured by setting the  type  field of the resolver      Please note that the  Tekton Hub  https   hub tekton dev   will be deprecated after  migration to the Artifact Hub  https   github com tektoncd hub issues 667  is done     When setting the  type  field to  artifact   the resolver will hit the public hub api at https   artifacthub io  by default but you can configure your own  for example to use a private hub instance  by setting the  ARTIFACT HUB API  environment variable in      config resolvers resolvers deployment yaml      config resolvers resolvers deployment yaml   Example      yaml env   name  ARTIFACT HUB API   value   https   artifacthub io        When setting the  type  field to  tekton   the resolver will hit the public tekton catalog api at https   api hub tekton dev by default but you can configure your own instance of the Tekton Hub by setting the  TEKTON HUB API  environment variable in      config resolvers resolvers deployment yaml      config resolvers resolvers deployment yaml   Example      yaml env   name  TEKTON HUB API   value   https   api private hub instance dev       The Tekton Hub deployment guide can be found  here  https   github com tektoncd hub blob main docs DEPLOYMENT md       Usage      Task Resolution     yaml apiVersion  tekton dev v1beta1 kind  TaskRun metadata    name  remote task reference spec    taskRef      resolver  hub     params        name  catalog   optional       value  tekton catalog tasks       name  type   optional       value  artifact        name  kind       value  task       name  name       value  git clone       name  version       value   0 6           Pipeline Resolution     yaml apiVersion  tekton dev v1beta1 kind  PipelineRun metadata    name  hub demo spec    pipelineRef      resolver  hub     params        name  catalog   optional       value  tekton catalog pipelines        name  type   optional       value  artifact       name  kind       value  pipeline       name  name       value  buildpacks       name  version       value   0 1      Note  the buildpacks pipeline requires parameters      Resolution of the pipeline will succeed but the PipelineRun     overall will not succeed without those parameters           Version constraint  Instead of a version you can specify a constraint to choose from  The constraint is a string as documented in the  go version  https   github com hashicorp go version  library   Some examples      yaml params      name  name     value  git clone     name  version     value     0 7 0       Will only choose the git clone task that is greater than version  0 7 0      yaml params      name  name     value  git clone     name  version     value     0 7 0    2 0 0       Will select the   latest   git clone task that is greater than version  0 7 0  and less than version  2 0 0   so if the latest task is the version  0 9 0  it will be selected   Other operators for selection are available for comparisons  see the  go version  https   github com hashicorp go version blob 644291d14038339745c2d883a1a114488e30b702 constraint go L40C2 L48  source code        Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  https   creativecommons org licenses by 4 0    and code samples are licensed under the  Apache 2 0 License  https   www apache org licenses LICENSE 2 0