Those beginning to learn Kubernetes do not need to try to understand every component and option of the platform from the first week. That is the conclusion presented by Joep Piscaer of Portainer.io, drawing on his previous experience as a VMware architect and his observation that developers and IT staff face the same question when moving to container-based environments: where should learning actually begin?
The author believes that common learning paths do not always provide a suitable starting point. Kubernetes documentation is extensive, paid courses may simply repeat the same documentation, while certification paths can quickly become overly detailed or present long lists of resources without building a connected understanding of the core concepts. He therefore suggests starting with what he calls mental “scaffolding”: a limited set of ideas that explain the platform’s behavior before moving on to its many details.
Start with the Desired-State Mechanism
The first concept is desired state and reconciliation. In Kubernetes, the process is not limited to issuing a command to run a container. Instead, the user declares that a certain state should exist, after which the platform continuously compares reality with that declaration and corrects the difference between them. According to the author, functions such as self-healing, scaling, and rolling deployments all fall under the same mechanism, with the desired state or the way it changes differing between them.
This concept is both educationally and practically important. Rather than memorizing each function as a separate feature, learners can view Kubernetes behavior as multiple applications of a single mechanism. The author emphasizes that without this understanding, the rest of the platform can appear to be a long list of separate properties that must be memorized.
Understand How the Node Model Differs
The second pillar is separating the control plane from worker nodes, along with understanding what it means for a node to be “replaceable.” The author compares this with traditional VMware experience, where a team might deal with a failed ESXi host by repairing it, moving workloads away from it, or upgrading it and then returning it to service.
In Kubernetes, however, when a node fails, the system does not necessarily assume that the node itself must be rescued. Any healthy node can run any workload, so the system is designed to bypass the affected node and replace it rather than protect it as a specific piece of hardware. Piscaer points out that carrying traditional infrastructure-management habits into this model may lead teams to protect a component that the platform was originally designed to abandon when necessary.
Identify the Network Problem’s Layer
The author proposes studying networking through four successive layers: from the container to the pod, from the pod to the service, from the service to the ingress, and then from the ingress to the outside world.
According to this view, much of the confusion in network troubleshooting arises because the team does not identify the layer at which the problem occurs. A pod’s IP address exists but is changeable, while a service’s IP address is virtual and stable, and there is not necessarily a process listening on it directly. Knowing the layer being examined can eliminate much of the ambiguity before additional diagnostic commands are run.
Treat Requests and Limits as Operational Boundaries
The source describes resource requests and limits as operational workload-survival contracts, not merely advisory values. The scheduler uses the request value to determine a suitable place to run the workload, while the limit represents the ceiling it is not expected to exceed.
Overstating resource requirements may waste capacity, while understating them may lead to pods being evicted at a critical time when the node runs out of space. The author connects this mistake with the recurring difference between a workload that runs in a test environment and then collapses in production, explaining that the problem may lie in resource specification rather than in the application code.
Why Are There CNI and CSI Plugins?
The fifth pillar is understanding why networking and storage are left to plugins such as CNI and CSI instead of having a single implementation built into Kubernetes. The source explains that the platform defines the contracts but leaves the implementation to plugins because the needs of a small cluster in an edge environment differ radically from those of a regulated, multiregion environment.
This explains the breadth of the tools and options landscape. The existence of multiple networking options is not necessarily accidental chaos, but a direct result of choosing flexibility instead of imposing a single design on all environments. That does not mean choosing a plugin has become easy; it places the variety of options in its proper context.
What Changes for the Learner in Practice?
The proposed approach does not eliminate topics such as GitOps, observability, service meshes, and policy engines, but postpones them until the learner encounters a problem that gives them meaning. After understanding the core mechanism, the structure of the control plane and nodes, the network path, and resource boundaries, the transition to these topics is based on a specific practical question rather than an attempt to cover the entire “map.”
This is an educational perspective, not an official path to obtaining a certification or a substitute for specialized documentation. The source also does not provide setup steps or operational commands, but rather a framework for building an initial understanding. At the end of the article, the author points to a free educational resource that he describes as vendor-neutral at kubeschool.portainer.io. It is associated with the organization to which the author belongs, so it should be regarded as a resource suggested by the source, not as an independently established reference here.