Node load balancing

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 example kubernetes. 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.