### Summary The Kubernetes executor unconditionally sets `spec.resources` on every build pod, even when no `pod_*` resource keys are configured. On Kubernetes 1.34 and later, where the `PodLevelResources` feature gate is beta and enabled by default, a **non-nil but empty** pod-level resources object causes the pod to be classified as **QoS `BestEffort`** regardless of the requests set on its containers. The practical effect is that every CI job pod becomes the kubelet's first eviction candidate and receives the worst OOM score, even when its build container requests several gigabytes of memory. On a busy cluster this shows up as CI jobs being evicted under node memory pressure in preference to genuinely low-priority workloads. ### Root cause `executors/kubernetes/kubernetes.go` assigns the result of `podResourcesReference()` to the pod spec unconditionally, and that helper always returns a non-nil pointer: ```go func (s *executor) podResourcesReference() *api.ResourceRequirements { resources := api.ResourceRequirements{} if s.configurationOverwrites != nil { resources.Limits = s.configurationOverwrites.podLimits resources.Requests = s.configurationOverwrites.podRequests } return &resources } ``` With no `pod_cpu_*` / `pod_memory_*` configuration, `Limits` and `Requests` are nil maps, so the submitted pod carries `spec.resources: {}`. The field is `*ResourceRequirements` with `json:"resources,omitempty"`, and `omitempty` does not drop a non-nil pointer to an empty struct, so the empty object reaches the API server. Kubernetes then classifies it as `BestEffort`. In `release-1.34`, `pkg/apis/core/v1/helper/qos/qos.go` enters the pod-level branch on a nil check alone: ```go if utilfeature.DefaultFeatureGate.Enabled(features.PodLevelResources) && pod.Spec.Resources != nil ``` There is no test for whether the struct is empty. Inside that branch the pod-level requests and limits maps are empty, so it falls through to `if len(requests) == 0 && len(limits) == 0 { return v1.PodQOSBestEffort }`, and container-level resources are never consulted. This is a known upstream defect, documented in KEP-2837: *"While most of the codebase correctly differentiates between them to determine if a pod has opted into pod-level resources, `ComputePodQOS` fails to do so consistently"*, which can lead to *"a pod with container-level resources ... misclassified as `BestEffort`"*. The upstream fix is gated behind `PodLevelResourcesFixKubeletQOSClass`, which is not present in `release-1.36` and is declared for **1.37** on `master`. Operators on 1.34 to 1.36 therefore cannot wait for the platform fix, and the gate cannot be disabled on managed platforms such as GKE, where feature-gate changes are only permitted on alpha clusters. ### Steps to reproduce 1. Kubernetes 1.34 or later (`PodLevelResources` beta, enabled by default). 2. GitLab Runner 18.10 or later using the Kubernetes executor. 3. Configure container-level resources only, for example `[runners.kubernetes] cpu_request = "3000m"`, `memory_request = "3Gi"`. Do not set any `pod_*` keys. 4. Run any job and inspect the resulting build pod: ``` kubectl get pod <build-pod> -o jsonpath='{.spec.resources}' # -> {} (empty, but present) kubectl get pod <build-pod> -o jsonpath='{.status.qosClass}' # -> BestEffort kubectl get pod <build-pod> -o jsonpath='{.spec.containers[?(@.name=="build")].resources}' # -> populated requests ``` **Expected:** `Burstable`, since the build container has requests. **Actual:** `BestEffort`. The same configuration on Kubernetes 1.33 yields `Burstable`, because the pod-level branch is not taken. Note that the scheduler still honours the container-level requests (pods fail to schedule with `Insufficient cpu` when the cluster is full), so this is specifically a QoS/eviction-ranking problem rather than a scheduling one, which makes it easy to miss. ### Proposed fix Return nil when nothing was actually configured, so the field is omitted: ```go func (s *executor) podResourcesReference() *api.ResourceRequirements { resources := api.ResourceRequirements{} if s.configurationOverwrites != nil { resources.Limits = s.configurationOverwrites.podLimits resources.Requests = s.configurationOverwrites.podRequests } if len(resources.Limits) == 0 && len(resources.Requests) == 0 { return nil } return &resources } ``` This is behaviour-preserving for anyone who has configured pod-level resources, and restores correct QoS for everyone who has not. ### Affected versions - **GitLab Runner:** 18.10 and later, including current `main`. Pod-level resources support was added in !5922 (milestone 18.10), closing #39085. - **Kubernetes:** 1.34 through 1.36 (fix gate lands in 1.37). ### Workaround Set genuine pod-level resources (`pod_cpu_request`, `pod_cpu_limit`, `pod_memory_request`, `pod_memory_limit`) so the object is non-empty and a real QoS class is computed. Note these take precedence over container-level values and must accommodate the sum of the build, helper and any service containers, so they need to be sized deliberately rather than copied from the build container. ### References - KEP-2837: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2837-pod-level-resource-spec/README.md - Kubernetes 1.34 pod-level resources announcement: https://kubernetes.io/blog/2025/09/22/kubernetes-v1-34-pod-level-resources/ - `qos.go` in `release-1.34` vs `master` (the added `IsPodLevelResourcesSet` check) - Origin of the pod-level resources feature in Runner: !5922, #39085