DEV Community: Siddharth More

How Kubernetes Nodes Learn to Say No: Taints and Tolerations

Siddharth More — Tue, 22 Sep 2026 04:58:57 +0000

TL;DR

Taints go on nodes, tolerations go on pods. A tainted node rejects pods by default, and a toleration is what lets a specific pod back in. It is opposite of node selectors and affinity, where the pod was the one doing the choosing.
Three effects: NoSchedule, PreferNoSchedule, NoExecute.
NoExecute is the odd one out. It can evict pods that are already running, not just block new ones from landing.
Tolerating a taint doesn't mean a pod prefers that node. It just means the taint won't stop it from scheduling on the node.

Skip around if you already know the basics:

The problem this actually solves
Taints, tolerations, and the three effects
Where this actually shows up
What the scheduler's doing under the hood
Taints and tolerations vs node affinity
What goes wrong, and why
Try it yourself

WHY: the problem

Node selectors and affinity, from Part 2, are opt-in. A pod decides which nodes it wants, and the scheduler tries to honor that.

Sometimes you need the opposite. A node that rejects almost everything by default, unless a pod specifically says it's fine with that. Control-plane nodes are the classic example, you don't want regular application pods landing there and competing with the control plane for resources.

That's what taints and tolerations are for. Instead of a pod pulling toward a node, a node pushes pods away, and only pods that explicitly tolerate that push can get scheduled on it.

WHAT: taints, tolerations, and effects

A taint lives on a node. It's a key, a value, and an effect, written as key=value:effect.

A toleration lives on a pod. It lists the key, value, and effect the pod is willing to tolerate. If it matches, the taint doesn't block that pod.

Here's a way to picture it: a taint is bug repellent sprayed on a node. A toleration is a bug that's immune to that specific spray.

The three effects behave differently, and the analogy maps onto all of them:

NoSchedule - full-strength spray. Immune bugs land fine, everything else won't come near. Bugs that landed before the spray went down aren't touched either way, this only stops new arrivals.
PreferNoSchedule - a lighter dose. Bugs would rather avoid it, but if every other spot's taken, they'll land there anyway. Same as above, anything that landed earlier just stays put.
NoExecute - once the spray's applied, only immune bugs can land or stay. Every other bug gets rejected, whether it landed before the spray or was about to land after.

Setting a taint on a node:

kubectl taint nodes node-1 dedicated=gpu:NoSchedule

Tolerating it from a pod:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"
  containers:
  - name: nginx
    image: nginx

operator can also be Exists instead of Equal, if a pod should tolerate a key regardless of its value:

tolerations:
- key: "dedicated"
  operator: "Exists"
  effect: "NoSchedule"

A node isn't limited to one taint. When there are several taints, a pod has to tolerate every NoSchedule and NoExecute taint on that node to be allowed there, each one gets checked independently, and missing even one will keep the pod out. PreferNoSchedule taints don't count toward that requirement, they only ever affect scoring, never a hard block.

One more piece worth knowing: tolerationSeconds. It only applies to NoExecute, and it changes what the toleration itself means. Instead of tolerating the taint forever, it's saying "I tolerate this taint, but only for N seconds." The countdown starts the moment the taint shows up. Until it runs out, the pod counts as tolerating the taint and stays put. Once it expires, Kubernetes treats the pod as if it no longer tolerates that taint at all, and evicts it, exactly like a pod that never had a matching toleration in the first place.

tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "gpu"
  effect: "NoExecute"
  tolerationSeconds: 3600

📖 Docs: Taints and tolerations

WHEN: where this actually shows up

A few real situations where taints and tolerations show up:

Control-plane nodes, tainted by default so regular workloads stay off them.
Dedicated GPU or other specialized-hardware nodes, so only the workloads that need them land there.
Kubernetes itself uses this mechanism internally. When a node goes unreachable or stops responding, the node controller taints it automatically.

HOW: what's actually happening

Taints get checked during the same filtering phase from Part 1, just inverted. Normally filtering asks "can this node run the pod?" Here it's more like "has this node been told to reject the pod?" If yes and if there's no matching toleration on pod, the node gets filtered out, same as any other hard requirement.

PreferNoSchedule doesn't touch filtering at all. It works through scoring, same as preferred node affinity in Part 2, nudging the scheduler away from tainted nodes without ruling them out.

What happens on a node that's already running pods matters here, (I am intentionally repeating these points to make it stick to your memory) and the three effects don't behave the same way:

Taint a live node with NoSchedule or PreferNoSchedule, and nothing happens to pods already running there. These only affect future scheduling decisions, not the pods sitting there right now.
Taint it with NoExecute, and any pod without a matching toleration gets evicted, immediately, or after the grace period if tolerationSeconds is set. This is the one real exception to "scheduling is a one-time decision" from Part 1, worth closing that loop here.

The automatic tainting mentioned in previous section works off a fixed set of built-in keys, all under the node.kubernetes.io/ prefix: not-ready, unreachable, memory-pressure, disk-pressure, pid-pressure, network-unavailable, and unschedulable. The first two carry NoExecute, which is what actually triggers eviction the moment a node's condition flips.

That sounds like it should mean every pod in the cluster gets evicted the instant a node blips offline for a second, but Kubernetes doesn't let that happen by default. Every pod automatically gets a built-in toleration for not-ready and unreachable, capped at 300 seconds, whether or not one was written by hand. That's the buffer that keeps a brief network hiccup from turning into a mass eviction.

DIFFERENCE: taints and tolerations vs node affinity

Node affinity and taints solve a similar-sounding problem from opposite directions.

Affinity is a pod pulling toward a node it wants. Taints are a node pushing pods away by default, and a toleration is what lets a specific pod back in.

Here's where that difference actually shows up. Back in Part 2, node affinity let a pod prefer or require a specific node, but that was only the pod's side of the deal. Nothing stopped some other pod, one with no affinity rule at all, from landing on that same node too. Affinity never restricts the node itself.

Taints and tolerations exist for exactly that gap. If the goal is "no pod should schedule here unless it explicitly tolerates this" affinity can't do that on its own, that's what a taint is for.

Tolerating a taint doesn't mean a pod prefers that node either, or that it'll get scheduled there. It just means the taint won't block it. If the goal is a pod landing on GPU nodes specifically, not just being allowed there, tolerations usually get paired with node affinity on top. The taint keeps everyone else out, the affinity pulls the right pod in.

FAILURE: what goes wrong

The tolerate-doesn't-mean-prefer mix-up is the most common one. A pod with the right toleration can still land on an untainted node it has nothing to do with, because a toleration only removes a restriction, it doesn't express a preference.

The second one is more of a hazard than a misconception. Adding a NoExecute taint to a node that's already serving traffic can evict running pods with no warning, if that wasn't accounted for. Worth checking what's already running and what it tolerates before tainting a node people are relying on.

One more thing worth flagging now and covering properly later: DaemonSet pods tolerate several of these built-in taints automatically, which is part of why they keep running in places regular pods can't. More on that in Part 5.

PRACTICE: taint, tolerate, check

Taint a node:

kubectl taint nodes node-1 dedicated=gpu:NoSchedule

Deploy the toleration pod from the WHAT section, plus a plain one with no toleration at all:

apiVersion: v1
kind: Pod
metadata:
  name: plain-pod
spec:
  containers:
  - name: nginx
    image: nginx

kubectl apply -f gpu-pod.yaml
kubectl apply -f plain-pod.yaml
kubectl get pods -o wide

plain-pod should avoid node-1 entirely. Confirm the taint is actually there:

kubectl describe node node-1

Look for a Taints: line near the top of the output.

To remove the taint later:

kubectl taint nodes node-1 dedicated=gpu:NoSchedule-

That trailing - is easy to miss and just as easy to forget, so it's worth calling out on its own.

Next up, Part 4: pod affinity and anti-affinity, where instead of a pod caring about a node, it starts caring about other pods.

If anything here didn't land, or you'd explain it differently, drop a comment. Doubts and pushback are both welcome.

How does Kubernetes decide where GPU workloads or SSD-heavy databases should run? Published Part 2 of my Kubernetes scheduling series. This one covers node selectors and node affinity.

Siddharth More — Fri, 18 Sep 2026 10:57:35 +0000

Siddharth More

Sep 15

Kubernetes Scheduling 101: What Really Happens Before Your Pod Runs

#kubernetes #beginners #devops

4 min read

Telling the Kube-Scheduler Where Pods Can Run: Node Selectors and Node Affinity

Siddharth More — Fri, 18 Sep 2026 06:25:26 +0000

TL;DR

nodeSelector matches a pod to a node using labels. Simple, exact match, nothing fancier.
Node affinity does the same job with more expressive rules: In, NotIn, Exists, DoesNotExist, Gt, Lt.
Affinity comes in two flavors: required (hard rule) and preferred (soft nudge, weighted).
IgnoredDuringExecution means once the pod's running, changes to the node's labels don't affect it. No eviction, no re-check.

Skip around if you already know the basics:

The problem this actually solves
nodeSelector vs node affinity, explained
Where node selection actually matters
What the scheduler's doing under the hood
nodeSelector vs affinity, the trade-offs
What goes wrong, and why
Try it yourself

WHY: the problem

In Part 1, we saw kube-scheduler filter out nodes that can't run a pod, then score whatever's left. That's default. Most of the time, you don't need to touch it.

But sometimes the scheduler doesn't know something you know. Maybe only some of your nodes have GPUs. Maybe a database needs SSD-backed storage, and a spinning disk will tank its performance. Nothing in a plain pod spec tells the scheduler to care about that.

Node selectors and node affinity exist to close that gap. They let you attach the missing context yourself.

WHAT: the two mechanisms

Both work off the same idea: label your nodes, then tell the pod which labels to look for.

nodeSelector is the simple version. Give it one or more key-value pairs, and the pod only lands on a node that has every one of them.

apiVersion: v1
kind: Pod
metadata:
  name: nodeselector-pod
spec:
  nodeSelector:
    disktype: ssd
  containers:
  - name: nginx
    image: nginx

Node affinity does the same job, but with real operators instead of one flat match: In, NotIn, Exists, DoesNotExist, Gt, Lt.

Worth noting: there's no separate "node anti-affinity" field - using NotIn or DoesNotExist as the operator is what gets you that behavior, keeping a pod away from nodes that match instead of drawing it toward them.

It also splits into two types:

requiredDuringSchedulingIgnoredDuringExecution - a hard rule, functionally like nodeSelector but more expressive
preferredDuringSchedulingIgnoredDuringExecution - a soft rule with a weight (1-100) that nudges the scheduler's scoring, without blocking the pod if nothing matches

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

Read that as: this pod MUST land on an HDD node, and it would prefer us-east-1a, but it won't sit Pending for the zone to match.

One thing that trips people up: nodeSelectorTerms doesn't just take matchExpressions. It also takes matchFields, and the two aren't interchangeable.

matchExpressions matches against node labels, the same labels you set earlier. matchFields matches against node fields instead, things like the node's actual name in the API, not something someone labeled.

matchFields lets node affinity match against supported node fields rather than labels. A common example is matching metadata.name to target a particular node.

apiVersion: v1
kind: Pod
metadata:
  name: pinned-to-node-1
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - node-1
  containers:
  - name: nginx
    image: nginx

Worth being honest about this one: it's rarely the right call. Hard-coding a node name defeats the whole point of a label-based system, and if that node ever gets replaced, your pod just stops scheduling. Reach for matchExpressions and labels first.

There's one more thing worth nailing down: how multiple expressions and values actually combine. It's not obvious just from looking at the YAML.

Inside one matchExpressions list, every entry has to match. That's an AND.

Inside one expression's values list, matching any single value is enough. That's an OR.

And across separate entries in nodeSelectorTerms itself, only one term has to fully match. That's another OR, one level up.

Stacked together, it looks like this:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: In
            values:
            - us-east-1a
            - us-east-1b
          - key: disktype
            operator: In
            values:
            - ssd
        - matchExpressions:
          - key: zone
            operator: In
            values:
            - us-west-2a

Read that as:
(zone is (us-east-1a OR us-east-1b), AND disktype is ssd)
OR
(zone is us-west-2a).

It looks like a lot stacked up like that, but it's really just three separate rules, each with its own logic, nested inside each other.

You can also use both nodeSelector and nodeAffinity,in that case a node must satisfy both before the Pod can be scheduled.

📖 Docs: nodeSelector · node affinity

WHEN: where node selection actually matters

A few real situations where controlling Pod placement makes sense, regardless of which mechanism you reach for:

GPU workloads that should only run on GPU-equipped nodes
Databases or caches that need SSD-backed storage
Workloads you want kept in a specific zone, without hard-blocking if that zone's full
Compliance or licensing rules that pin certain workloads to certain hardware

If none of that applies, the scheduler's default behavior is usually fine on its own.

HOW: what's actually happening

nodeSelector and the required affinity rule both get evaluated during the filtering phase from Part 1. Any node that doesn't match gets thrown out before scoring even starts.

The preferred affinity rule works differently. It doesn't touch filtering at all. Once the feasible set is decided, the scheduler adds the rule's weight to a node's score if that node matches. Highest score wins, same as any other scoring factor.

Both mechanisms share one behavior worth calling out: they're ignored during execution. The rule only gets checked once, at scheduling time. If someone relabels the node an hour later, nothing happens to the pod already running there.

TRADE-OFFS: nodeSelector vs affinity

nodeSelector is less YAML and easier to read. If the requirement really is "must have this one label," there's no reason to reach for affinity instead.

The moment you need OR logic, negation, or a "prefer but don't require," nodeSelector can't do it and affinity can. That flexibility costs a bit more nesting, but there's no real downside beyond that.

One thing neither of these solves: pod-to-pod placement, like "run this next to that" or "spread these apart." That's pod affinity and anti-affinity, coming in Part 4. And if the goal is nodes actively rejecting pods rather than pods choosing nodes, that's taints and tolerations, next up in Part 3.

FAILURE: what goes wrong

The most common failure: you set a required rule, no node matches it, and the pod remains Pending until a suitable node becomes available or the scheduling constraints change. There's no obvious error, just a pod that never starts. kubectl describe pod, specifically its Events section, is where you'll actually see the scheduling failure reason.

The second one catches people off guard: because these rules are IgnoredDuringExecution, relabeling a node does nothing to pods already scheduled there. If you're expecting a label change to trigger a reschedule, it won't. You'd have to delete and recreate the pod yourself.

PRACTICE: label, deploy, check

Label two nodes differently:

kubectl label node node-1 disktype=ssd
kubectl label node node-2 disktype=hdd
kubectl get nodes --show-labels

Save the two pod specs from the WHAT section as nodeselector-pod.yaml and affinity-pod.yaml, then deploy both:

kubectl apply -f nodeselector-pod.yaml
kubectl apply -f affinity-pod.yaml
kubectl get pods -o wide

For the nodeSelector pod, describe shows it directly:

kubectl describe pod nodeselector-pod

Look for a Node-Selectors: line. It'll show disktype=ssd.

kubectl describe pod is useful for inspecting scheduling information and events, but it isn't the best way to inspect the complete affinity configuration. To see the exact affinity rules attached to the Pod, inspect the Pod spec directly:

kubectl get pod affinity-pod -o yaml | grep -A 16 affinity

That's the only reliable way to confirm what's actually attached to a running pod.

Next up, Part 3: taints and tolerations, where instead of pods choosing nodes, nodes start rejecting pods.

For those who read till end, I appreciate your patience since this was bit complex, and I too had to struggle to shape this article.

If anything here didn't land, or you'd explain it differently, drop a comment. Doubts and pushback are both welcome.

Kubernetes Scheduling 101: What Really Happens Before Your Pod Runs

Siddharth More — Tue, 15 Sep 2026 05:59:06 +0000

TL;DR

Scheduling means binding a pod to a node by setting spec.nodeName. You can set this yourself (manual scheduling), or let kube-scheduler do it.
kube-scheduler decides in two steps: filtering out nodes that can't run the pod, then scoring the ones that can.
A pod stays on its node for life once scheduled, with one exception: a NoExecute taint can evict it later. More on that in Part 3.
Manual scheduling via nodeName skips the filter-and-score process entirely, so it also skips the safety checks that come with it.

You run kubectl apply, and the pod just shows up somewhere. But how does Kubernetes actually pick that node?

This is Part 1 of a series on Kubernetes scheduling. Before we get into node selectors, taints, and affinity rules, we need to understand what scheduling actually is. And the easiest way to understand it is to see what happens when you skip it.

What scheduling actually means

Scheduling comes down to one thing: binding a pod to a node. That means writing the node's name into the pod's spec.nodeName field. Once that field is set, the kubelet on that node picks up the pod and runs it.

Here's the part most people miss. This binding happens once, at creation time. Kubernetes doesn't sit there watching your pods and moving them around as conditions change.

Once a pod lands on a node, it stays there for its lifetime. Even if a better node shows up five minutes later.

* There's one exception to that "stays there forever" claim. Taints with the NoExecute effect can actively kick a running pod off a node if it doesn't tolerate that taint. We'll get into NoExecute in Part 3. For now, just keep that asterisk in the back of your mind.

Manual scheduling: setting `nodeName` yourself

Since binding a pod to a node is just setting a field, you can set it yourself.

apiVersion: v1
kind: Pod
metadata:
  name: manually-placed-pod
spec:
  nodeName: k8s-worker-1
  containers:
  - name: nginx
    image: nginx

Apply that, and the pod goes straight to k8s-worker-1. No decision-making involved. This is literally what the docs call manual scheduling.

But here's the catch. When you set nodeName yourself, you skip the whole decision-making process. And that costs you a few safety checks:

No resource check. If k8s-worker-1 doesn't have enough CPU or memory, the pod doesn't get rejected. It just fails to run properly, or gets stuck.
No existence check. Typo the node name, and there's no scheduler around to catch it. The pod sits in Pending, and the reason isn't obvious at a glance.
No taint awareness. If k8s-worker-1 has a taint the pod doesn't tolerate, manual placement ignores it completely. It's a handy tool for demos and edge cases. But it's not something you build on.

📖 Docs: Assigning pods to nodes using nodeName

Enter kube-scheduler: the two-phase process

For every other pod, nodeName starts out empty. Filling it in is kube-scheduler's job. It does that in two steps.

Filtering. kube-scheduler looks at every node and throws out the ones that can't run the pod at all. Not enough CPU or memory? Out. A taint the pod doesn't tolerate? Out. Port conflict, volume mismatch, whatever hard requirement it fails? Out.

Whatever's left after that is the feasible set. Every node in it can technically run the pod.

Scoring. Now kube-scheduler ranks those feasible nodes against each other. It might favor nodes with more free resources, to spread load around. It might favor a node that already has the image cached, so the pod starts faster. There are other scoring rules too, depending on how your cluster's set up.

Whichever node scores highest wins. That's when nodeName actually gets set - by the scheduler, not by you.

This filter-then-score process is exactly what manual scheduling skips. Node selectors, taints, affinity, all of it works by shaping what goes into this process. None of it replaces it.

📖 Docs: kube-scheduler's Filter-then-Score process

Demo: manual vs scheduler-driven placement

Let's see this side by side. Deploy two pods that are basically identical, except one has nodeName set and one doesn't.

# manual-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: manual-pod
spec:
  nodeName: k8s-worker-1
  containers:
  - name: nginx
    image: nginx
---
# scheduled-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: scheduled-pod
spec:
  containers:
  - name: nginx
    image: nginx

Apply both. Then check where they landed:

kubectl get pods -o wide

Both should be Running, maybe on different nodes. Now look at the events.

kubectl describe pod scheduled-pod

You'll see a Scheduled event, something like Successfully assigned default/scheduled-pod to <node>. That's a record of the scheduler actually making a decision.

kubectl describe pod manual-pod

No Scheduled event at all. As far as the scheduler's concerned, it was never involved. The kubelet on k8s-worker-1 just picked up a pod that already had its name written on it.

That missing event is the clearest proof you'll get that these are two different code paths, not two flavors of the same thing.

If you don't see it there, events expire after a while and describe won't always show old ones. Run kubectl get events instead and look for the Scheduled reason.

Manual scheduling, and what it skips

Calling nodeName "manual scheduling" is fine, and it's the term you'll see everywhere, including in CKA material. The label isn't the important part.

What matters is what it skips. nodeName doesn't run through kube-scheduler's filter-then-score engine at all, it just hands the kubelet a node and says go.

That's the distinction that matters for the rest of this series. Node selectors, node affinity, taints and tolerations, pod affinity, none of them bypass the scheduler. They all work with it, either by narrowing the feasible set or nudging the score. Keep that in mind and the rest of this series will click faster.

Next up, Part 2: node selectors and node affinity, the simplest way to actually influence the scheduler instead of skipping it.

Kubernetes and Swap: Why It's Disabled by Default (And How That's Changing) - A kubeadm Debugging Story

Siddharth More — Mon, 07 Sep 2026 17:32:53 +0000

If you've ever bootstrapped a Kubernetes cluster from scratch, you've probably hit this error at least once:

err="failed to run Kubelet: running with swap on is not supported, please disable swap or set --fail-swap-on flag to false"

I ran into it while setting up my own practice cluster on LXC containers using kubeadm. Everything else checked out - containerd (container runtime), cgroup drivers, network config, but kubelet flatly refused to start. The reason: swap was still enabled.

This post walks through why that happens, an LXC-specific nuance worth knowing, and what's actually changed in recent Kubernetes releases around swap support.

Quick Refresher: What Is Swap?

Swap is disk space (a partition or file) that the Linux kernel uses as overflow when physical RAM runs out, moving inactive memory pages to disk to free up RAM - slower than RAM, but it acts as a safety net against out-of-memory crashes.

Why Kubernetes Disables Swap By Default

By default, kubelet requires swap to be turned off on every node. If swap is on, kubelet won't even start, and you'll get exactly the error above.

The reasoning is about predictability. Kubernetes' scheduler and eviction system rely on accurate memory accounting to decide where to place pods and when to evict them under pressure. Swap breaks that: a pod could look like it's within its memory limit while actually thrashing against disk-backed swap, invisible to the scheduler. So historically, the safest default was simple: no swap, period.

The LXC-Specific Gotcha: Swap Isn't Namespaced

Here's a detail worth knowing if you're running Kubernetes nodes as LXC containers rather than full VMs: swap is a global, host-wide kernel resource - not namespaced like CPU, memory limits, or networking.

So /proc/swaps inside an LXC container reflects the host's swap state, not a per-container one. If the host has swap enabled, every LXC container on it - including your Kubernetes node - sees swap as "on" regardless of container-level settings. You can't hide it from the container alone.

Your real options in this setup:

Disable swap on the host (swapoff -a + comment out the entry in /etc/fstab) - the cleanest fix. (But I won't recommend)
Tell kubelet to tolerate swap being present via config (see next section) (Recommended).
Restrict swap at the cgroup level (memory.swap.max=0 on cgroup v2) as an extra safety net - though it limits usage, not detection, so kubelet still needs to be told to tolerate it.

How I Fixed It

Since I wanted to move fast without reprovisioning a separate swap-free host, I set failSwapOn: false in the kubelet configuration:

# /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false

Restart kubelet, and it starts up right away - running in NoSwap mode by default.

The Bigger Picture: KEP-2400 and Swap Support Going GA

While debugging this, I learned that Kubernetes' stance on swap has actually been evolving for years - and it's more nuanced than "swap = broken."

KEP-2400 (Node Memory Swap Support) started as alpha in Kubernetes 1.22 (2021) and reached GA in Kubernetes 1.34 (2025). It introduces the NodeSwap feature, controlled via kubelet configuration:

failSwapOn: false
memorySwap:
  swapBehavior: LimitedSwap   # or NoSwap

The two supported behaviors:

NoSwap - the default. Kubernetes workloads (pods) don't and can't use swap, but processes outside Kubernetes' scope - system daemons, and even kubelet itself - still can. This protects the node from system-level memory spikes without giving that safety net to workloads.
LimitedSwap - pods get a bounded, proportional amount of swap based on their memory requests, via cgroup v2. Guaranteed and BestEffort QoS pods get zero swap by design; only Burstable pods (requests < limits) get meaningful access.

An earlier mode, UnlimitedSwap, was removed in 1.30 - it let a single misbehaving container consume unlimited swap and potentially crash the node.

GA Doesn't Mean "Auto-Enabled"

Going GA doesn't mean kubelet now silently tolerates swap on upgrade. On the latest version, swap left on with no config changes still triggers the same startup error - the safe default hasn't moved. What's changed is there's now a stable, supported way to opt in, useful for things like JVM-based apps (Jenkins, SonarQube) that reserve large amounts of memory but rarely touch all of it, or as a buffer against short memory spikes instead of an outright OOMKill.

Swap on Kubernetes nodes is still an advanced, deliberate choice - control-plane nodes in particular are recommended to stay swap-free.

Takeaways

Kubelet requires swap off by default - unchanged even with KEP-2400 reaching GA in 1.34.
On LXC containers, remember swap is a host-level kernel resource, not namespaced.
failSwapOn: false gets kubelet running quickly (default NoSwap), but disabling swap at the host level is still the standard fix for a dedicated node.
If you want to use swap intentionally, LimitedSwap gives a bounded, QoS-aware way to do it - worth exploring for memory-heavy, low-active-usage workloads.

This is my first dev.to post, so if I got something wrong or oversimplified, or if you've handled swap differently on your clusters, I'd genuinely appreciate the correction - drop a comment below.

DEV Community: Siddharth More

How Kubernetes Nodes Learn to Say No: Taints and Tolerations

WHY: the problem

WHAT: taints, tolerations, and effects

WHEN: where this actually shows up

HOW: what's actually happening

DIFFERENCE: taints and tolerations vs node affinity

FAILURE: what goes wrong

PRACTICE: taint, tolerate, check

How does Kubernetes decide where GPU workloads or SSD-heavy databases should run? Published Part 2 of my Kubernetes scheduling series. This one covers node selectors and node affinity.

Kubernetes Scheduling 101: What Really Happens Before Your Pod Runs

Telling the Kube-Scheduler Where Pods Can Run: Node Selectors and Node Affinity

WHY: the problem

WHAT: the two mechanisms

WHEN: where node selection actually matters

HOW: what's actually happening

TRADE-OFFS: nodeSelector vs affinity

FAILURE: what goes wrong

PRACTICE: label, deploy, check

Kubernetes Scheduling 101: What Really Happens Before Your Pod Runs

What scheduling actually means

Manual scheduling: setting nodeName yourself

Enter kube-scheduler: the two-phase process

Demo: manual vs scheduler-driven placement

Manual scheduling, and what it skips

Kubernetes and Swap: Why It's Disabled by Default (And How That's Changing) - A kubeadm Debugging Story

Quick Refresher: What Is Swap?

Why Kubernetes Disables Swap By Default

The LXC-Specific Gotcha: Swap Isn't Namespaced

How I Fixed It

The Bigger Picture: KEP-2400 and Swap Support Going GA

GA Doesn't Mean "Auto-Enabled"

Takeaways

Manual scheduling: setting `nodeName` yourself