Kubernetes node affinity is a feature that allows you to influence how pods are scheduled to specific nodes in a cluster based on ==custom labels assigned to the nodes==. It’s part of Kubernetes’ scheduling framework and enables fine-grained control over pod placement.

Types of Node Affinity

Node affinity is specified in a pod’s specification under the nodeAffinity field within affinity. It has three types:

1. RequiredDuringSchedulingIgnoredDuringExecution:

   • Pods must be scheduled on nodes that match the affinity rules.
   • If no nodes meet the criteria, the pod will not be scheduled.
   • The “ignored during execution” part means the pod won’t be evicted if the node’s labels change after scheduling.

   Example:

   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
         - matchExpressions:
           - key: "disktype"
             operator: In
             values:
             - "ssd"
   

2. PreferredDuringSchedulingIgnoredDuringExecution:

   • Pods prefer to be scheduled on nodes that match the affinity rules, but it’s not mandatory.
   • If no preferred nodes are available, the pod will still be scheduled on other nodes.

   Example:

   affinity:
     nodeAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 1
         preference:
           matchExpressions:
           - key: "region"
             operator: In
             values:
             - "us-west"
   

3. NodeSelector (Legacy Approach):

   • A simpler way to assign pods to nodes based on node labels.
   • Only supports equality-based matches (key: value).
   • Deprecated in favor of nodeAffinity due to its limited capabilities.

   Example:

   nodeSelector:
     disktype: ssd
   

Key Operators in Node Affinity

• In: Matches if the node’s label key has any of the specified values.
• NotIn: Matches if the node’s label key does not have the specified values.
• Exists: Matches if the node has the label key, regardless of its value.
• DoesNotExist: Matches if the node does not have the label key.
• Gt and Lt: Matches if the label value is greater or less than the specified value (only for numeric values).

Example: Combined Node Affinity

Below is a pod configuration that uses both required and preferred affinities:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: region
            operator: In
            values:
            - us-east
  containers:
  - name: nginx
    image: nginx

Use Cases of Node Affinity

1. Ensuring pods are deployed on nodes with specific hardware (e.g., SSD storage, GPUs).
2. Deploying pods closer to the required geographical region for performance.
3. Controlling pod placement in hybrid clusters with different node types (on-premise vs cloud).

Node affinity provides a more expressive and flexible way to control pod placement compared to nodeSelector.