To increase system resiliency during host or zone failures, configure the topologySpreadConstraints parameter. This controls the even distribution of pods across the cluster topology, such as availability zones, nodes, or regions.
Before configuring the topologySpreadConstraints parameter, please read the BRIX Enterprise advanced settings article to learn about all the pod placement tools and recommendations for using them together.
How to configure the topologySpreadConstraints parameter
You can configure the topologySpreadConstraints parameter in the values-elma365.yaml file. Go to the .Values.global.topologySpreadConstraints field and set the values, for example:
global:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
Where:
maxSkewis the maximum allowable difference in the number of pods between nodes.topologyKeyis the metadata key to define the topology of the nodes, for examplekubernetes. io/hostname.whenUnsatisfiableis the algorithm of action if the constraints cannot be applied:-
ScheduleAnyway. If no suitable node is found, the pod will run on any available node. DoNotSchedule. If no suitable node is found, the pod will not run until the conditions are met.
-
Once the parameter is configured, apply it as described in the Modify BRIX Enterprise parameters article.
Default values for the topologySpreadConstraints parameter
If you do not set the topologySpreadConstraints parameter, the following configuration applies for even distribution of pods:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: <service name>
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: <service name>