As a recovering VMware architect, it took me a little while to grasp Kubernetes. And I noticed I’m not alone in this.. From developers on our own team who need to get fluent in Kubernetes fast to do their dev work, to IT generalists on the customer side who’ve spent a decade running vSphere and are now migrating off it as software is increasingly packaged as containers. Different people, same question: where do I actually start learning?
They get the same non-answer when they look online. The Kubernetes docs. A paid course that regurgitates the docs. A certification path that goes too deep too fast. A podcast list with no discernible information density. A “top resources” listicle with more links than anyone could click in a year (and most of them pointers to a corporate blog). None of that actually helps people grasp the key concepts of Kubernetes to help build the mental scaffolding so they can dive deep into specific topics.
Learn the scaffolding first
There are five pieces of scaffolding that help to build that mental model before diving into Kubernetes more deeply.
Desired state and reconciliation. This is the one idea underneath every other behavior Kubernetes has. You don’t tell it to run a container, you declare that a container should exist, and something keeps checking reality against that declaration and correcting the gap, forever, without being asked. Self-healing is this. Scaling is this. A rollout is this, just the desired state changing in controlled steps. If you don’t have this one straight, everything else looks like a pile of separate features you have to memorize instead of one mechanism wearing different clothes.
The control plane and worker split, and what “disposable” really means. This is the one your vSphere years actively work against you on. An ESXi host that gets sick gets nursed, migrated off, patched, brought back. A Kubernetes node that gets sick gets replaced. Any healthy node can run any workload, so the system doesn’t try to save the failing one, it just routes around it. That’s not a minor implementation detail, it’s a different relationship with the hardware underneath you, and if you carry the vSphere instinct of babying a specific box into a Kubernetes cluster, you’ll spend a lot of energy protecting something the system was designed to let go of.
The four networking layers, from a container out. Container to pod, pod to service, service to ingress, ingress to the outside world. Most networking confusion in Kubernetes isn’t a networking problem, it’s a “which layer is this actually happening at” problem. A pod IP is real but volatile. A service IP is virtual and stable and has nothing listening on it directly. Know which layer you’re debugging and half the mystery disappears before you’ve touched a single command.
Requests and limits as a survival contract, not a suggestion. A request is what the scheduler uses to decide where your workload fits. A limit is the ceiling it isn’t allowed to cross. Get this wrong in either direction and you get one of two outcomes: wasted capacity because you over-declared, or pods getting evicted at the worst possible moment because you under-declared and the node ran out of room. This is the single most common gap between “works in staging” and “falls over in production,” and it has nothing to do with your application code.
Why CNI and CSI exist as plugins in the first place. Kubernetes deliberately doesn’t ship networking or storage. It defines the contract and leaves the implementation to a plugin, because a small edge cluster and a multi-zone regulated environment have nothing in common operationally, and forcing one design on both would have been worse than picking none. This matters less as a technical fact and more as an explanation: it’s the actual reason the tooling landscape sprawls the way it does. Once you understand that the gaps are intentional, the fifteen CNI options on the market stop looking like chaos and start looking like exactly what you’d expect from a system that chose flexibility over a single opinion.
Everything else is a lesson for another day. Some lessons follow immediately, like GitOps and Observability, others can wait longer. Rome wasn’t built in a day, nor is a full understanding of cloud-native. It’s ok to leave answers to problems you haven’t had yet.
Don’t try to cover the whole map
If you need to learn Kubernetes, but don’t know where to start, here’s the actual advice. Don’t start by trying to cover the whole map. You don’t need the service mesh conversation in week one. You don’t need an opinion on policy engines before you’ve deployed a single working workload.
Learn the mechanism first: desired state, reconciliation, the thing that makes the whole system behave the way it does. Then the machine: control plane, worker nodes, and the specific way “disposable” breaks your old instincts. Then the plumbing: how a request actually reaches a container, and why storage and networking were left as plugins instead of being baked in.
That’s enough to get the job done for a while. The rest isn’t going anywhere, and you’ll encounter problems along the way, helping you figure out what to learn next. It’ll all be there the day you hit the specific problem that makes a service mesh or a policy engine make sense. You’ll learn it faster then anyway, because you’ll finally know what question you’re asking.
If you want a primer that stays at this altitude on purpose, architecture and mental models, not configuration walkthroughs, kubeschool.portainer.io is for you. It’s free and vendor-neutral.