Add container resource requirements customization for affinity-assistant pods

[vdemeester]

Problem

Affinity-assistant pods have hardcoded resource requirements that cannot be customized:

// pkg/reconciler/pipelinerun/affinity_assistant.go:331-339
Resources: corev1.ResourceRequirements{
    Limits: corev1.ResourceList{
        "cpu":    resource.MustParse("50m"),
        "memory": resource.MustParse("100Mi"),
    },
    Requests: corev1.ResourceList{
        "cpu":    resource.MustParse("50m"),
        "memory": resource.MustParse("100Mi"),
    },
}

This causes issues in environments with ResourceQuota policies:

• Resource Contention: Hardcoded values may be insufficient or excessive
• Quota Exhaustion: Minimal AA pods still consume quota needed for workloads
• LimitRange Conflicts: Namespace LimitRanges may prevent pod creation
• Inflexibility: No tuning based on cluster size or workload needs

Use Case

Red Hat OpenShift Pipelines customers with strict ResourceQuota policies need to customize affinity-assistant resources to match quota constraints and prevent scheduling failures (#8015, #3049).

Proposed Solution

Add Resources field to AffinityAssistantTemplate, following the pattern from #2679:

type AffinityAssistantTemplate struct {
    NodeSelector      map[string]string
    Tolerations       []corev1.Toleration
    ImagePullSecrets  []corev1.LocalObjectReference
    SecurityContext   *corev1.PodSecurityContext
    PriorityClassName *string
    Resources         *corev1.ResourceRequirements `json:"resources,omitempty"` // NEW
}

Configuration examples:

Global default:

default-affinity-assistant-pod-template: |
  resources:
    requests:
      cpu: "50m"
      memory: "100Mi"
    limits:
      cpu: "100m"
      memory: "200Mi"

Per-PipelineRun override:

spec:
  taskRunTemplate:
    podTemplate:
      resources:
        requests:
          cpu: "100m"
          memory: "200Mi"

Implementation

1. Update AffinityAssistantTemplate struct
2. Update MergeAAPodTemplateWithDefault() merge logic
3. Apply resources in affinityAssistantStatefulSet()
4. Add validation (requests ≤ limits)
5. Maintain backward compatibility (current hardcoded values as defaults)
6. Update docs and generate OpenAPI schemas

Alternatives Considered

• Extend default-container-resource-requirements: Inconsistent with AffinityAssistantTemplate pattern
• LimitRange: Already available; applies to all pods (not targeted)
• MutatingAdmissionWebhook: Over-engineered
• Environment variables: Anti-pattern

Related Issues

• Add option to specify PodTemplate for Affinity Assistant #2679 - PodTemplate for AA (implemented nodeSelector/tolerations, not resources)
• Support full podtemplate spec for affinity assistant pod #7779 - Full podtemplate spec support
• affinity assistant will schedule onto nodes with insufficient resources to run a pod in the pipeline, it should not #8015 - AA scheduling failures due to resources
• Affinity assistant only takes first task's resource requirements into account when choosing a node #3049 - AA only considers first task resources

Benefits

• Flexibility for different cluster configurations
• ResourceQuota compatibility
• Follows existing AffinityAssistantTemplate pattern
• Backward compatible
• Kubernetes-native

Implementation Offer

Red Hat OpenShift Pipelines team is willing to contribute this implementation if the community agrees with the approach.

Questions

1. Does this align with Tekton's AA configuration vision?
2. Should this go through the TEP process (API change)?
3. Beta feature flag before stabilization?

---

cc @tektoncd/core-maintainers

[ocpvkb]

👍

[waveywaves]

/assign @mathur07

[tekton-robot]

@waveywaves: GitHub didn't allow me to assign the following users: mathur07.

Note that only tektoncd members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

Details

In response to this:

/assign @mathur07

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.