Skip to content

Topology

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

Node placement

For high availability it's desirable that different Kubernetes Nodes don't share the underlying hardware and hence failure domain.

You can control scheduling of OpenStack servers using server groups. By default, MetaKube creates one server group for each cluster, which is used for all MachineDeployments and hence, Nodes.

In some scenarios (many nodes) it's impossible to avoid all Nodes being scheduled on the same hardware.

MetaKube allows you to reference your own server group for a MachineDeployment. This gives you more control over placement, incl.:

  • Using "hard" anti-affinity policy to "fail fast" in case scheduling isn't possible
  • Using server groups for smaller MachineDeployments on which the policy can be enforced

Pod placement

Whenever a Pod is created, its spec.nodeName field is initially empty. It's the scheduler's role to choose a fitting Node and fill out this field.

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

Taints

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

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

Labels & Affinity

Any labels in spec.template.spec.metadata.labels of a MachineDeployment will be added 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.