Add topology spread constrant option #343
Conversation
Signed-off-by: Loc Mai <locmai0201@gmail.com>
Signed-off-by: Loc Mai <locmai0201@gmail.com>
| @@ -468,6 +470,7 @@ ingester: | |||
| prometheus.io/port: '8080' | |||
|
|
|||
| nodeSelector: {} | |||
| topologySpreadConstraints: [] | |||
There was a problem hiding this comment.
Question for reviewers: given that ingesters have a pod disruption budget of 1, would it make sense to revise the default podAntiAffinity config a few lines below this to make it a hard requirement that more than one ingester should never be scheduled to the same node? That behavior could also be implemented using topologySpreadConstraints constructs, which would eliminate the need for the podAntiAffinity config.
This is desirable because presently it is possible to get two pods on one node, and then when node patching happens, the process gets stuck because it can't evict two ingester pods in order to patch the node.
There was a problem hiding this comment.
would you be open to create an seperate PR after this is merged?
There was a problem hiding this comment.
would it make sense to revise the default podAntiAffinity config a few lines below this to make it a hard requirement that more than one ingester should never be scheduled to the same node?
We do this for our production deployments with an override. We should probably pick a clear strategy for this chart on whether the chart defaults represent good production values or whether they are more tuned for testing. It is helpful to be able to deploy multiple ingester pods to a single node for testing.
Signed-off-by: Loc Mai <locmai0201@gmail.com>
|
@nschad Thanks for taking a look, I just pushed a new one to solve that. |
What this PR does:
Provide the ability to configure Pod Topology Spread Constraints.
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]