Every time a pod crashes and restarts itself within seconds, a small set of background processes has already detected the failure, picked a replacement node, and started a new container. That quiet automation is the whole point of Kubernetes, and it only works because of a specific architecture. Understanding that architecture is what separates teams who debug clusters confidently from teams who restart things and hope. (Best ai architecture generators for building designs) (Kubernetes Components and Architecture)
Kubernetes grew out of Google’s internal Borg system, and the project was open-sourced in 2014 before being donated to the Cloud Native Computing Foundation. The design has stayed remarkably stable since then: a control plane that makes decisions, and worker nodes that run workloads. Everything else is detail layered on top of that split.
The two halves of every cluster
A Kubernetes cluster is divided into two logical parts. The control plane is the brain. It stores the desired state of the system, watches for drift, and responds to events. Worker nodes are the muscle. They run the actual containers and report back. (Eks cluster upgrade kubernetes 1 37 13 steps 2026) (Kubernetes)
What surprises many newcomers is that there is no single “master server” doing everything. The control plane itself is a set of cooperating components, each with one job. On small clusters these can share a machine. On production clusters they are spread across multiple machines for redundancy.
The API server is the front door
The kube-apiserver is the central hub of the entire system. Every other component talks to it, and it is the only component that talks directly to the cluster’s database. When someone runs `kubectl apply`, the request goes to the API server, which validates it, applies admission policies, and writes the result to storage.
This hub-and-spoke design matters in practice. Because all communication flows through one authenticated, auditable endpoint, you get a single place to enforce access control and a single place to watch for changes. It also means a slow or overloaded API server makes the entire cluster feel slow, which is why API server latency and request throttling are among the first things experienced operators check during an incident.
etcd holds the truth
etcd is a distributed key-value store that holds all cluster state: every object, every configuration, every status field. If etcd is lost without a backup, the cluster’s memory is gone, even if the containers keep running for a while.
A practical tip that saves real pain: etcd is sensitive to disk latency. Running it on slow or network-attached storage is one of the most common causes of flaky, hard-to-diagnose clusters. Fast local SSDs and regular snapshots are not optional extras. They are the difference between a recoverable failure and a rebuild from scratch.
The scheduler decides placement
The kube-scheduler watches for newly created pods that have no node assigned, then picks a node for each one. It does this in two phases: filtering (which nodes can run this pod?) and scoring (which of those is the best fit?).
Filtering considers resource requests, node affinity and anti-affinity rules, taints and tolerations, and topology constraints. Scoring ranks the survivors. A common mistake is setting resource requests far too low “to be safe,” which lets the scheduler pack pods onto nodes that then run out of memory. Requests are not limits, but they are the scheduler’s map of the world. Getting them roughly right is one of the highest-leverage tuning tasks in Kubernetes.
Controllers run the reconciliation loops
The kube-controller-manager bundles dozens of controllers into one binary. Each controller watches a particular kind of object and works to make reality match the declared intent. The Deployment controller creates ReplicaSets, the ReplicaSet controller creates pods, the Node controller notices when a node stops reporting, and so on.
This is the declarative model in action. Users describe what they want, not how to get there. Controllers endlessly loop, comparing actual state to desired state and nudging one toward the other. Once that clicks, a lot of Kubernetes behavior stops feeling magical and starts feeling predictable.
A cloud-controller-manager handles cloud-specific work such as provisioning load balancers and managing node lifecycles, keeping provider code out of the core.
What runs on every worker node
Worker nodes do the actual work. Each one runs three main pieces.
kubelet, the node agent
The kubelet is the primary agent on each node. It receives pod specifications from the API server and ensures the described containers are running and healthy. It also reports node and pod status back upstream. If the kubelet stops, the node is marked unhealthy and its pods may be rescheduled elsewhere.
The container runtime
Containers need something to actually run them. Kubernetes talks to runtimes through the Container Runtime Interface (CRI), an abstraction that decoupled the project from any single runtime. The most visible consequence was the removal of the built-in Docker integration, known as dockershim, in Kubernetes 1.24 in 2022. Workloads did not break, because container images built with Docker still run fine on CRI-compliant runtimes; what changed was the plumbing underneath.
kube-proxy and service networking
kube-proxy implements the networking rules that make Services work, historically using iptables and later adding IPVS as an option for larger clusters. It is worth knowing that some modern networking setups handle service routing through other means, so kube-proxy is not universally mandatory in every configuration. For most teams running mainstream distributions, it is simply there and working.
Pods, the atomic unit
Kubernetes does not schedule containers directly. It schedules pods, the smallest deployable unit. A pod wraps one or more containers that share a network namespace and can share storage volumes. Containers in the same pod reach each other over localhost.
The sidecar pattern, where a helper container (a log shipper, a proxy) runs alongside the main application in one pod, is a direct consequence of this design. So is the advice to keep pods small. A pod is a unit of scheduling, scaling, and failure, so bundling unrelated services into one pod couples their fates in ways that are painful to untangle later.
How a request becomes a running container
The full flow is easier to remember as a sequence:
- A user or CI pipeline submits a manifest to the API server.
- The API server validates it and writes the object to etcd.
- A controller notices the new object and creates the dependent objects, such as a ReplicaSet and then pods.
- The scheduler assigns each pending pod to a node.
- The kubelet on that node sees the assignment and instructs the runtime to pull images and start containers.
- The kubelet reports status back, and the API server stores it.
Every step is asynchronous. Nothing waits for the previous step to finish in a blocking way, which is why Kubernetes scales and why it occasionally takes a few seconds for things to “settle.” Understanding the sequence also explains why a pod stuck in Pending usually points at the scheduler, while a pod stuck in ContainerCreating points at the node.
Control plane versus worker nodes at a glance
| Aspect | Control plane | Worker nodes |
|---|---|---|
| Main role | Decide and store state | Run containers |
| Key components | API server, etcd, scheduler, controller manager | kubelet, container runtime, kube-proxy |
| Talks to etcd | Yes, via the API server only | No |
| Typical failure impact | Cluster-wide loss of control | Localized workload disruption |
| Scaling approach | Fewer, larger, redundant nodes | Many nodes, added horizontally |
That last row is a useful mental model. You scale the control plane for resilience, and you scale workers for capacity. Confusing the two leads to over-provisioned control planes and under-provisioned workers.
Design principles worth internalizing
Three principles explain most of Kubernetes’ behavior.
Everything goes through the API server. This gives you one authentication boundary, one audit log, and one extension point. It also means the API server is a shared bottleneck under heavy load.
State is stored, not inferred. Because etcd holds the declared state, any component can restart and pick up where it left off. This is why Kubernetes tolerates component failures so well.
Controllers reconcile continuously. Nothing is a one-time action. A deleted pod gets recreated. A drifted configuration gets corrected. This is powerful, and it is also why fighting the controller loop (for example, manually editing pods managed by a Deployment) never ends well.
For teams thinking about how these pieces map onto broader system design, the same layering ideas show up in general software architecture concepts: separation of concerns, single sources of truth, and loose coupling between components.
Practical lessons from real clusters
A few patterns show up again and again in production.
Back up etcd and test the restore. An untested backup is a hope, not a plan.
Watch the control plane’s resource usage separately from workloads. API server memory growth and etcd disk latency are early warning signs that get missed when dashboards only track application metrics.
Keep cluster versions current. Upgrades touch every component discussed here, and skipping several minor versions at once turns a routine task into a project. Teams planning a jump should follow a structured upgrade plan rather than improvising, since the order of control plane and node upgrades genuinely matters.
Set resource requests thoughtfully and use pod disruption budgets for anything critical. The scheduler can only make good decisions with good inputs.
Finally, resist the urge to treat Kubernetes as a goal in itself. It is an orchestration layer with real operational cost, and the architecture above explains exactly where that cost comes from: you are running a distributed system to manage distributed systems.
Conclusion
Kubernetes architecture is simpler than its reputation suggests once the pieces are separated. A control plane stores desired state, schedules work, and runs reconciliation loops. Worker nodes execute that work through the kubelet and a container runtime. Everything communicates through the API server, and etcd remembers it all.
That design delivers real resilience, but it also concentrates risk in a few places: the database, the API server, and the quality of the resource requests you feed the scheduler. Teams that understand where those pressure points sit debug faster, plan upgrades more calmly, and spend less time wondering why a pod is stuck. The architecture rewards curiosity, and it punishes guesswork.
Frequently asked questions
What is the difference between the control plane and worker nodes?
The control plane makes decisions and stores cluster state. Worker nodes run the actual containers. The control plane includes the API server, etcd, the scheduler, and the controller manager; worker nodes run the kubelet, a container runtime, and typically kube-proxy.
Does Kubernetes still need Docker?
No. Kubernetes uses the Container Runtime Interface to talk to runtimes, and the built-in Docker integration was removed in version 1.24 in 2022. Images built with Docker still run fine on modern CRI-compliant runtimes such as containerd.
What happens if etcd goes down?
The cluster loses its ability to read or write state. Running containers usually keep running for a while, but no new scheduling or configuration changes can happen. This is why etcd backups and fast local disks are treated as essential operational requirements.
Why is my pod stuck in Pending?
A pod in Pending has not been assigned to a node. The usual causes are insufficient CPU or memory on available nodes, unsatisfiable node affinity rules, or taints the pod does not tolerate. Check the scheduler’s events first; they almost always name the reason.
Is kube-proxy always required?
Not always. kube-proxy implements Service networking rules, historically with iptables and later with IPVS. Some modern networking setups handle service routing through other mechanisms, so its role depends on the specific cluster configuration.
How many control plane nodes should a production cluster have?
Most production clusters run three control plane nodes, which allows etcd to maintain quorum if one fails. Five is used for larger or more critical environments. A single control plane node is fine for learning but leaves no room for failure.
