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:
maxSkew
is the maximum allowable difference in the number of pods between nodes.topologyKey
is the metadata key to define the topology of the nodes, for examplekubernetes. io/hostname
.whenUnsatisfiable
is 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
In the values-elma365.yaml
file, the topologySpreadConstraints
parameter is set to the following default values:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
You can change these values of the parameter.
Found a typo? Select it and press Ctrl+Enter to send us feedback