Kubernetes gets explained badly most of the time. You'll find "a container orchestration platform for managing containerized workloads at scale" on the first page of nearly every search. That sentence is true and useless at the same time.
Here's the version I'd give a friend.
The one-sentence version
Kubernetes is a program that runs on a group of machines and decides where your other programs run, restarts them when they crash, and moves them around when a machine dies. That's it. Everything else is detail on top of that.
What "orchestration" actually means
Before containers, if you wanted to run five apps reliably, you either put them all on one server and hoped they didn't fight over resources, or you gave each one its own server and maintained five servers.
Kubernetes takes a pile of machines (nodes) and treats them as one pool. You tell it "run this app, keep 2 copies of it alive." It picks which machine to put each copy on, watches them, and if one dies or the machine it's on dies, it starts a replacement somewhere else in the pool. You don't pick the machine. You don't SSH in to restart the process. It just happens.
That's the whole trick. Not magic, just a scheduler and a loop that keeps checking "is reality what I was told it should be" and fixing it when it isn't.
What "self-hosted" means here
Managed Kubernetes (the kind most clouds sell) means someone else runs the control plane, the part that makes the scheduling decisions, and you just point workloads at it. Self-hosted means you're running that control plane yourself, on your own infrastructure, instead of paying a hyperscaler's markup for it.
Self-hosted doesn't mean harder in the way people assume. It means you own the infra layer instead of renting it, which matters a lot once you're the one billing clients for hosting and the margin is yours to keep or hand to AWS. (And if "VPS" and "cloud" still feel like separate categories, they're mostly not — worth clearing up before this part.)
What actually runs on it
A few pieces, none of them exotic:
- Nodes — the actual machines, virtual or physical.
- Pods — the smallest unit Kubernetes schedules, usually one container (your app) per pod.
- A control plane — the decision-maker. Watches what's supposed to be running and reconciles reality against it.
- A scheduler — picks which node a pod lands on.
That's the infrastructure layer. On top of it, most real setups add a couple more pieces: something that watches a git repo and applies changes automatically (I use FluxCD), and something that provisions the underlying servers in the first place (I use OpenTofu). Neither of those is Kubernetes itself, they're the automation wrapped around it.
Why this matters for hosting client apps or sites specifically
If you're hosting one app or site, none of this buys you much. The moment you're hosting several apps or sites for different clients on shared infrastructure, the "watches and fixes itself" part stops being a nice-to-have and starts being the reason you're not the one manually restarting a crashed process at 11pm for a client who won't know or care that it happened.
I've written about the actual maintenance-load argument for this in more depth, cost breakdown included, if you want the case for why this beats a VPS per client rather than just the definition. And if you're considering this as an actual side business rather than a one-off setup, here's that fuller case.
If this is useful, tell me
I'm building a course and template repo around exactly this setup, the real one I run client apps and sites on right now, not a generic "learn Kubernetes" bootcamp. Still deciding how deep to go on the fundamentals versus assuming you'll pick them up as you go.
If you're trying to figure out whether this is worth learning before you commit real hours to it, get on the list below. You'll get real build notes as I hit them, and a say in what the course actually covers.