Change:
} } <del> var podsNeededForSaturation int milliCpuPerPod := nodeMaxAllocatable / maxNumberOfPods if milliCpuPerPod < minPodCPURequest { milliCpuPerPod = minPodCPURequest } framework.Logf("Using pod capacity: %vm", milliCpuPerPod) for name, leftAllocatable := range nodeToAllocatableMap { framework.Logf("Node: %v has cpu allocatable: %vm", name, leftAllocatable) podsNeededForSaturation += (int)(leftAllocatable / milliCpuPerPod) } By(fmt.Sprintf("Starting additional %v Pods to fully saturate the cluster CPU and trying to start another one", podsNeededForSaturation)) // As the pods are distributed randomly among nodes, // it can easily happen that all nodes are saturated // and there is no need to create additional pods. // StartPods requires at least one pod to replicate. if podsNeededForSaturation > 0 { framework.ExpectNoError(testutils.StartPods(cs, podsNeededForSaturation, ns, "overcommit", *initPausePod(f, pausePodConfig{ Name:   "", Labels: map[string]string{"name": ""}, Resources: &v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(milliCpuPerPod, "DecimalSI"), }, Requests: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(milliCpuPerPod, "DecimalSI"), </del> <ins> By("Starting Pods to consume most of the cluster CPU.") // Create one pod per node that requires 70% of the node remaining CPU. fillerPods := []*v1.Pod{} for nodeName, cpu := range nodeToAllocatableMap { requestedCPU := cpu * 7 / 10 fillerPods = append(fillerPods, createPausePod(f, pausePodConfig{ Name: "filler-pod-" + nodeName, Resources: &v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(requestedCPU, "DecimalSI"), }, Requests: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(requestedCPU, "DecimalSI"), }, }, Affinity: &v1.Affinity{ NodeAffinity: &v1.NodeAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: &v1.NodeSelector{ NodeSelectorTerms: []v1.NodeSelectorTerm{ { MatchExpressions: []v1.NodeSelectorRequirement{ { Key:      "node", Operator: v1.NodeSelectorOpIn, Values:   []string{nodeName}, }, }, }, }, </ins> }, }, <del> }), true, framework.Logf)) </del> <ins> }, })) </ins> } <ins> // Wait for filler pods to schedule. for _, pod := range fillerPods { framework.ExpectNoError(framework.WaitForPodRunningInNamespace(cs, pod)) } By("Creating another pod that requires unavailable amount of CPU.") // Create another pod that requires 50% of the largest node CPU resources. // This pod should remain pending as at least 70% of CPU of other nodes in // the cluster are already consumed. </ins> podName := "additional-pod" conf := pausePodConfig{ Name:   podName, Labels: map[string]string{"name": "additional"}, Resources: &v1.ResourceRequirements{ Limits: v1.ResourceList{ <del> v1.ResourceCPU: *resource.NewMilliQuantity(milliCpuPerPod, "DecimalSI"), </del> <ins> v1.ResourceCPU: *resource.NewMilliQuantity(nodeMaxAllocatable*5/10, "DecimalSI"), </ins> }, }, } WaitForSchedulerAfterAction(f, createPausePodAction(f, conf), podName, false) <del> verifyResult(cs, podsNeededForSaturation, 1, ns) </del> <ins> verifyResult(cs, len(fillerPods), 1, ns) </ins> }) // Test Nodes does not have any label, hence it should be impossible to schedule Pod with

Discussion:
cc cc Seeing a failure on our downgrade test. Can someone please look at this? https://k8s- Example failure https://k8s- Seeing timeouts on the downgrade test
Since we're so late in the release process and this is the first time we're seeing this fail, going to mark as non-release-blocking for now.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/scheduling: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
It fails in more places than just the downgrade job, but when the downgrade job fails that test, that timeout appears to be the consistent error that it fails with
/assign I looked at the logs. The test creates a few pods to saturate the existing nodes and then creates an additional pod and ensures that this last pod stays pending. The problem we observe is that those saturating pods are often not scheduled, causing a test timeout. Those pods use all the resources on the nodes. So, any small changes to the amount of available node resources or even rounding errors could cause those saturating pods to not schedule. I will test this theory by cutting down the amount of resources that the saturating pods use, but I would like to check if the problem is fixed before submitting the PR. Where can I get the steps these cluster downgrade tests take?
The test setups are in the test-infra repo. E.g.
see my analysis in .