Configure Pod Scheduling

Overview

To get the optimal performance out of StreamNative Platform, you can control how to schedule the component Pods on Kubernetes nodes to achieve one or more of the following purpose:

To ensure Pods are not scheduled on the same node as other intensive applications or critical workloads.
To schedule Pods on a dedicated node.
To select the nodes with the most suitable hardware for the Pods.
To avoid a situation where multiple Pods are competing for the same resources (storage or network).

StreamNative Platform supports the following features for scheduling StreamNative component Pods on Kubernetes nodes:

Taints and tolerations

Taints and tolerations work together to ensure that Pods are not scheduled onto specific nodes in Kubernetes.

Taints are applied to a node, and tolerations are applied to Pods. The Pods that do not declare a toleration for a taint cannot be scheduled to that node.

Affinity and anti-affinity

Taints and tolerations make sure that Pods are not scheduled onto the nodes, but they do not guarantee that Pods get scheduled onto the node where you intend them to run.

To schedule the Pods on a specific node, use another Kubernetes feature, affinity and anti-affinity. StreamNative Platform supports the following types of Kubernetes affinity features:

Pod anti-affinity

Pod anti-affinity

The Pod anti-affinity allows you to specify that a set of Pods are scheduled away from one another on different nodes, availability zones, or several other potential topology domains. For example, you can use Pod anti-affinity to ensure that the BookKeeper Pods do not share nodes with other resource-intensive or critical workloads.

`nodeSelector`

nodeSelector is a simple Pod scheduling feature that allows scheduling a Pod onto a node. You can add the nodeSelector field to your Pod specification and specify the node labels you want the target node to have. Therefore, the Pod can be scheduled onto the nodes that have the specified labels.

Configure taints and tolerations for StreamNative components

This section describes how to configure taint and tolerations for StreamNative components.

Configure taints

For details about placing a taint on a node using the kubectl taint nodes command, see Taint and Toleration.

Configure tolerations

When a Pod is configured with a toleration, the Pod "tolerates" the taint that matches the triple <key, value, effect> using the matching operator <operator>.

When a Pod tolerates a node taint, the Pod can be scheduled to the node.

Configure the tolerations property of the StreamNative components in the values.yaml YAML file as follows, and update the resource.

<component>:
  tolerations:
    - effect: # --- [1]
      key: # --- [2]
      operator: # --- [3]
      value: # --- [4]
      tolerationSeconds: # --- [5]

[1] effect: indicate what to do with intolerant Pods. Allowed values are NoSchedule, PreferNoSchedule, NoExecute.
When it is set to an empty value, this toleration matches all taints.
[2] key: the taint key that the toleration applies to.
If the key is empty, the operator field must be set to Exists. This combination means to match all values and all keys.
[3] operator: the match operator to compare key to the value. Allowed operators are Exists and Equal. By default, it is set to Equal.
Exists is equivalent to a wildcard for value, so that a Pod can tolerate all taints of the key.
[4] value: the taint value the toleration matches to. If the operator is set to Exists, the value must be empty.
[5] tolerationSeconds: the time period that the toleration tolerates the taint. This field is available only when effect is set to NoExecute. Otherwise, this field is ignored.
By default, it is not set, which means to tolerate the taint forever (not evicting the taint).
Zero and negative values are treated as 0 (evicting the taint immediately).

For example, the following taint is placed on node1:

kubectl taint nodes node1 myKey=myValue:NoSchedule

The following value snippet matches the taint created above, and the Pod can be scheduled onto the node:

broker:
  tolerations:
    - key: 'myKey'
      operator: 'Equal'
      value: 'myValue'
      effect: 'NoSchedule'

For more information on the fields, see Taint and Toleration.

Configure Pod anti-affinity for StreamNative components

The section describes how to configure Pod anti-affinity schedule rules, for example, whether to co-locate or to avoid putting a Pod in the same node or zone as some other Pods already running on the node.

Currently, StreamNative Platform only supports anti-affinity rules to avoid scheduling the Pods of a same component to the same nodes.

Enable Pod anti-affinity

By default, all the Pulsar core components (zookeeper, bookkeeper, autorecovery, broker, proxy) enable Pod anti-affinity.

To disable Pod anti-affinity, you can configure the <component>.affinity.anti_affinity property of the StreamNative components in the values.yaml YAML file as follows, and update the resource.

<component>:
  affinity:
    anti_affinity: false

Configure anti-affinity rule type

StreamNative provides two types of Pod anti-affinity rules:

requiredDuringSchedulingIgnoredDuringExecution: to be scheduled onto a node, a Pod must satisfy these rules.
preferredDuringSchedulingIgnoredDuringExecution: the scheduler schedules the Pods, which satisfy the specified affinity expressions, to nodes , but it may choose a node that violates one or more of the expressions. The node with the greatest sum of weights is most preferred.

To specify the rule type, you can configure the <component>.affinity.type property of the StreamNative components in the values.yaml YAML file as follows, and update the resource.

<component>:
  affinity:
    type: requiredDuringSchedulingIgnoredDuringExecution

Configure `nodeSelector` for StreamNative components

Before scheduling Pods onto nodes in Kubernetes using nodeSelector, you need to add a label to the target node. For details about placing a label on a node using the kubectl label nodes command, see add a label to a node.

For example, the following label is placed on node1:

kubectl label nodes node1 cloud.google.com/gke-nodepool: default-pool

Then, you can add the <component>.nodeSelector field for a specific StreamNative component with the node's label and the Pod can be scheduled onto the target node.

<component>:
  nodeSelector:
    cloud.google.com/gke-nodepool: default-pool