Pod Placement

Several operators of the Stackable Data Platform permit the configuration of pod affinity as described in the Kubernetes documentation. If no affinity is defined in the product’s custom resource, the operators apply reasonable defaults that make use of the preferred_during_scheduling_ignored_during_execution property. Refer to the operator documentation for details.

Affinities can be defined at role level, group level or both. When defined at both levels, the two affinities are merged with the group affinity taking precedence. The resulting definition is then added to the corresponding pod template.

Affinities can be configured by adding an affinity property to the product’s custom resource, as shown below:

  podAffinity: ...
  podAntiAffinity: ...
  nodeAffinity: ...

The following example shows how to configure pod affinities at role level:

apiVersion: kafka.stackable.tech/v1alpha1
kind: KafkaCluster
  name: kafka-cluster
      affinity: (1)
        podAffinity: null (2)
        podAntiAffinity: (3)
          - podAffinityTerm:
                  app.kubernetes.io/component: broker
                  app.kubernetes.io/instance: kafka-cluster
                  app.kubernetes.io/name: kafka
              topologyKey: kubernetes.io/hostname
            weight: 70
        nodeAffinity: (4)
            - matchExpressions:
              - key: high-throughput-network
                operator: In
                - enabled

Here the pod placement for the broker Pods of an Apache Kafka cluster is configured as follows:

1 The pod assignment for all Pods of the brokers role.
2 No constraint is defined for clustering Pods.
3 A preferred constraint is defined for spreading brokers across cluster nodes. The intent here is to increase availability in case of node failures.
4 A required constraint for scheduling brokers on nodes with the fictional high-throughput-network label. Failing to satisfy this constraint will prevent the Kafka cluster from starting up.