Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SUMMARY
By default, due to low default resource requests, automation job pods are frequently scheduled on the same OCP worker nodes even when there are other nodes available. One way we can influence this behavior without blocking job pods from being scheduled to prioritize being as far away from other jobs as is possible is to add pod-anti-affinity rules
We saw this issue on a very large OCP cluster with 20 or more worker nodes available, but all jobs were ending up on only 5 worker nodes. CPU utilization on those nodes was 100% and problems with delays in job events arriving to the control plan were encountered, and in general the jobs ran slower than expected.
Steps to Reproduce
Run lots of jobs on a container group with relatively low CPU/memory requests (the default) and many large worker nodes
Actual Behavior
Jobs clump together, are not automatically spread across worker nodes
Expected Behavior
Jobs spread out across available worker nodes to evenly distribute workload
With these changes, for users on small clusters, they will likely not notice much change, but for users with larger number of worker nodes, this will help make sure pods are further spread out and better utilize their resources when running in our default mode of low resource requests and no limits. Notice I used preferredDuringSchedulingIgnoredDuringExecution which means if there is no other host to schedule on, then it gets scheduled anyway if otherwise schedulable. So won't have detrimental impact on small clusters.
ISSUE TYPE
COMPONENT NAME
AWX default container pod spec
AWX VERSION
devel
ADDITIONAL INFORMATION
I was able to test this locally using https://github.com/ansible/awx/blob/devel/docs/development/kind.md to setup a local kind cluster with a couple worker nodes. Describing the pod output in yaml, I was able to verify the affinity rules being set.