Skip to content

Topology

Here, we describe the available mechanisms to distribute nodes and workloads.

Node placement

High availability benefits from Kubernetes Node not sharing the underlying hardware and failure domain.

You can control the scheduling of OpenStack servers using server groups. By default, MetaKube creates one server group per cluster, and all MachineDeployments use it, along with their Nodes.

In some scenarios (for example, large clusters), OpenStack may schedule all Nodes on the same hardware.

MetaKube lets you reference your own server group for a MachineDeployment. This gives you more control over placement, including:

  • Using a "hard" anti-affinity policy to fail fast when scheduling is not possible
  • Using server groups for smaller MachineDeployments where the policy takes effect

Pod placement

When you create a Pod, its spec.nodeName field starts empty. The scheduler chooses a suitable Node and sets this field.

Before scoring each Node and choosing the best one, the scheduler discards certain Nodes based on the Pod's and Node's specifications.

Taints

When you specify spec.template.spec.taints in a MachineDeployment, Kubelet registers the node with these taints.

Specify tolerations in your Pods to allow them to schedule on nodes with matching taints.

Labels and Affinity

Labels in spec.template.spec.metadata.labels of a MachineDeployment apply to the corresponding nodes.

Use these labels with nodeSelectors, affinity or topologySpreadConstraints rules.

Info

MetaKube adds the machine-controller/physical-host-id label to the nodes.

It contains a reference to the hardware node the server is on.