If you have run vSphere for a decade, Kubernetes documentation reads as though it were written for somebody else. It was. Here is the translation I wish I had been handed.
The rough mapping
A pod is the smallest thing that gets scheduled. Closest analogue is a VM, except it is usually one process, it is disposable, and it has no identity worth preserving.
A node is an ESXi host. It runs the workloads and has capacity.
A deployment is a statement of desired state: run five of these. There is no vSphere equivalent because vSphere has no concept of continuously reconciling toward a declaration. This is the actual conceptual gap.
A service is a stable address in front of things that come and go. Think of it as a load balancer VIP that updates itself.
A namespace is a resource pool plus a folder plus a permission boundary, rolled together.
etcd is the vCenter database, except every component reads it directly and it is the single source of truth for everything.
The three ideas that actually differ
Declarative reconciliation. You do not perform actions; you declare an end state and a controller works continuously to reach it. When you delete a pod, one comes back, because you declared five. This confuses everyone once, memorably.
Workloads are cattle. A pod has no name you care about, no fixed address, no uptime worth quoting. If it misbehaves you kill it. This is genuinely different from a world where a VM’s uptime was a source of pride.
The network is software all the way down. Every pod gets an address, addresses are ephemeral, and connectivity is governed by policy objects rather than by where things are plugged in.
What transfers directly
More than you expect. Capacity planning, failure domains, maintenance windows, storage performance, network design, monitoring discipline, backup strategy, change control. The hard-won instincts about how infrastructure fails are entirely applicable, and the platform teams that struggle are usually the ones with strong Kubernetes knowledge and no infrastructure background, not the reverse.
You are not starting from zero. You are learning a vocabulary for things you already understand, plus three genuinely new ideas.
Where virtualization people are immediately useful
Storage. The Kubernetes storage conversation is full of people who have never sized an array. Knowing what a StorageClass means underneath is rare and valuable.
Failure domains. Anti-affinity, rack awareness, and what happens when a node dies are the same problems with new names.
Capacity. Requests and limits are overcommit by another name, and the intuitions about how much you can safely oversubscribe carry over directly.
The thing to resist
Treating it as a VM platform with extra steps. Running a stateful monolith in a pod, giving it a persistent address, and never letting it restart is technically possible and gets you the complexity of Kubernetes with the benefits of neither model.
If a workload genuinely wants to be a VM, run it as a VM. OpenShift Virtualization exists precisely so you do not have to containerise everything to be on one platform, and the correct answer for a large slice of an enterprise estate is “leave it as a VM and run it here”.
How I would learn it
Build a small cluster and break it. Kill nodes while workloads run. Fill a disk. Expire a certificate. Watch what the platform does. The reconciliation behaviour is the whole point and reading about it teaches you nothing.
Then read the etcd documentation, because when the cluster is unwell, etcd is where the truth is.