August 21, 2026
9 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
When you deploy containerized applications at scale, understanding Kubernetes architecture explained: control plane and nodes is the difference between a stable platform and constant firefighting. Most outages I diagnose stem from treating the cluster as a black box rather than a set of interacting processes with specific failure modes. This guide breaks down the exact components, data flows, and operational realities you need to manage production workloads confidently, whether you are running on managed cloud infrastructure or bare metal.
Quick answer: Kubernetes architecture explained: control plane and nodes consists of the control plane (API server, etcd, scheduler, controller manager) that manages cluster state, and worker nodes (kubelet, kube-proxy, container runtime) that execute workloads. The API server is the single entry point for all operations, while etcd stores the authoritative cluster state.
For developers transitioning from traditional VPS deployments or Laravel application development on single servers, this distributed model requires a mental shift. You no longer SSH into a machine to fix a process; you declare desired state and let the reconciliation loops converge reality toward it. If you are evaluating whether your team needs this complexity versus simpler orchestration, my article on tech solutions for startups covers trade-offs for growing businesses. Understanding these internals also directly impacts how you design CI/CD pipelines for zero-downtime deployments.
What Are the Core Components of Kubernetes Architecture Explained: Control Plane and Nodes?
The Kubernetes control plane is a collection of four distinct processes that collectively maintain the desired state of the cluster. In production, these run as separate pods on dedicated control-plane nodes, though they can be co-located in single-node test environments. Each component has a singular responsibility and communicates exclusively through the API server—never directly with each other.
API Server (kube-apiserver)
The API server is the front door to the cluster. Every operation—whether from kubectl, the dashboard, controllers, or kubelets—passes through it. It validates requests, authenticates users via OIDC/webhooks/RBAC, authorizes actions, and persists state changes to etcd. Crucially, it serves as the watch endpoint: components don't poll; they open long-lived HTTP watches and receive events when resources change. In Kubernetes 1.32+ (stable in 2026), the API server supports structured logging and improved request throttling to prevent cascade failures during high-load reconciliation storms.
etcd: The Source of Truth
etcd is a distributed key-value store using Raft consensus. It holds all cluster state: pod specs, configmaps, secrets, node status, leases, and custom resource definitions. Nothing else in the cluster is authoritative. If etcd loses data and has no backup, the cluster is unrecoverable. Always run etcd as an odd-numbered cluster (3 or 5 nodes) for quorum. Backups must be automated, encrypted, and tested regularly—I've seen teams discover their backup restoration procedure was broken only during an actual outage. Use etcdctl snapshot save with TLS certificates and verify snapshots monthly.
Scheduler (kube-scheduler)
The scheduler watches for unbound pods (those without a .spec.nodeName) and assigns them to nodes based on predicates (hard constraints like resource requests, taints/tolerations, node affinity) and priorities (soft preferences). It does not move running pods—that's the descheduler's job if installed. Custom schedulers or scheduling profiles allow workload-specific placement logic, useful when certain legal-tech portals require dedicated compliance-labeled nodes.
Controller Manager (kube-controller-manager)
This binary runs dozens of independent controller goroutines: ReplicaSet, Deployment, Node, EndpointSlice, ServiceAccount, and more. Each controller implements a reconciliation loop: read desired state from the API server, observe actual state, compute diff, and issue corrective writes back through the API server. Controllers never talk to nodes directly. If a controller crashes, its loop restarts idempotently—no partial state corruption.
How Do Worker Nodes Execute Workloads in Kubernetes Architecture?
Worker nodes run your application containers and the agents required to integrate them into the cluster. Unlike the control plane, worker nodes are designed to be ephemeral and replaceable. Losing a worker should never cause data loss for stateless services; stateful workloads require persistent volumes with appropriate replication.
kubelet: The Node Agent
The kubelet is the primary node agent. It receives pod specs from the API server (via watch), ensures containers are running via the Container Runtime Interface (CRI), reports node status and pod conditions back, and executes liveness/readiness/startup probes. If a container fails its liveness probe, kubelet kills and restarts it. If readiness fails, endpoints are removed from services. Misconfigured probes are the #1 cause of "my app is running but not receiving traffic" issues I troubleshoot. Always set reasonable timeouts and periods—aggressive probes cause cascading restarts under load.
Container Runtime Interface (CRI)
Kubernetes no longer ships Docker as a built-in runtime. Since v1.24, you must use a CRI-compliant runtime: containerd (default in most distributions), CRI-O, or others. containerd 2.x is stable in 2026 and offers lower overhead than legacy dockershim setups. The kubelet communicates with the runtime over a Unix socket (/run/containerd/containerd.sock). Never bypass CRI to manage containers manually—the kubelet will fight you and win.
kube-proxy: Service Networking
kube-proxy maintains network rules so Services resolve to healthy pod IPs. Three modes exist:
- iptables (default): Creates DNAT/SNAT rules per service/port. Scales poorly beyond ~10k services due to O(n) rule evaluation.
- IPVS: Uses kernel IP Virtual Server for O(1) lookups. Preferred for large clusters. Requires
ipvsadmand kernel modules loaded. - nftables (beta/stable in 1.32+): Modern replacement for iptables with better performance and atomic rule updates.
In practice, IPVS mode reduces latency variance for high-service-count clusters. Verify mode with kube-proxy --metrics-bind-address and monitor kubeproxy_sync_proxy_rules_duration_seconds.
How Does Data Flow Between Control Plane and Nodes During Pod Creation?
Understanding the sequence of events when you run kubectl apply -f deployment.yaml reveals why certain failures occur and where to look for diagnostics. This flow is identical whether triggered by CLI, CI pipeline, or GitOps operator.
- Authentication & Authorization: API server validates credentials and RBAC permissions. Denied requests return 403 immediately.
- Admission Control: Mutating webhooks modify the object (inject sidecars, add labels), then validating webhooks enforce policies (OPA/Gatekeeper, Kyverno). Failures here block creation.
- Persistence: API server writes the Deployment spec to etcd. Returns 201 Created to client.
- Deployment Controller: Watches new Deployment, creates ReplicaSet object via API server.
- ReplicaSet Controller: Watches new ReplicaSet, creates N Pod objects (unbound, no nodeName).
- Scheduler: Watches unbound Pods, evaluates nodes, writes
.spec.nodeNamebinding back via API server. - kubelet: Watches bound Pod assigned to its node, calls CRI to pull image and start containers.
- Status Reporting: kubelet updates Pod status (Running, Ready conditions) via API server. Endpoints controller updates Service endpoints.
If any step fails, the system remains eventually consistent. A crashed scheduler means pods stay Pending until it recovers. A failed admission webhook blocks creation entirely—check kubectl describe pod for webhook rejection messages. This decoupled design is what makes Kubernetes resilient but also makes debugging non-obvious.
What Are Common Misconfigurations in Kubernetes Control Plane and Node Setup?
After years of consulting on production clusters, these patterns recur across teams adopting Kubernetes:
| Misconfiguration | Symptom | Fix |
|---|---|---|
| Single-node etcd in production | Total cluster loss on disk failure | Always 3+ etcd nodes; automate encrypted backups |
| No resource requests/limits | Noisy neighbor, OOM kills, unschedulable pods | Set requests = observed p95 usage; limits ≤ 2× requests |
| Liveness probe too aggressive | Cascade restarts under GC/load spikes | Use startup probe for slow starts; increase periodSeconds |
| kube-proxy in iptables mode >5k services | High latency, conntrack table exhaustion | Switch to IPVS or nftables mode |
| No PodDisruptionBudgets | Node drain causes full outage | Set minAvailable/maxUnavailable for every critical workload |
| Missing priority classes | System pods evicted before app pods | Create PriorityClasses; assign system-critical/high-priority |
A frequent mistake is confusing liveness and readiness probes. Liveness determines if a container should be restarted; readiness determines if it should receive traffic. Using the same endpoint for both means a temporary overload triggers restarts instead of graceful backpressure. For Laravel or Symfony apps behind PHP-FPM, use a lightweight health check for liveness (/healthz returning 200 from opcache-warmed opcode) and a deeper dependency check for readiness (/readyz verifying DB/Redis/cache connectivity).
How Should You Secure Communication Between Control Plane and Nodes?
All Kubernetes internal communication uses mutual TLS. Certificates are typically issued by the cluster CA during bootstrap (kubeadm, kops, or managed provider). Key security practices:
- Rotate certificates proactively. kubeadm clusters auto-rotate kubelet certs; control-plane certs require manual or cert-manager renewal. Monitor expiry with
kubeadm certs check-expiration. - Restrict etcd access. Only API server should connect to etcd. Firewall etcd ports (2379/2380) to control-plane nodes only.
- Enable audit logging. Configure API server audit policy to log metadata-level for all requests, request-response bodies for sensitive resources (secrets, configmaps). Ship logs externally—compromised nodes may tamper local logs.
- Use RBAC minimally. Default deny. Grant verbs/resources/namespaces explicitly. Audit bindings quarterly.
- Encrypt secrets at rest. Enable EncryptionConfiguration with aescbc or secretbox provider. Rotate encryption keys periodically and re-encrypt existing secrets.
On managed platforms (EKS, GKE, AKS), much of this is handled automatically, but you remain responsible for RBAC, network policies, and workload identity configuration. Never assume managed equals secure-by-default.
Practical Next Steps for Mastering Kubernetes Architecture Explained: Control Plane and Nodes
Theory alone won't build operational intuition. Set up a local cluster with kind or minikube using multi-node topology to observe control-plane separation. Intentionally break components: stop etcd, delete kube-proxy, misconfigure probes—and watch how the system degrades. Read source code for controllers you rely on; the reconciliation logic is often simpler than documentation suggests. For teams managing business-critical applications, invest time in observability: Prometheus metrics for API server latency, etcd WAL fsync duration, scheduler e2e latency, and kubelet PLEG relisting time. These signals distinguish transient blips from architectural problems.
If you're building or migrating infrastructure and need hands-on guidance tailored to your workload profile, reach out to discuss your Kubernetes architecture. Whether you're optimizing an existing cluster or evaluating whether Kubernetes fits your scale, getting the foundation right prevents costly rework later. Understanding Kubernetes architecture explained: control plane and nodes deeply is what separates operators who react to alerts from engineers who design systems that rarely trigger them.
Frequently Asked Questions
The control plane consists of four main components: kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. These manage cluster state, scheduling decisions, API requests, and background reconciliation loops that maintain desired configuration across all nodes.
Control plane nodes run cluster management services like the API server and scheduler. Worker nodes run kubelet, kube-proxy, and container runtime to execute application workloads. In production, these roles are typically separated for stability and security isolation.
Minimum three control plane nodes for production HA. This allows etcd quorum with one node failure. Two nodes provides no fault tolerance since etcd requires majority consensus. Single-node clusters are acceptable only for development or testing environments.
Etcd is the distributed key-value store holding all cluster state including pod specs, secrets, configmaps, and node status. It uses Raft consensus for consistency. All control plane components read from and write to etcd; losing etcd data means losing your entire cluster state unless you have backups.
The scheduler evaluates pending pods against node resources, taints, tolerations, affinity rules, and topology constraints. It runs filtering predicates first to eliminate unsuitable nodes, then scoring functions to rank remaining candidates. Custom schedulers can extend this logic for specialized workload placement requirements.
Existing pods continue running because kubelets maintain local state and containers don't depend on constant API access. However, new deployments, scaling events, and configuration changes fail until the API server recovers. This is why production clusters always run multiple API server instances behind a load balancer.
Technically yes by removing the NoSchedule taint, but avoid it in production. Control plane resources should remain dedicated to cluster management. Running app workloads risks resource contention during scaling events or failures. Development clusters sometimes allow this to save costs on small deployments.
Kube-proxy maintains network rules on each node to route traffic to service endpoints. It watches the API server for Service and EndpointSlice objects, then updates iptables or IPVS rules accordingly. This enables stable virtual IPs that load-balance across healthy backend pods regardless of their physical location.
At least 2 CPU cores and 8GB RAM per control plane node for clusters under 100 nodes. Scale to 4 cores and 16GB for larger clusters. Etcd performance depends heavily on fast SSD storage; spinning disks cause latency spikes that destabilize the entire control plane during high write loads.
Use etcdctl snapshot save to create point-in-time backups stored off-cluster. Automate this via CronJob or systemd timer. Restore requires stopping etcd, running snapshot restore, and restarting the cluster. Test restores quarterly; untested backups are worthless. For managed Kubernetes, rely on provider snapshots but verify restoration procedures.
Resource isolation prevents application workloads from starving critical management services during traffic spikes or runaway processes. Security boundaries reduce attack surface since worker nodes shouldn't have direct etcd access. Operational clarity simplifies troubleshooting when issues arise. The cost savings of combining roles rarely justify the operational risk.
The controller manager runs dozens of controllers that watch API objects and reconcile actual state toward desired state. When a Deployment specifies three replicas but only two pods exist, the ReplicaSet controller creates the missing pod. This continuous reconciliation loop handles failures, scaling, and configuration drift automatically without human intervention.
Common causes include insufficient etcd disk IOPS, memory pressure on API servers, certificate expiration, clock skew between nodes, and network partitions breaking Raft consensus. Monitor etcd WAL fsync duration and API server request latencies. Most instability stems from undersized infrastructure rather than software bugs. Budget at least Rs 15,000/month (~USD 112) per control plane VM for reliable operation.
Managed services abstract away control plane provisioning, upgrades, and etcd management. You typically cannot SSH into control plane nodes or modify their configuration directly. This reduces operational burden but limits customization. Self-managed clusters give full control at the cost of requiring dedicated DevOps expertise. Choose based on team capacity, not just monthly cost comparison.
Upgrade within one minor version of latest stable release. Kubernetes supports three active minor versions; older releases stop receiving security patches. Always upgrade control plane before worker nodes. Test upgrades in staging first. Plan maintenance windows since API server restarts cause brief unavailability. Delaying upgrades beyond six months accumulates technical debt and increases migration complexity significantly.
