Hi, thanks for that suggestion. I took a look, but tit seems it isn't
quite what's needed.
It looks likes pod (anti)affinity is a binary thing. It works for the
first pod on the node with/without the specified label, but it doesn't
ensure an even spread when you schedule multiple pods.
In my
Here’s an OpenShift reference for the same thing.
https://docs.openshift.com/container-platform/3.6/admin_guide/scheduling/pod_affinity.html
On Wed, 4 Jul 2018 at 9:14 pm, Joel Pearson
wrote:
> You’re probably after pod anti-affinity?
>
You’re probably after pod anti-affinity?
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
That lets you tell the scheduler that the pods aren’t allowed to be on the
same node for example.
On Wed, 4 Jul 2018 at 8:51 pm, Tim Dudgeon wrote:
> I've got a
I've got a process the fires up a number of pods (bare pods, not backed
by replication controller) to execute a computationally demanding job in
parallel.
What I find is that the pods do not spread effectively across the
available nodes. In my case I have a node selector that restricts
