|
|
|
|
|
|
by zaat
2219 days ago
|
|
|
Simply put, what the article recommends is in most situations, dead wrong advice. If configured as suggested, and for some reason you lose enoguh nodes in your cluster for not having single node for each of your replicas, you will have less replicas than you intended, since the scheduler can't schedule a pod to a node where identical pod is already running. Additionally, the affinity and anti affinity features are costly from the cluster perspective, so the configuration recommended by the author cost you performance. And why isn't Kubernetes doing the obvious thing and spread apart your pods? well, it's simple - it does the right thing: https://v1-15.docs.kubernetes.io/docs/concepts/scheduling/ku... The first scoring parameter is SelectorSpreadPriority. |
|
|