Skip to content

Component scheduling New#

MKE 4 runs a number of platform components as Kubernetes workloads. By default, the Kubernetes scheduler is able to place the Pods for these components on any eligible node, and as such several replicas of a single component can reside on the same node. Should that node fail, every replica that it hosts is simultaneously lost, which thus undermines the availability that running multiple replicas is intended to provide. Component scheduling addresses this concern.

You configure component scheduling through the spec.componentScheduling section of the MkeConfig object. Once it is enabled, MKE 4 applies a set of Kubernetes topology spread constraints to its platform components, thus distributing their Pods across the cluster topology, across distinct nodes, by default.

Covered components#

MKE 4 applies the component scheduling constraints to the following components, each of which is considered critical to the operation of the cluster:

Default configuration#

By default, component scheduling is enabled through the MkeConfig object, with a single constraint that spreads component Pods across cluster nodes:

spec:
  componentScheduling:
    enabled: true
    topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway

This configuration limits the Pod count difference between any two nodes to one (maxSkew: 1) across the kubernetes.io/hostname topology domain. The constraint is a preference, not a requirement: whenUnsatisfiable: ScheduleAnyway allows placement even when no node can satisfy the spread, so a Pod is never left Pending solely because the skew cannot be honored.

Configuration fields#

The componentScheduling section fields are detailed in the following table:

Field                                                             Description
enabled Determines whether MKE 4 applies the component scheduling constraints.

Default: true
topologySpreadConstraints Results in a list of Kubernetes topology spread constraints that MKE 4 applies to its platform component Pods.

Each entry in topologySpreadConstraints accepts the standard Kubernetes fields, the most significant of which are detailed in the table below:

Field                                                             Description
maxSkew Sets the maximum permitted difference in the number of matching Pods between any two topology domains. Must be greater than zero.
topologyKey Sets the node label that defines a topology domain. Pods are spread across the domains identified by this key; kubernetes.io/hostname, for example, treats each node as a domain.
whenUnsatisfiable Determines the action the scheduler takes when a Pod cannot be placed without violating the constraint. ScheduleAnyway schedules the Pod regardless, whereas DoNotSchedule leaves the Pod Pending.

Disable component scheduling#

To disable component scheduling, set spec.componentScheduling.enabled in the MkeConfig object to false:

spec:
  componentScheduling:
    enabled: false

When component scheduling is disabled, MKE 4 does not apply any topology spread constraints to its platform component Pods, and placement reverts to the default behavior of the Kubernetes scheduler.