Cluster Architecture

Learn how Kubernetes clusters are organized across the control plane, worker nodes, API server, etcd, scheduler, controllers, kubelet, and networking.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A Kubernetes cluster has a control plane that makes decisions and worker nodes that run application Pods. The API server is the front door, etcd stores cluster state, and nodes run kubelet plus container runtime.

🔍 What Is It?

Kubernetes cluster architecture is the arrangement of components that store desired state, schedule workloads, run containers, and connect them over the network.

The control plane contains API server, etcd, scheduler, and controllers. Worker nodes run kubelet, kube-proxy or equivalent networking, container runtime, and application Pods.

🎯 Why Do We Need It?

Architecture knowledge makes troubleshooting practical.

When a Pod is pending, scheduling and node capacity matter. When updates are not applied, API/controller health matters. When traffic fails, Services, CNI, DNS, and kube-proxy behavior matter.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

In managed Kubernetes, cloud providers often operate the control plane while platform teams operate node pools, add-ons, ingress controllers, observability, admission policies, and workload standards.

In self-managed clusters, the platform team must also operate etcd backups, control-plane HA, certificates, and upgrades.

⚙️ How It Works

Users call the API server with kubectl, CI/CD, Helm, or GitOps controllers. The API server validates requests and stores state in etcd.

Controllers watch state and create or update dependent objects. The scheduler assigns Pods to nodes. Kubelet on each node asks the container runtime to run containers and reports status back to the API.

💻 Example

Cluster component flow — How a Deployment becomes running Pods.

text
kubectl apply -f deployment.yaml
  -> API server validates and stores desired state
  -> Deployment controller creates ReplicaSet
  -> ReplicaSet controller creates Pod objects
  -> Scheduler assigns Pods to nodes
  -> Kubelet starts containers through runtime
  -> Service routes traffic to ready Pod endpoints

🤔 Common Confusions

❓ Is the control plane where app containers run?

Usually no. Application Pods run on worker nodes. Control-plane nodes run cluster management components.

❓ Is etcd a normal application database?

No. etcd stores Kubernetes cluster state and must be protected, backed up, and operated carefully.

❓ Is kubelet a controller?

Kubelet is the node agent that runs and reports Pods on its node. Controllers usually run in the control plane.

🚨 Common Production Issues

**etcd backup missing** makes cluster-state recovery extremely difficult in self-managed clusters.

**Node pressure ignored** causes evictions and scheduling failures.

**Control-plane API latency** slows deployments and controllers.

**Unmanaged add-ons** such as CNI or DNS become hidden single points of failure.

✅ Best Practices

Understand which parts are provider-managed and which are platform-owned

Monitor API server, scheduler, controller manager, DNS, CNI, and node health

Keep node pools replaceable and automated

Back up etcd for self-managed clusters

Plan cluster upgrades and add-on compatibility

Document failure domains across zones and node pools

🏛️ Architect's Note

Senior Architect's Perspective

Cluster architecture is a dependency map. If you know which component owns each decision, Kubernetes debugging becomes methodical instead of mystical.

💬 Frequently Asked Questions

Interview: How would you explain Cluster Architecture in a real Kubernetes project?

Cluster Architecture should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Cluster Architecture?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

What are the main control-plane components?

API server, etcd, scheduler, controller manager, and often cloud-controller-manager in cloud environments.

What runs on worker nodes?

Kubelet, container runtime, networking components, node-level agents, and application Pods.

🎯 Key Takeaways

1Control plane manages cluster state and decisions
2Worker nodes run application Pods
3API server and etcd are central to cluster behavior
4CNI, DNS, and node health are production-critical

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages