Kubernetes Architecture, Explained by a Broke Engineer Who Shouldn't Have Touched It

The Weekend I Tried to Kubernetes a Product With Zero Users

In 2023, when I was building Bitly-clone number who-knows-what — I called mine Clickly — I hit a stretch where I was convinced my URL shortener needed to be “web scale.” Not because it had users. It had zero. But because I’d watched enough conference talks to believe that Real Engineers ran Kubernetes, and I, an above-average engineer in India living off a salary, wanted very badly to feel like a Real Engineer.

So one weekend I decided I’d deploy Clickly on a Kubernetes cluster.

I want you to understand the shape of this. I had a Postgres database (on Neon, free), a Next.js frontend, and a small redirect API. That’s it. That entire product could have — and eventually did — run on a $5 box. But that weekend I spun up a managed cluster, spent Saturday reading about kubectl and YAML and something called an ingress controller, and by Sunday night I had a “Hello World” pod responding to requests and a control plane quietly billing me for the privilege. (There’s an even heavier, enterprise flavour of this — Red Hat’s OpenShift, which I compared to plain Kubernetes here.)

I felt like a genius for about four hours. Then I looked at the dashboard, realized I’d just built a spaceship to deliver a pizza, and tore the whole thing down. That weekend is the reason I can write this post: I learned exactly what Kubernetes is, and exactly why you probably shouldn’t touch it yet.

Let me give you both halves. First the honest architecture — because you should understand it. Then the honest advice.

---

What Kubernetes Actually Is (No Jargon)

Strip away the mystique and Kubernetes is one thing: a robot that babysits containers.

You hand it a bunch of containers — think of a container as your app plus everything it needs to run, packaged so it behaves the same on your laptop and in production. You’ve probably heard of Docker; that’s the tool most people use to build those containers. (If you’re fuzzy on how those two relate, Docker vs Kubernetes — which layer you actually need untangles it; they’re different jobs, not rivals.) Now imagine you have not one container but forty of them, spread across ten servers, and they keep crashing, and traffic keeps spiking, and servers keep dying at 3 AM. Someone has to notice a container died and restart it. Someone has to spread them across machines so one server isn’t melting. Someone has to route traffic to the healthy ones.

Kubernetes is that someone. It’s a container orchestrator. You tell it “I want five copies of this app running at all times,” and it obsessively makes reality match that wish — restarting, rescheduling, and rebalancing without you waking up.

It came out of Google, which had been running everything on an internal system called Borg for years. They open-sourced a cleaned-up version in 2014 and handed it to the Cloud Native Computing Foundation, which is why no single company “owns” it today. The name is Greek for helmsman — the person steering the ship. And because engineers are lazy, “Kubernetes” got shortened to K8s (K, then eight letters, then s). You’ll see that everywhere.

That’s the whole idea. Everything below is just how the robot does the babysitting.

---

The Control Plane: The Brain

A Kubernetes cluster splits into two halves. The control plane is the brain — it makes decisions but doesn’t run your actual app. The nodes are the muscle — they run your code. Let’s do the brain first.

The control plane is a handful of programs that gossip constantly:

• kube-apiserver — the front door. Every command you type, every other component, everything goes through the API server. It’s the only thing allowed to talk to the database directly. If the apiserver is down, the cluster is deaf.
• etcd — the memory. A key-value store that holds the entire state of the cluster: what’s supposed to be running, every config, every secret. It’s the single source of truth. If you ever hear someone say “we lost etcd,” go get them a coffee, they’re having a bad day. (It also holds every Secret in near-plaintext, which is one reason securing Kubernetes is a full-time job — another argument for not running it solo.)
• kube-scheduler — the seating host at a restaurant. A new pod shows up needing a table; the scheduler looks at every node, sees who has room, and assigns it the best seat.
• kube-controller-manager — the obsessive manager. It runs little loops that constantly compare “what should be true” against “what is true,” and fixes the gap. You said five copies but only four are alive? A controller notices and spawns the fifth. This “desired state vs. actual state” reconciliation is the soul of Kubernetes.
• cloud-controller-manager — the translator, only present when you’re on a cloud. It’s what lets Kubernetes ask AWS or Google Cloud for a load balancer or a disk without your app knowing the difference.

Here’s the elegant part, and the part that made me fall a little in love before I came to my senses: none of these boss each other around. Each one just watches the API server and quietly does its job. The scheduler watches for unscheduled pods. The controllers watch for gaps. It’s less a chain of command and more a room full of specialists all reading the same whiteboard.

---

The Nodes: The Muscle

A node is just a machine — a virtual server, usually — where your containers actually run. A cluster has one or many. Each node runs three things:

• kubelet — the shift supervisor on each machine. It takes orders from the control plane (“run these pods here”), tells the container runtime to start them, and constantly reports back on whether they’re alive.
• container runtime — the thing that actually runs containers. For years everyone said “Docker” here, but Kubernetes removed direct Docker support back in 2022; under the hood most clusters now use containerd. Your Docker images still work fine — this is plumbing you rarely see.
• kube-proxy — the traffic cop. It maintains the network rules so that when something asks for “the payments service,” the request actually finds a healthy pod, wherever it happens to be living that minute.

And the word you’ll hear more than any other: the pod. A pod is the smallest thing Kubernetes deals with — a wrapper around one container (occasionally a few that must live together). You don’t hand Kubernetes a container directly; you hand it a pod. Pods are cattle, not pets: they get born, they die, they get replaced, and the whole system is built to not care when one vanishes.

That’s the entire architecture. Brain tells muscle what to want; muscle runs it and reports back; brain notices when reality drifts and corrects it. On a whiteboard, it’s genuinely beautiful. In your bank account, it’s a different story.

---

What This Actually Costs You (Two Kinds of Bill)

There’s the money bill and the sanity bill. The money one is easier to show.

The moment you spin up a managed cluster, you pay for the control plane whether or not a single container of yours is running. This is the part that stings for a bootstrapper:

Provider	Control plane cost	What that is per month
Amazon EKS	$0.10 / hour	≈ $73/mo, before any of your code runs
EKS on an old version	$0.60 / hour (extended support)	≈ $438/mo — a 6x penalty for not upgrading
Google GKE	$0.10 / hour per cluster	one cluster is covered by GKE’s ~$74.40/mo free-tier credit
DigitalOcean Kubernetes	free control plane	you only pay for worker nodes, from $12/mo

And that’s just the brain. On top of it you still pay for the nodes — the actual servers — plus load balancers, disks, and the cross-zone network traffic nobody warns you about. EKS’s jump to $438/month if you fall behind on version upgrades is the kind of thing that quietly eats a founder alive. DigitalOcean and GKE’s free-tier trick are the humane options here, and even those assume you know what you’re doing.

But honestly? The money is the smaller bill. The bigger one is the sanity tax. Kubernetes has its own vocabulary — deployments, services, ingress, config maps, persistent volume claims — its own config language (endless YAML), its own package manager (Helm), and its own way of breaking. (Of that whole vocabulary, the one object you’d actually hand-write is the Deployment — I broke that one down on its own in Kubernetes Deployment, explained.) Every hour you spend debugging why a pod won’t schedule is an hour you didn’t spend getting a single user. That’s the real cost, and it doesn’t show up on any invoice.

---

So Should You Run It? Almost Certainly Not

Here’s the Broken Engineer take, and I’ve earned it the hard way: Kubernetes is the AWS of the container world. Same trap, same seduction, same outcome.

Just like I told you never to start on AWS, I’m telling you not to start on Kubernetes. It is a phenomenal piece of technology built to solve a problem you do not have. It exists so that companies with hundreds of services and dedicated platform teams can run them without going insane. You are one person with zero users and a dream. You are not that company. Not yet, and maybe not ever — and that’s fine.

The tell is simple: if you have to ask whether you need Kubernetes, you don’t. The people who genuinely need it know exactly why, down to the specific pain it removes. Everyone else is cosplaying scale, the way I was that weekend with Clickly — the same weekend I also talked myself into needing an event-streaming pipeline for a product with zero users. Over-engineering felt productive. It was the opposite of productive. It was me hiding from the actual hard thing, which is distribution — getting anyone to care that your product exists. (The natural next chapter of that same mistake: once you’ve hand-built cloud infrastructure you can’t recreate, you go looking for terraform import to codify the cluster you never needed.)

You’re a broke engineer. You don’t have a scaling problem. You have a “nobody knows I exist” problem. Kubernetes fixes the wrong one.

---

What To Use Instead

(This is the short version; I ranked the full set of Kubernetes alternatives — PaaS, lighter orchestrators, managed K8s — in its own post.) Everything Kubernetes does for you at scale — restart my app if it crashes, run a couple of copies, give me a URL, roll out a new version — the modern platforms do with a git push and zero YAML:

• Railway — push a repo, get a running backend for a flat few dollars a month. This is where I move my APIs, and it’s genuinely joyful to use.
• Fly.io — if you live in the terminal and want global, multi-region deploys, fly launch and you’re scattered across the planet. It gives you Kubernetes-shaped superpowers without the Kubernetes.
• Koyeb — when you want a real, always-on server with a flat monthly price and no per-request billing nightmares.

All three quietly run containers on orchestration you never have to see. That’s the point. Someone else is running the K8s-equivalent so you don’t have to. I laid out exactly where each one fits — and when to graduate from one to the next — in my full deployment tier list and the complete deployment guide. I would never reach for a raw cluster before I’d exhausted these, and I’ve never once needed to.

---

When Kubernetes Does Make Sense

I’m not going to pretend it’s useless — that would be its own kind of dishonesty. Kubernetes earns its keep when:

• You’re running dozens of services and a real team is managing them.
• You have genuine multi-region, multi-cloud requirements you can’t fake with a simpler platform.
• Your company has decided to standardize infrastructure across many teams, and the consistency is worth the overhead.
• You’re being paid to know it — it’s a legitimately valuable skill on a résumé, and learning it on someone else’s cluster is a smart move.

If that’s you, wonderful. Go deep, it’s a beautiful system. But notice that every one of those bullets describes a company with revenue and people. None of them describe a solopreneur at $0 MRR trying to ship. Respect the tool. Just don’t marry it before the first date.

---

The thing I actually learned that weekend in 2023 wasn’t how to run a cluster. It was that complexity is a drug, and “this is what real engineers do” is the dealer. Kubernetes is the helmsman of a giant ship. You’re in a kayak with a laptop and a dream. Understand the ship — genuinely, it’s worth knowing how it steers — but paddle your kayak, ship your product, and go find the one thing that actually moves the needle: a human being who wants what you built.

The day you truly need Kubernetes will be a great day, because it’ll mean you have the scale to justify the pain. Until then, git push and get back to work. (And if you’re still assembling the rest of the stack on a shoestring, start with the broke solopreneur’s survival guide.)

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and hand you the scars so you can skip them. Now close the docs and go get a user.