0Pricing
DevOps Bootcamp · Lesson

Node Selectors and Affinity

Control where Pods are scheduled using node selectors and more expressive node and Pod affinity rules.

Node Selectors and Affinity is a free DevOps Bootcamp lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Control Where Pods Land

By default, Kubernetes schedules Pods on any available node. But what if you need more control?

Sometimes, you need Pods to run on specific nodes. Maybe those nodes have special hardware, licenses, or are in certain availability zones.

This lesson explores how to guide Kubernetes' scheduler using Node Selectors and Node Affinity.

Why Guide the Scheduler?

Imagine you have a database Pod that needs to run on a node with high-performance SSDs, or a GPU-intensive application that requires specific hardware.

You might also want to keep certain Pods away from each other for fault tolerance, or ensure they run on nodes with specific operating systems.

Kubernetes provides tools to express these scheduling preferences.

Nodes Have Labels

Before we can tell Pods where to go, nodes need identities! Kubernetes uses labels to identify nodes based on their characteristics.

  • Labels are key-value pairs, like disk=ssd or gpu=true.
  • You can add custom labels to your nodes using kubectl label nodes <node-name> <key>=<value>.
  • These labels are how we target specific nodes for Pod placement.

Node Selectors: Simple Match

The simplest way to constrain a Pod to a specific set of nodes is using nodeSelector.

It's a field in your Pod's specification that takes a map of key-value pairs. The Pod will only be scheduled on nodes that have all those labels.

It's like saying, "I need a node that is exactly this."

Node Selector in Action

Let's say we have nodes labeled disk=ssd. Here's how you'd make a Pod run only on those nodes:

apiVersion: v1
kind: Pod
metadata:
  name: ssd-app
spec:
  containers:
  - name: my-container
    image: nginx
  nodeSelector:
    disk: ssd

Node Affinity: Advanced Matching

While nodeSelector is straightforward, it's very strict. What if you want "preferred" nodes, or more complex matching rules?

Node Affinity offers more flexibility. It allows you to express "soft" or "hard" requirements for Pods to land on nodes with specific labels.

It uses a more powerful syntax with operators like In, NotIn, Exists, DoesNotExist, Gt, Lt.

Required & Preferred Affinity

Node affinity has two main types:

  • requiredDuringSchedulingIgnoredDuringExecution: The Pod must be scheduled on a node matching the rules. If no such node exists, the Pod won't be scheduled.
  • preferredDuringSchedulingIgnoredDuringExecution: The scheduler tries to find a node matching the rules, but if none are available, it will still schedule the Pod elsewhere. It's a "best effort" approach.

Required Node Affinity

Here's a Pod requiring a node with the label env=production. If no such node exists, the Pod will remain pending.

apiVersion: v1
kind: Pod
metadata:
  name: prod-app
spec:
  containers:
  - name: my-container
    image: httpd
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: env
            operator: In
            values:
            - production

Pod Affinity: Other Pods Matter

What if you want to schedule Pods based on where other Pods are running?

  • Pod Affinity: Attracts Pods to nodes where other Pods with specific labels are already running. Useful for co-locating services that communicate frequently.
  • Pod Anti-affinity: Repels Pods from nodes where other Pods with specific labels are running. Great for spreading replicas across nodes for high availability.

Pod Anti-affinity in Practice

This manifest ensures that no two Pods with the label app=my-web can be scheduled on the same node. This improves fault tolerance.

The topologyKey specifies the domain over which the anti-affinity applies (e.g., node, zone).

apiVersion: v1
kind: Pod
metadata:
  name: web-app-pod
  labels:
    app: my-web
spec:
  containers:
  - name: web-container
    image: busybox
    command: ["sh", "-c", "echo 'Hello from web-app'; sleep 3600"]
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: my-web
          topologyKey: "kubernetes.io/hostname"

Test Your Knowledge

You want to ensure your critical database Pods must not be scheduled on nodes with the label zone=dev. Which type of scheduling rule would you use for this strict exclusion based on node labels?

Recap: Scheduling Control

Great job! You've learned powerful ways to control where your Pods run:

  • Node Labels: Key-value pairs identifying node characteristics.
  • Node Selectors: Simple, strict matching to schedule Pods on nodes with specific labels.
  • Node Affinity: More flexible rules (required or preferred) for node selection, using operators.
  • Pod Affinity/Anti-affinity: Co-locating or separating Pods based on other Pods' locations.

These tools are crucial for optimizing resource usage, ensuring fault tolerance, and meeting specific application needs.

Frequently asked questions

Is the “Node Selectors and Affinity” lesson free?

Yes — the full text of “Node Selectors and Affinity” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Node Selectors and Affinity”?

Control where Pods are scheduled using node selectors and more expressive node and Pod affinity rules. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Node Selectors and Affinity” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Resource Requests and Limits
  2. Node Selectors and Affinity
  3. Taints and Tolerations
  4. Pod Priority and Preemption
← Back to DevOps Bootcamp