Do not set empty pod level resources object

What does this MR do?

Makes executor.podResourcesReference() return nil instead of an empty &api.ResourceRequirements{} when no pod-level resource overwrites (KUBERNETES_POD_CPU_*/KUBERNETES_POD_MEMORY_*) are configured. Both pod assembly paths (preparePodConfig and stepsPreparePodConfig) share this function, so the fix applies to both.

Why was this MR needed?

Job pods were showing qosClass: BestEffort instead of the expected Burstable, due to two combined issues:

  1. Since commit e562863b, podResourcesReference() always set Pod.Spec.Resources to a non-nil-but-empty ResourceRequirements, even when no pod-level resources were configured.
  2. Kubernetes versions < 1.37 before kubernetes/kubernetes#137150 mis-calculates QoS class when Pod.Spec.Resources is present-but-empty under the PodLevelResources feature gate, misclassifying the pod as BestEffort.

This MR is necessary for gitlab-runner customers using k8s executor on k8s clusters before 1.37 to get correct qosClass.

What's the best way to test this MR?

go test ./executors/kubernetes/... -run 'TestPodResourcesReference|TestStepsPreparePodConfig_PodResources' covers the fix directly (nil/empty/limits-only/requests-only/both-set cases, and full pod assembly). go build/go vet clean; full package test has 3 pre-existing failures unrelated to this change (reproduce identically on main); lint has 3 pre-existing issues on unrelated lines.

Manual check: run a job with no KUBERNETES_POD_* overwrites, kubectl get pod <pod> -o jsonpath='{.spec.resources}' should now be empty/absent (was {}). Setting KUBERNETES_POD_CPU_REQUEST/ KUBERNETES_POD_MEMORY_REQUEST (or _LIMIT) should still populate it.

What are the relevant issue numbers?

N/A — no issue number provided.

Edited by Joseph Zhang

Merge request reports

Loading
Loading