Kubernetes Architecture

How a Kubernetes Cluster Really Works
If you have ever asked "what actually happens inside Kubernetes when I deploy an application?" — this guide is for you. Understanding Kubernetes architecture is the single best way to move from copy-pasting YAML files to genuinely knowing how your applications run, scale, and recover from failure in production.
This is a complete but beginner-friendly walkthrough of Kubernetes cluster architecture: the control plane, the worker nodes, and every core Kubernetes component in between. By the end, you will be able to explain, in plain language, exactly what happens from the moment you run kubectl apply to the moment your application is live.
If your team is evaluating whether to adopt Kubernetes for a real workload, Technovez's cloud and DevOps services can help you design a cluster architecture that fits your product roadmap — but first, let's build the foundation.
What Is Kubernetes Architecture, in Plain English?
Kubernetes architecture explained simply: Kubernetes is a system for running containerized applications across a group of machines, called a cluster, while automatically handling scheduling, scaling, networking, and self-healing.
Every Kubernetes cluster architecture is split into two logical halves:
1.The control plane — the "brain" that makes decisions about the cluster (what should run, where, and how many copies).
2.The worker nodes — the "muscle" that actually runs your application containers.
These two halves constantly communicate. The control plane tells the worker nodes what the desired state of the cluster should be, and the worker nodes report back on the actual state. Kubernetes' entire design philosophy is built around closing the gap between "desired state" and "actual state" automatically — this is called the reconciliation loop, and it's the concept that makes Kubernetes self-healing.
Think of it like an air traffic control tower (control plane) directing airplanes (workloads) that land at various airports (worker nodes). The tower doesn't fly the planes — it issues instructions, while the airports handle the actual operations.
Kubernetes Components Explained: The Full Picture
Before diving into each piece, here is a bird's-eye view of the core Kubernetes components and where they live:
Location Component Primary Job
Control Plane kube-apiserver Front door for all cluster communication
Control Plane etcd Stores the cluster's entire state
Control Plane kube-scheduler Decides which node runs which pod
Control Plane kube-controller-manager Watches and corrects cluster state
Worker Node kubelet Runs and monitors containers on the node
Worker Node kube-proxy Handles networking and traffic routing
Worker Node Container Runtime Actually pulls and runs container images

Now let's unpack each one, grouped by where they live in the Kubernetes cluster architecture.
The Kubernetes Control Plane: The Cluster's Brain
The Kubernetes control plane (historically called the Kubernetes master node) makes global decisions about the cluster — scheduling workloads, responding to events, and maintaining the desired state defined in your manifests. Managed services like Amazon EKS, Google GKE, or Azure AKS host and maintain the control plane for you; self-managed clusters typically run it on dedicated nodes for high availability.
The control plane is made up of four essential components:

1. Kubernetes API Server The Kubernetes API server (kube-apiserver) is the front door to the cluster. Every interaction — from kubectl, a CI/CD pipeline, or another component — passes through it. It exposes a RESTful API, validates requests, and is the only component that reads from and writes directly to etcd. If you remember one fact about Kubernetes architecture, it's this: nothing talks to etcd except the API server.
2. Kubernetes etcd Kubernetes etcd is a distributed, consistent key-value store that holds the entire state of the cluster: every deployment, service, secret, configmap, and node status. It is effectively the cluster's "source of truth" and its memory. If etcd is lost without a backup, you lose the record of your cluster's desired state — which is why production clusters back it up regularly on dedicated, high-performance disks.
3. Kubernetes Scheduler The Kubernetes scheduler (kube-scheduler) watches for newly created pods without a node assigned, then picks the best-fit worker node for each one — scoring nodes on available CPU and memory, affinity/anti-affinity rules, taints and tolerations, and data locality. The scheduler doesn't run anything itself; it just makes the placement decision and writes it back to the API server.
4. Kubernetes Controller Manager The Kubernetes controller manager (kube-controller-manager) runs controller processes that continuously compare desired state to actual state and correct any drift. The Node Controller notices when a node goes offline; the Replication Controller keeps the correct number of pod replicas running. This is the mechanism behind Kubernetes' self-healing behavior — if a pod crashes, a controller notices and schedules a replacement automatically. Kubernetes Worker Nodes: Where Your Applications Actually Run Kubernetes worker nodes (often just called Kubernetes nodes) are the machines — virtual or physical — that run your actual application workloads. A production cluster typically has multiple worker nodes for redundancy and scalability. Each node runs three essential components:
5. Kubelet The Kubernetes kubelet is an agent that runs on every worker node and communicates directly with the control plane. It receives pod specifications from the API server, ensures the described containers are running and healthy, and reports node and pod status back up. If a container fails a health check, the kubelet restarts it.
6. Kube-Proxy Kubernetes kube-proxy manages network rules on each node, enabling communication to and from pods regardless of which node they land on. It implements Kubernetes Services by directing traffic to the correct pod endpoints, using iptables or IPVS rules under the hood. Without kube-proxy, pods on different nodes wouldn't reliably reach each other through a stable Service address.
7. Container Runtime The Kubernetes container runtime actually pulls container images and runs containers — engines like containerd or CRI-O. Kubernetes talks to the runtime through the Container Runtime Interface (CRI), which is why it's runtime-agnostic and works with any CRI-compliant engine. Kubernetes Pods: The Smallest Deployable Unit Kubernetes pods are the atomic unit of deployment in Kubernetes — you never deploy a raw container directly; you deploy it inside a pod. A pod is a logical wrapper around one or more containers that share the same network namespace (same IP address and port space) and can share storage volumes. Most pods run a single container, but multi-container pods are common for sidecar patterns — a logging agent or service-mesh proxy alongside your main container. Pods are also ephemeral by design: when a pod dies, a controller creates a brand-new one to replace it, usually with a new IP address — which is why Services, not direct pod IPs, are the standard way to expose applications reliably. How It All Fits Together: A Request's Journey To make this Kubernetes architecture explained guide concrete, here is what actually happens when you run kubectl apply -f deployment.yaml: 1.kubectl sends the request to the Kubernetes API server. 2.The API server validates the request and writes the desired state into etcd. 3.The controller manager notices a new Deployment object and creates the corresponding Pod objects. 4.The scheduler sees unscheduled pods and assigns each one to a suitable worker node. 5.The kubelet on that node picks up the assignment and instructs the container runtime to pull the image and start the container. 6.Kube-proxy updates networking rules so the new pod is reachable through its Service. 7.The kubelet continuously reports pod health back to the API server, closing the reconciliation loop. This entire cycle — desired state in, actual state monitored and corrected — is the essence of every Kubernetes cluster architecture, whether it's a three-node home lab or a thousand-node production environment. Frequently Asked Questions About Kubernetes Architecture What are the two main parts of Kubernetes architecture? Every Kubernetes cluster is divided into the control plane, which makes scheduling and management decisions, and worker nodes, which run the actual application containers. What replaced the term "Kubernetes master node"? The Kubernetes project now uses "control plane" instead of "master node" to describe the components that manage cluster state, though many engineers still use both terms interchangeably. Is a Kubernetes pod the same as a container? No. A pod is a wrapper that can hold one or more containers sharing the same network and storage context. Kubernetes schedules and manages pods, not individual containers directly. Why does Kubernetes use etcd instead of a regular database? Etcd is a distributed, strongly consistent key-value store built specifically for reliably storing configuration and state data across multiple machines, which is exactly what a cluster's source of truth requires. Do I need to manage the control plane myself? Not necessarily. Managed Kubernetes services handle the control plane for you, while you focus on worker node workloads — though self-managed clusters give you full control over both. A DevOps and cloud infrastructure partner can help you decide which approach fits your team. Final Thoughts Kubernetes architecture can look intimidating from the outside, but it comes down to a simple idea: a control plane that decides what should happen, and worker nodes that make it happen — with a constant feedback loop keeping the two in sync. Once you can trace a request from kubectl through the API server, scheduler, kubelet, and container runtime, the rest of Kubernetes — Deployments, Services, Ingress, Helm charts — becomes far easier to reason about. If you're planning a Kubernetes migration, designing a production-grade cluster, or just need a team that lives in this stuff daily, take a look at what Technovez's engineering and DevOps services can do for your roadmap, learn more about our team, or browse more guides on our blog.

Ready to Build on Kubernetes the Right Way?
Designing a reliable, secure, and cost-efficient Kubernetes architecture takes more than reading a guide — it takes real-world cloud and DevOps expertise. Technovez helps startups and enterprises design, migrate to, and manage production Kubernetes clusters tailored to their stack and growth plans.
Talk to our cloud & DevOps team →
Have a project in mind? Contact Technovez today and let's discuss how we can help you architect infrastructure that scales with your business.