Assigning pods to nodes

You can configure affinity rules in your custom resource (CR) to specify the nodes that your pods are scheduled to run on. For example, you might want to place pods from two different services into the same availability zone or ensure that a pod runs only on nodes with a particular type of CPU.

The following affinity settings can be used to control the scheduling of pods on worker nodes:

Node affinity

spec.advanced.podSettings.microservice.affinity.nodeAffinity

Use node affinity to control which nodes your pod are scheduled to run on, based on labels on the node.

Pod affinity and anti-affinity

spec.advanced.podSettings.microservice.affinity.podAffinity
spec.advanced.podSettings.microservice.affinity.podAntiAffinity

Use pod affinity and anti-affinity to control the nodes that your pods are scheduled to run on, based on the labels on pods that are already running on the node.

The pod affinity rule controls the placement of a pod on the same node or availability zone as another pod. The anti-affinity rule enables the scheduler to avoid putting a pod on the same node or availability zone as another pod.

Tolerations

spec.advanced.podSettings.microservice.tolerations

Tolerations works with the node property, taints, to ensure that pods are not scheduled to run on inappropriate nodes.

Taints allow a node to repel a set of pods. Tolerations are applied to pods, and ensure that pods are scheduled to run on nodes with matching taints.

The affinity rules apply to the following microservices:

apollo                brent                conductor
daytona               doki                 galileo
ishtar               nimrod
siteplanner           talladega            vault
zookeeperlocks

The affinity rules also apply to the following IBM® Cloud Pak foundational services:

kafka                kafkaEntityOperator
zookeeper

Examples of affinity rules

The following custom resource snippet shows example settings for the apollo microservice:

apollo:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            topologyKey: "kubernetes.io/hostname"
            labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - apollo
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "kubernetes.io/arch"
              operator: In
              values:
              - amd64    
    tolerations: []

The node affinity rule ensures that the pod can be placed only on a node that has a label with the key kubernetes.io/arch and the value amd64.

The anti-affinity rule ensures that the pod cannot be placed on a node that is in the same availability zone as an already-running pod that has a label with the key app and the value apollo.

For more information about affinity rules, see Placing pods relative to other pods using affinity and anti-affinity rules.