Kubernetes Looks Complex… Until You Understand the Flow
Kubernetes can feel overwhelming when you first encounter terms like API Server, etcd, Scheduler, Controllers, Kubelet, and Pods.
The good news is that Kubernetes isn’t a collection of unrelated components—it’s a control system designed to continuously ensure your applications are running in their desired state.
Once you understand how the control plane and worker nodes interact, the architecture becomes much easier to reason about.
Kubernetes Architecture
At a high level, a Kubernetes cluster consists of two major parts:
Kubernetes Cluster
+-------------------------------+
| Control Plane |
|-------------------------------|
| API Server |
| etcd |
| Scheduler |
| Controller Manager |
| Cloud Controller Manager |
+---------------+---------------+
|
|
Cluster Management
|
+-----------------+-----------------+
| |
+-------------+ +-------------+
| Worker Node | | Worker Node |
|-------------| |-------------|
| Kubelet | | Kubelet |
| Kube-Proxy | | Kube-Proxy |
| Pods | | Pods |
+-------------+ +-------------+
The Control Plane makes decisions.
The Worker Nodes execute those decisions.
The Control Plane: The Brain of Kubernetes
The Control Plane is responsible for maintaining the desired state of the cluster.
API Server
The API Server is the front door to Kubernetes.
Every action—whether it’s from kubectl, the OpenShift console, CI/CD pipelines, or operators—flows through the API Server.
Example:
kubectl apply -f deployment.yaml
The API Server:
- Validates the request
- Authenticates the user
- Stores the desired state in etcd
- Notifies other control plane components
Think of it as the central communication hub for the cluster.
etcd
etcd is Kubernetes’ distributed key-value database.
It stores the entire cluster state, including:
- Deployments
- Pods
- Nodes
- Services
- Secrets
- ConfigMaps
- RBAC policies
Without etcd, Kubernetes would have no memory of how the cluster should look.
Scheduler
The Scheduler determines where a Pod should run.
When a new Pod is created, it evaluates factors such as:
- Available CPU and memory
- Node labels
- Taints and tolerations
- Affinity and anti-affinity rules
- Resource constraints
Its responsibility ends once it assigns the Pod to a worker node.
It does not start the container.
Controller Manager
Controllers continuously compare:
Desired State vs. Current State
If they detect a difference, they take corrective action.
Examples:
- A Pod crashes → Create a replacement Pod
- A node becomes unavailable → Reschedule workloads
- Replica count decreases → Launch new Pods
This reconciliation loop is what gives Kubernetes its self-healing capabilities.
Cloud Controller Manager
When running Kubernetes in cloud environments, the Cloud Controller Manager integrates with infrastructure providers.
Typical responsibilities include:
- Provisioning load balancers
- Managing cloud storage
- Handling node lifecycle
- Configuring networking resources
In on-premises environments, these tasks are often handled differently or may not be required.
Worker Nodes: Where Applications Run
Worker nodes execute the workloads defined by the Control Plane.
They host the Pods that run your applications.
Kubelet
The Kubelet is the node agent.
It watches for Pods assigned to its node and ensures they are running as expected.
Responsibilities include:
- Receiving Pod specifications from the API Server
- Communicating with the container runtime (such as CRI-O)
- Monitoring container health
- Restarting failed containers when necessary
The Kubelet manages the Pod lifecycle but relies on the container runtime to actually create and start containers.
Kube-Proxy
Applications running in Pods have dynamic IP addresses that can change whenever Pods are recreated.
Kube-Proxy manages the networking rules that allow Kubernetes Services to reliably route traffic to the correct Pods.
It handles:
- Service networking
- Load balancing across Pod replicas
- Network forwarding rules
This enables clients to communicate with a stable Service IP instead of individual Pod IPs.
Pods
A Pod is the smallest deployable unit in Kubernetes.
A Pod contains one or more tightly coupled containers that:
- Share the same network namespace
- Share storage volumes
- Are scheduled together
- Are managed as a single unit
Most applications run with one container per Pod, although sidecar containers are also common.
The Kubernetes Request Flow
When you deploy an application, the sequence looks like this:
Developer
|
| kubectl apply
v
API Server
|
| Store desired state
v
etcd
|
| Notify Scheduler
v
Scheduler
|
| Select Worker Node
v
Worker Node
|
| Kubelet
v
Container Runtime (CRI-O, containerd, etc.)
|
| Start Container
v
Pod Running
|
| Kube-Proxy
v
Service Exposes Application
This entire process typically completes within seconds.
Why Kubernetes Is So Powerful
Once this architecture is in place, Kubernetes can automatically:
- Deploy applications
- Scale workloads horizontally
- Restart failed containers
- Balance traffic across replicas
- Roll out application updates
- Roll back failed deployments
- Manage CPU and memory resources
- Recover from node failures
- Maintain high availability across clusters
The platform continuously works to ensure that the actual state matches the desired state.
The Bigger Picture
Kubernetes is much more than a container orchestrator.
It provides a foundation for:
- Automation – Reduces manual operational tasks
- Resilience – Automatically recovers from failures
- Portability – Runs consistently across on-premises, public cloud, and hybrid environments
- Scalability – Supports applications from a few containers to thousands of nodes
- Consistency – Delivers predictable deployments regardless of the underlying infrastructure
Key Takeaway
The architecture becomes much easier to understand when you think of Kubernetes as a control loop:
- The Control Plane decides what should happen.
- Worker Nodes make it happen.
- Controllers continuously verify that reality matches the desired state.
Everything else—from scaling and self-healing to rolling updates and service discovery—is built on top of this simple but powerful design.