Quick Summary: If your kubeadm init command is crashing due to swap memory or preflight errors, you aren’t alone. I’m breaking down why Kubernetes demands total control of your RAM and providing three ways to bypass the checks—from a temporary hack to the production-grade solution.

So, You Thought Kubeadm Would Be Easy? Handling the ‘Swap’ & Preflight Headaches

I still remember the first time I tried to provision a bare-metal cluster for a high-frequency trading client at TechResolve. We had these beastly machines, let’s call the primary one prod-fin-master-01, loaded with NVMe drives and ridiculous amounts of RAM. I had the networking planned out, the VIPs configured, and I felt like a wizard. I typed kubeadm init, leaned back in my chair, and waited for the magic.

Instead of magic, I got a wall of red text. The kubelet refused to start. The preflight checks screamed at me about swap memory and mismatched container runtime interfaces. It’s a humbling moment when you realize that despite years of cloud experience, a default Linux setting can bring your architecture to its knees. If you are staring at a [ERROR Swap]: running with swap on is not supported message right now, take a breath. We’ve all been there.

The “Why”: Why K8s Hates Your Swap File

Here is the reality check: Kubernetes is a control freak. It needs to know exactly how much memory a Pod is using so the scheduler can make intelligent decisions.

When you have swap memory enabled on a Linux host, the OS might move pages of memory from RAM to the hard drive when pressure is high. While this is great for a standard web server, it ruins Kubernetes’ math. K8s can’t distinguish between “memory used” and “memory swapped.” This leads to performance degradation that is invisible to the scheduler, or worse, the Out-Of-Memory (OOM) killer terminating the wrong processes because it thinks you have more headroom than you actually do.

The kubelet is programmed to fail fast if it detects swap is active. It’s not a bug; it’s a safety feature.

The Fixes: From Hacky to Production-Ready

Depending on whether you are running a quick lab on dev-test-01 or building the next production cluster, you have options. Here are the three ways I handle this.

Solution 1: The Quick Fix (The “I Just Want It To Run”)

If you are in the middle of a demo or just learning, you don’t need to overengineer the solution. You just need to turn swap off instantly for the current session. This will let kubeadm proceed, but be warned: if you reboot the server, swap comes back, and your kubelet will die.

Run this on all your nodes:

sudo swapoff -a

That’s it. Retry your init command. It usually works immediately after this.

Solution 2: The Permanent Fix (The Production Standard)

For prod-db-01 or any server you actually care about, you need to disable swap at the boot level. This ensures that if the server restarts for a kernel patch, your cluster comes back up automatically.

Step 1: Disable it immediately.

sudo swapoff -a

Step 2: Edit your filesystem table. You need to comment out the swap entry.

# Open the fstab file
sudo vi /etc/fstab

# Look for a line that looks like this:
# /dev/mapper/cs-swap  none  swap  defaults  0 0

# Add a hash (#) to the start of the line to comment it out:
# # /dev/mapper/cs-swap  none  swap  defaults  0 0

Pro Tip: After editing /etc/fstab, always run mount -a just to ensure you didn’t accidentally break the syntax of other mounts. A bad fstab means a server that won’t boot.

Solution 3: The ‘Nuclear’ Option (The Config Bypass)

Sometimes, you are in a constrained environment (like a weird VM setup provided by IT) where you literally cannot disable swap, or you are testing a feature specifically related to swap (which is technically in beta for newer K8s versions). You can force kubeadm to shut up and do it anyway.

I call this the Nuclear Option because you are telling the safety systems to look the other way. Use this with caution.

You pass a flag to ignore the specific preflight error:

sudo kubeadm init --ignore-preflight-errors=Swap

Alternatively, if you are using a configuration file (which you should be doing for reproducible builds), you can add it to your InitConfiguration:

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  ignorePreflightErrors:
  - Swap

If you take this route, you must also configure the Kubelet on that node to accept swap, otherwise, it might still crash loop after the control plane initializes. You’ll need to edit /etc/default/kubelet (or your systemd unit) to include --fail-swap-on=false.

My advice? Stick to Solution 2. Treat your bare metal like cattle, disable the swap, and let the Kubernetes scheduler do the job it was designed to do.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions