Kubernetes on Tom Meurs

Chaos Engineering: Breaking Your Cluster to Make It Stronger

Tue, 28 Apr 2026 19:45:00 +0100

TL;DR Chaos engineering is breaking your own cluster on purpose, with the hypothesis written down first and a rollback ready. I run it on the homelab with Litmus: a weekly pod-delete, a monthly node drain, a game day every quarter. So far it has found four things the dashboard would never have shown me.

My dashboard is a wall of green. Pods running, replicas matched, CPU comfortable, no alerts firing. I look at it and get that small hit of “everything’s fine.” And mostly it is. The cluster’s been up for weeks and nothing has fallen over.

Longhorn vs Rook-Ceph: Kubernetes Storage Compared

Mon, 20 Apr 2026 19:38:00 +0100

TL;DR Longhorn and Rook-Ceph both give you replicated block storage that survives a node dying. Longhorn is one Helm install and a UI that shows you what a volume is doing. Rook-Ceph is Ceph with a Kubernetes operator around it, so you get block, object and filesystem storage, and the operations that come with them. I run Longhorn on three nodes. Below is why, and when I’d switch.

Run your first stateful workload on a self-hosted cluster and you find out fast that nobody hands out PersistentVolumes for free. There’s no cloud provider storage class to lean on. You’ve got your nodes, their disks, and a Postgres pod that won’t schedule. An hour of reading later you’re left with two names that keep coming up. Longhorn and Rook-Ceph .

Cilium: eBPF Networking for Kubernetes

Wed, 08 Apr 2026 20:23:00 +0100

TL;DR Cilium is the CNI I run in every cluster. It replaces kube-proxy and its iptables chains with eBPF programs in the kernel, enforces network policies on identity and on HTTP paths, and Hubble shows me every flow and every drop. WireGuard between the pods, BGP to the switch, no sidecars. My production values are at the bottom.

The first time a service stopped resolving in one of my clusters, I spent an evening reading iptables chains. Hundreds of rules, generated by kube-proxy, evaluated top to bottom. I never found the problem. I restarted the node and it went away.

NixOS vs Talos for Kubernetes Nodes: Two Flavors of Immutable Infrastructure

Sun, 15 Mar 2026 20:37:00 +0100

TL;DR Talos and NixOS are both declarative and both can be immutable, and that’s about where the resemblance stops. Talos runs Kubernetes and nothing else, with no shell to drift in. NixOS is a full Linux where the whole machine is one Nix config. I run Talos on my cluster nodes and NixOS on the machines around them, and this post is how I got to that split.

I’ve written about Talos Linux as the immutable Kubernetes OS, and I’ve compared Arch vs NixOS for workstations. After both, the same question kept arriving in my inbox. Why not NixOS on the Kubernetes nodes too?

Talos Linux: The Immutable Kubernetes OS That Changed How I Think About Nodes

Wed, 11 Mar 2026 21:15:00 +0100

TL;DR Talos Linux is a Linux that runs Kubernetes and nothing else. No SSH, no shell, no package manager. Every change goes through an API and a YAML file in Git. I’ve run my nodes on it for three years, and this post is how I stopped missing the shell.

The first time I tried to SSH into a Talos node, I got nothing. No shell, no connection, not even a login prompt. I sat there for a minute wondering how I was supposed to debug a machine I couldn’t get into.

Data-Driven Kubernetes Migration: Why You Need Metrics Before You Move

Sun, 08 Feb 2026 14:00:00 +0100

TL;DR An e-commerce client moved a PHP monolith to EKS in October, two weeks before Black Friday, with resource limits guessed from the old server specs. Mid-morning the pods hit their memory limit, died in a loop for four hours, and the estimate was €240,000 in lost revenue. The second half is how to get those numbers from load tests and VPA recommendations instead of guessing them.

“We want to migrate to Kubernetes by November.”

K8sGPT with a Local 70B Model on Apple Silicon

Thu, 05 Feb 2026 14:00:00 +0100

TL;DR I pointed K8sGPT at a Llama 3.3 70B model running on a Mac Studio in my own office, so no cluster metadata leaves the network, and fed it three broken workloads. It found all three and wrote fixes I’d accept from a colleague, except for the resource numbers, which it made up. Assisted diagnosis works, at 25 seconds a query. Autonomous cluster management is still marketing, and the security section is why I wouldn’t let a model change anything on its own.

When not to use Kubernetes

Sat, 17 Jan 2026 10:00:00 +0100

I write a lot about Kubernetes, and I run it at home every day. I like it.

So it might surprise you that I spend a fair amount of my time talking people out of it.

The situation I keep walking into goes like this. A small team, one product, a roadmap full of features customers are waiting for, and someone has decided the first milestone is a Kubernetes cluster. Three nodes minimum, etcd, a CNI , an ingress controller, cert-manager, a monitoring stack. Weeks of work before a single customer sees anything. Everyone nods along, because that’s what a serious setup is supposed to look like.

Unbreakable - My Fascination.

Tue, 23 Dec 2025 20:00:00 +0100

As a kid I called the things that fascinated me unbreakable. Indestructible never fit, because indestructible means it never breaks. Unbreakable means it keeps working after it breaks.

I know exactly when it started. A photo of an A-10 Thunderbolt II back from a mission with half a wing gone, the tail in tatters and the fuselage full of holes. It still brought its pilot home.

Luck had nothing to do with it. Somebody sat at a drawing board years before that mission and decided the plane had to come home looking like that.

Running Kubernetes Offline: Edge Computing Without Internet

Tue, 04 Mar 2025 20:47:00 +0100

What happens when your Kubernetes cluster can’t reach the internet? I don’t mean a slow connection. I mean no connection at all. Ships at sea. Remote mining sites. Factory floors with air-gapped networks. Military deployments.

For a lot of people that sounds exotic, like a problem someone else has. I treat it as a baseline design requirement, and I’ll explain why it makes my homelab better even though I almost never actually pull the cable.

Graceful Degradation in Kubernetes: What Happens When Components Fail

Thu, 20 Feb 2025 14:22:00 +0100

Everyone repeats the line that Kubernetes is self-healing. Pods die, they come back. Nodes drop, workloads reschedule. The system reconciles itself toward the state you declared, and most days you never have to think about it.

Then one day the thing doing the healing is the thing that broke. The API server is down. etcd won’t respond. The scheduler is wedged. Now what?

This is the question I actually care about, because “self-healing” is only useful if I understand its edges. I want to know what degrades gracefully and what takes the whole cluster with it. So I’ve run my clusters through a lot of failures on purpose: planned, unplanned, and a few “hold my beer” experiments on hardware I didn’t mind losing. Here is what actually happens when each piece breaks, and why most of it matters less than people fear.

How etcd Actually Works: The Heart of Your Kubernetes Cluster

Mon, 27 Jan 2025 21:47:00 +0100

When something goes wrong in Kubernetes, the trail usually leads back to etcd. API server timing out? Check etcd. Pods stuck in pending? Might be etcd. Cluster feels sluggish? Probably etcd.

For a long time I treated etcd the way most operators do: as a black box that hums along next to the control plane. “The database.” You back it up and otherwise leave it alone. But black boxes feel like splinters to me, and the first time an etcd cluster fell over at 2am I realised I had no idea what I was actually looking at. So I learned. And it turns out the whole thing is built on a handful of ideas that, once they click, make most etcd problems diagnosable instead of terrifying.

Kubernetes High Availability: Stacked vs External etcd Explained

Wed, 15 Jan 2025 20:23:00 +0100

The first “production” Kubernetes cluster I ran had a single control plane node. It hummed along happily for weeks, right up until a disk failed and took the whole thing with it. Every pod, every service, gone. That outage taught me what “single point of failure” actually feels like, and it pushed me toward a question that I keep seeing trip people up: when you build a cluster that survives node loss, do you run etcd on your control plane nodes, or on dedicated nodes of its own?