1. Creating a Pod with Node Affinity#

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

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: nginx-ssd
5
spec:
6
  containers:
7
    - name: nginx
8
      image: nginx
9
  affinity:
10
    nodeAffinity:
11
      requiredDuringSchedulingIgnoredDuringExecution:
12
        nodeSelectorTerms:
13
          - matchExpressions:
14
              - key: disktype
15
                operator: In
16
                values:
17
                  - ssd

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

1
kubectl apply -f nginx-ssd.yaml

2. Checking Pod Status#

Let’s check the status of our pod:

1
kubectl get pods

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

1
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:

1
kubectl label nodes worker01 disktype=ssd

Check the pod status again:

1
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:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: redis-disktype
5
spec:
6
  containers:
7
    - name: redis
8
      image: redis
9
  affinity:
10
    nodeAffinity:
11
      requiredDuringSchedulingIgnoredDuringExecution:
12
        nodeSelectorTerms:
13
          - matchExpressions:
14
              - key: disktype
15
                operator: Exists

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

1
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:

1
kubectl label nodes worker02 disktype=

6. Verifying Pod Scheduling#

Check the status of both pods:

1
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!