Mastering Node Affinity in Kubernetes - A Practical Guide

Node Affinity in Kubernetes provides a powerful way to influence pod scheduling based on node attributes. In this hands-on guide, we’ll explore Node Affinity through a series of practical exercises. Let’s dive in!

1. Creating a Pod with Node Affinity

First, let’s create a pod with a Node Affinity rule that requires nodes with disktype=ssd:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-ssd
spec:
  containers:
    - name: nginx
      image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd

Save this as nginx-ssd.yaml and apply it:

kubectl apply -f nginx-ssd.yaml

2. Checking Pod Status

Let’s check the status of our pod:

kubectl get pods

You’ll notice that the pod is in a “Pending” state. Let’s investigate why:

kubectl describe pod nginx-ssd

In the events section, you should see messages indicating that no nodes match the affinity requirements.

3. Adding Label to Worker Node

Now, let’s add the required label to our worker01 node:

kubectl label nodes worker01 disktype=ssd

Check the pod status again:

kubectl get pods -o wide

You should now see that the nginx-ssd pod is scheduled on worker01.

4. Creating a Pod with Existence-based Node Affinity

Let’s create another pod, this time with a Node Affinity rule that only checks for the existence of the disktype label, without specifying a value:

apiVersion: v1
kind: Pod
metadata:
  name: redis-disktype
spec:
  containers:
    - name: redis
      image: redis
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: Exists

Save this as redis-disktype.yaml and apply it:

kubectl apply -f redis-disktype.yaml

5. Adding Label to Second Worker Node

Now, let’s add the disktype label to worker02, but without specifying a value:

kubectl label nodes worker02 disktype=

6. Verifying Pod Scheduling

Check the status of both pods:

kubectl get pods -o wide

You should see that:

• The nginx-ssd pod is scheduled on worker01 (which has disktype=ssd)
• The redis-disktype pod is scheduled on worker02 (which has the disktype label without a value)

Key Takeaways

1. Precise Control: Node Affinity allows you to define specific rules for pod placement based on node labels.
2. Flexibility: You can require exact label matches (In operator) or just the existence of a label (Exists operator).
3. Scheduling vs. Execution: The requiredDuringSchedulingIgnoredDuringExecution property ensures the rule is enforced during scheduling but doesn’t affect running pods if node labels change.
4. Label Management: Properly labeling your nodes is crucial for effective use of Node Affinity.

Conclusion

Node Affinity provides a powerful tool for controlling pod placement in your Kubernetes cluster. By using Node Affinity, you can ensure that pods are scheduled on nodes with the right characteristics for their workloads, whether that’s specific hardware, geographical location, or any other attribute you can represent with labels.

As you continue to work with Kubernetes, experiment with different Node Affinity rules and combinations of node labels. This will help you optimize your cluster resource utilization and ensure that your applications are running on the most suitable nodes.

Remember, while Node Affinity gives you fine-grained control over pod scheduling, it’s important to use it judiciously. Overly complex affinity rules can make your cluster harder to manage and potentially lead to scheduling conflicts. Always strive for a balance between control and simplicity in your Kubernetes configurations.

Happy Kuberneting!