Node Affinity vs. Taints and Tolerations

Understanding the Difference

While taints and tolerations are primarily used for preventing pod scheduling on specific nodes, node affinity is used to attract pods to specific nodes based on their labels.

Taints and Tolerations:

• Taints: Mark a node as unsuitable for pods unless they have specific tolerations.

• Tolerations: Allow pods to tolerate specific taints, enabling them to run on tainted nodes.

• Guarantee: Taints and tolerations don't guarantee pod scheduling on a specific node; they only prevent scheduling on unsuitable nodes.

Node Affinity:

• Attracts pods to nodes based on label matching.

• Provides more granular control over pod placement.

• Can be used for both required and preferred scheduling.

  Taints and tolerations alone aren't sufficient for precise pod placement based on disk type. Node affinity offers more flexibility.

Properties in the Node affinity

• requireDuringSchedulingIgnoredDuringExecution: If the required label is removed, the scheduler will no longer find suitable nodes, and the pod will remain pending. Existing pods unaffected.

• preferredDuringSchedulingIgnoredDuringExecution: Removing the preferred label will simply reduce the likelihood of the pod being scheduled on nodes that previously matched the label. Existing pods unaffected.

requireDuringSchedulingIgnoredDuringExecution:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis
spec:
  containers:
  - image: redis
    name: redis
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

the pod is in the pending state because no node matches with the affinity

after labeling the node the pod got assigned

preferedDuringSchedulingIgnoredDuringExecution- property

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis-2
spec:
  containers:
  - image: redis
    name: redis-2
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - hdd

Exists Operator

The Exists operator in node affinity ensures that a pod is scheduled on any node possessing a specific label key, irrespective of its value, even if it's empty.

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis-3
spec:
  containers:
  - image: redis
    name: redis-3
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: Exists