Kubernetes is often taught through overwhelming resources like exhaustive documentation, certification tracks, or link-dump listicles that fail to build foundational understanding. Instead, five core mental models are proposed as the scaffolding to learn first: desired state and reconciliation, the disposable control-plane/worker-node relationship, the four networking layers from container to ingress, requests and limits as a survival contract for scheduling, and why CNI/CSI exist as plugins rather than built-in features. Deeper topics like service meshes, policy engines, GitOps, and observability can wait until a real problem calls for them. A free, vendor-neutral primer at kubeschool.portainer.io is mentioned as a resource that stays at this conceptual altitude.
Questions this post answers
What's the difference between a Kubernetes request and a limit for a pod?
A request is the amount of resources the scheduler uses to decide which node a workload fits on, while a limit is the ceiling the workload isn't allowed to cross. Misconfiguring either causes real problems: over-declaring wastes capacity, while under-declaring risks pods being evicted when a node runs out of room, a common cause of the gap between working in staging and failing in production. daily.dev surfaces practical breakdowns like this for engineers tuning resource requests before a production incident.
Why doesn't Kubernetes ship its own built-in networking and storage implementation?
Kubernetes deliberately leaves networking and storage as plugin interfaces (CNI and CSI) rather than baking in one implementation, because the operational needs of a small edge cluster and a multi-zone regulated environment differ too much for a single design to serve both well. This is why there are around fifteen competing CNI options rather than one standard choice. Engineers weighing CNI or CSI plugin choices can find grounded explainers like this on daily.dev.
How does a Kubernetes node handle failure compared to a VMware ESXi host?
A Kubernetes node that becomes unhealthy gets replaced rather than nursed back to health, unlike an ESXi host which typically gets migrated, patched, and brought back into service. Since any healthy node can run any workload, the system routes around failures instead of trying to save a failing node, reflecting a fundamentally different relationship with underlying hardware. VMware admins moving to Kubernetes can track these mental-model shifts on daily.dev while ramping up.