Kubernetes is an orchestration platform that manages containerised applications across a cluster of machines. It solves the problem of manually deploying, scaling, and healing applications, which is impossible to do reliably at scale. For the CKA exam, you must understand how the control plane and worker nodes interact, because every administrative action you take depends on this architecture.
Jump to a section
A simple way to picture Kubernetes Architecture Overview
A restaurant kitchen is a system of specialised stations and people working together to turn raw ingredients into a finished meal for a customer. The head chef acts as the control plane. This chef never touches the stove directly. Instead, they decide the menu, receive orders from the front of house, plan the timing, assign tasks to line cooks, and check that every plate meets quality standards before it leaves the kitchen. The head chef's station has a whiteboard listing all current orders and their statuses. This is the brain of the operation.
The line cooks and their stations represent the worker nodes. Each cook has a specific section — grill, sauté, pastry — and each has their own set of tools, pans, and ingredients. When the head chef assigns a steak order to the grill cook, that cook is responsible for cooking it to specification using only their own equipment. They report back when it is done. If the grill cook is overwhelmed, the head chef can assign a prep cook to help or even reassign the order to a different station. The dishwasher, the expediter, and the food runners are all part of the support system, ensuring that the kitchen can scale from a quiet Tuesday lunch to a packed Saturday dinner without collapsing.
The critical point is that the head chef manages the state of the kitchen — they know every order, every cook's capacity, and every station's supplies — but they never do the actual cooking. That separation of decision-making from execution is exactly what Kubernetes architecture replicates: a central brain tells worker machines what to do, but the workers do the actual computing work.
Kubernetes architecture is a distributed system designed to run and manage containerised applications. A container is a lightweight, standalone package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings. Think of it as a shipping container for software — it isolates the application from the underlying server so it can run consistently anywhere. Kubernetes groups these containers into logical units called pods, which are the smallest deployable objects in the system.
A Kubernetes cluster consists of two main types of machines: control plane nodes and worker nodes. The control plane is the brain of the cluster. It makes global decisions about the cluster — scheduling new workloads, detecting and responding to failures, and maintaining the desired state of all applications. The kube-apiserver is the front door of the control plane. All communication, whether from a human using kubectl, from internal components, or from external automation, goes through this API server. The etcd is a distributed key-value store that acts as the cluster's source of truth. It stores all configuration data and state information. If etcd is corrupted, the cluster loses its memory. The kube-scheduler watches for newly created pods that have no node assigned and selects the best worker node for them based on resource requirements, policies, and constraints. The kube-controller-manager runs controller processes that regulate the state of the cluster. For example, the node controller notices when a worker node goes down and the replication controller ensures the correct number of pod replicas are running.
Worker nodes are the machines that actually run your applications. Each worker node runs three essential components: - kubelet: An agent that communicates with the control plane. It receives pod specifications from the API server and ensures that the containers described in those pods are running and healthy. - kube-proxy: A network proxy that maintains network rules on each node. It handles routing traffic to the correct pods, whether the traffic comes from inside or outside the cluster. - Container runtime: The software responsible for actually running containers. Docker used to be the default, but Kubernetes now supports any runtime that conforms to the Container Runtime Interface (CRI), such as containerd or CRI-O.
The entire system works on a declarative model. You declare the desired state of your application — for example, 'I want three copies of my web server running' — by writing a YAML file and sending it to the API server. The control plane reads that desired state, compares it to the current state, and takes action to reconcile them. If a pod crashes, the controller notices that the current state (two healthy pods) does not match the desired state (three) and starts a new pod. This continuous loop of check and correct is the core of Kubernetes architecture.
Before Kubernetes, operators managed individual servers manually. They would SSH into a machine, install dependencies, start an application, and hope it stayed running. When traffic increased, they added more servers by hand. When a server failed, they scrambled to restore service. Kubernetes replaces this fragile approach with a self-healing platform that separates the decision-making about where and how to run applications from the actual execution on individual servers. This architecture enables deployments that are resilient, scalable, and consistent across environments, from a developer's laptop to a multi-region cloud infrastructure.
User submits a desired state
An administrator writes a YAML file defining a Deployment with three replicas of a containerised web server. They run 'kubectl apply -f deployment.yaml'. This command sends an HTTP POST request to the API server, which validates the request and writes the desired state to etcd.
API server stores the state
The API server persists the Deployment definition into etcd. Etcd stores the data as a key-value pair, with the key being the resource path (e.g., /registry/deployments/default/my-deployment) and the value being the full YAML representation. This is the cluster's new source of truth.
Controller manager notices a difference
The Deployment controller, which is one of the controllers inside the controller manager, constantly watches the API server for new or updated Deployment objects. It detects that the desired replicas (3) do not match the current replicas (0). It creates a ReplicaSet object, which in turn creates Pod objects in the API server.
Scheduler selects a worker node
The scheduler watches for newly created Pod objects that have no 'nodeName' field set. For each unassigned pod, it evaluates all worker nodes based on resource requirements, affinity rules, and taints/tolerations. It selects the best-fit node and updates the pod object with the node name via the API server.
Kubelet runs the containers
The kubelet on the selected worker node watches the API server for pods assigned to its node. It sees the new pod specification, tells the container runtime to pull the image and start the container, and then reports the pod's status back to the API server.
Consider a medium-sized e-commerce company that runs its online store on a Kubernetes cluster. The infrastructure team has five control plane nodes spread across three availability zones in a cloud provider like AWS. The company has 50 worker nodes, each a virtual machine with 8 CPU cores and 32 GB of RAM. The application stack includes a front-end web server, a product catalogue API, a user authentication service, and a MySQL database.
One Tuesday morning, the marketing team launches a flash sale, and traffic to the website spikes to ten times the normal load. Here is what happens step by step in the Kubernetes architecture:
The company's team had previously defined a Deployment manifest that declared a desired state of 10 replicas of the web server, with CPU and memory resource limits. When the traffic surge hits, the existing pods begin to use more CPU. The kubelet on each worker node reports resource metrics to the control plane via the API server. The Horizontal Pod Autoscaler (HPA), a controller running inside the controller manager, detects that the average CPU utilisation across web server pods has exceeded the threshold of 80%. The HPA updates the desired replica count in the Deployment's specification via the API server. The scheduler then selects the best worker nodes for the new pods based on current resource availability and any pod affinity or anti-affinity rules. The kubelets on those nodes receive instructions to pull the container image from the registry and start the new pods. Within minutes, the cluster has scaled from 10 to 30 web server pods, spreading the traffic load across them.
The practical actions an IT professional takes with Kubernetes architecture include:
Writing and updating YAML manifests to define Deployments, Services, and other resources.
Running kubectl get nodes to monitor the health of worker nodes.
Investigating why a pod is stuck in 'Pending' state by running kubectl describe pod — this often reveals that the scheduler could not find a node with enough resources.
Inspecting control plane component logs, for example kubectl logs -n kube-system kube-scheduler-master, to diagnose why pods are not being scheduled.
Configuring etcd backups because losing the control plane's state can bring the entire cluster down.
Setting up monitoring and alerting on control plane endpoints such as the API server's /healthz path.
If the company did not use Kubernetes, the team would have to manually provision new servers during the flash sale, deploy the application code, and hope the database could handle the load. With Kubernetes, the scaling happened automatically, and the team only needed to monitor the process from their dashboards.
The CKA exam tests your practical ability to interact with a live Kubernetes cluster from the command line, not just theoretical knowledge of the architecture. However, understanding the architecture is essential because you will need to diagnose cluster issues, and the exam questions will present scenarios that force you to reason about component relationships.
The exam questions about Kubernetes architecture fall into several distinct types:
Questions that ask you to identify which component is responsible for a specific task. For example: 'Which control plane component maintains the desired state of the cluster?' The correct answer is the controller manager. The exam may present etcd, scheduler, and API server as distractors.
Troubleshooting scenarios where a node is not healthy. The exam typically asks you to run kubectl get nodes to see the node status, then investigate whether the kubelet is running on the problematic node using systemctl status kubelet.
Questions about component communication. For instance: 'Through which component does the kubelet on a worker node communicate with the control plane?' The answer is the API server. The exam might try to mislead you by suggesting a direct connection to etcd.
Scenarios requiring you to check the scheduler logs or the controller manager logs to understand why a pod is not being scheduled or why a Deployment is not scaling.
Questions that test your understanding of how kubectl commands map to architecture components. For example, running kubectl apply -f deployment.yaml sends a request to the API server, which then writes the desired state to etcd.
Key concepts the CKA loves to test:
The API server is the only component that communicates directly with etcd. No other component, including the scheduler or controller manager, should ever access etcd directly.
The scheduler only decides which node a pod should run on; it does not actually start the pod. The kubelet on the selected node receives the pod spec from the API server and uses the container runtime to start the containers.
The controller manager is a collection of controllers. The most important ones for the exam are the Node Controller and the Replication Controller (now part of the Deployment controller).
etcd requires a backup strategy. The exam may ask you to take a snapshot of etcd using etcdctl snapshot save or restore it.
Common traps the exam sets:
Offering 'kubelet' as the component that schedules pods. This is wrong. Kubelet only runs pods assigned to its node.
Suggesting that the API server stores data directly. It does not; it always writes to etcd.
Implying that kube-proxy handles DNS resolution. Kube-proxy handles network routing; CoreDNS is a separate component.
Asking about a 'master node' instead of 'control plane node'. The exam uses both, but modern Kubernetes documentation emphasises 'control plane'.
The API server is the only component that communicates directly with etcd; all other components and users interact with the API server.
The scheduler only decides which node a pod runs on; it does not start or manage containers.
The kubelet is the primary agent on each worker node, responsible for ensuring containers are running as specified by the control plane.
Etcd is a distributed key-value store that acts as the cluster's source of truth; losing it means losing the entire cluster's state.
Kubernetes uses a declarative model: you specify the desired state, and controllers continuously reconcile the current state to match it.
Worker nodes run three essential components: kubelet, kube-proxy, and a container runtime.
Control plane components can be replicated for high availability, but only one instance of the scheduler and controller manager should be active at any time to avoid conflicting decisions.
Kube-proxy handles network rules for service-to-pod communication, but it does not handle DNS resolution or encryption.
These come up on the exam all the time. Here's how to tell them apart.
API Server
Acts as the front door for all cluster interactions
Validates and processes all API requests
Does not store data itself; forwards writes to etcd
etcd
Acts as the cluster's persistent storage backend
Stores all cluster configuration and state as key-value pairs
Is not directly accessible by users; only the API server communicates with it
Scheduler
Runs on the control plane
Decides which node a pod should run on
Does not actually start or manage containers
kubelet
Runs on each worker node
Receives pod assignments from the API server
Starts and monitors containers using the container runtime
Controller Manager
Runs on the control plane
Contains controllers that regulate cluster state (e.g., node controller, replication controller)
Works with the API server to enforce desired state
kube-proxy
Runs on each worker node
Manages network rules for pod-to-pod and service-to-pod communication
Implements iptables or IPVS rules to route traffic
Pod
The smallest deployable unit in Kubernetes
Can contain one or more tightly coupled containers
Shares a network namespace and storage volumes among its containers
Container
A standalone runtime environment for software
Exists inside a pod; each pod typically has one container for simplicity
Has its own filesystem and process space, but shares the pod's network and volumes
Declarative Model
You specify the desired state (e.g., 'run 3 replicas')
Kubernetes automatically reconciles current state to match
Used in production with YAML files for repeatability
Imperative Model
You specify exact commands to achieve a state (e.g., 'kubectl run nginx')
You must manually track and correct drift
Useful for learning and debugging, but not for production automation
Mistake
The control plane runs on a single machine, and that machine is called the master.
Correct
The control plane is a set of processes that can run on multiple machines for high availability. The term 'master node' is outdated; modern Kubernetes refers to control plane nodes.
Older Kubernetes documentation and many outdated blog posts used the term 'master node', so beginners assume it is a single machine. The CKA exam expects you to know that control plane components are often replicated for resilience.
Mistake
kube-proxy is a DaemonSet that runs inside pods, not a separate binary.
Correct
kube-proxy is a system-level component that runs on each node, usually as a DaemonSet, but it operates as a network proxy at the OS level, not as a user-space application inside a pod.
Beginners confuse the deployment method (DaemonSet) with the component's nature. They think because it is deployed via a DaemonSet, it is 'just another pod'. In reality, kube-proxy has special privileges to modify iptables rules.
Mistake
etcd stores all Kubernetes data including container images.
Correct
etcd only stores configuration data and state information, such as pod specifications, Secrets, ConfigMaps, and cluster state. Container images are stored in a container registry (like Docker Hub or a private registry).
The word 'store' is vague. Beginners assume etcd is a general-purpose storage system that holds everything, including the actual application code. Understanding this distinction is critical because backing up etcd does not back up your container images.
Mistake
The scheduler runs on a worker node.
Correct
The scheduler is a control plane component that runs on one of the control plane nodes. It never runs on a worker node.
Beginners think that scheduling decisions happen on the node that will run the workload, because that is intuitive. However, the control plane is designed to centralise decision-making, so the scheduler is separated from execution.
Mistake
If a node fails, the kubelet on that node automatically reschedules the pods to a different node.
Correct
The kubelet only runs on the node it is assigned to. If a node fails, the kubelet stops working. The node controller, which runs inside the controller manager on the control plane, detects the node failure and reschedules the pods to other healthy nodes.
People naturally assume that the component closest to the problem (the kubelet on the failing node) handles the recovery. In reality, recovery is driven by the control plane, because the failing node cannot report its own status.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Control plane nodes run the components that manage the cluster, such as the API server, scheduler, and controller manager. Worker nodes run the actual application containers through the kubelet and container runtime. Control plane nodes are critical for cluster health; worker nodes are what run your workloads.
Yes, for development purposes you can run a single-node cluster using tools like Minikube or K3s. In production, you should have multiple control plane nodes for high availability, but technically all components can run on one machine.
Kubectl is a command-line tool that communicates with the API server over HTTPS. When you run 'kubectl get pods', it sends an HTTP GET request to the API server's /api/v1/pods endpoint, and the API server responds with the current state, which kubectl formats and prints to your terminal.
No, the scheduler runs only once in the cluster, typically on one of the control plane nodes. It is a central component that makes global scheduling decisions. Running multiple schedulers without proper configuration can lead to conflicting decisions.
If etcd fails, the cluster cannot read or write any state. Existing pods continue running, but you cannot deploy new applications, scale existing ones, or run 'kubectl get' commands. The API server becomes unresponsive. This is why etcd backups are critical for disaster recovery.
Yes, kube-proxy is a core component that runs on every node. It is responsible for implementing the networking rules that allow pods to communicate with each other and with the outside world. Without it, Services would not work correctly, and network traffic would not reach the correct pods.
You've finished Kubernetes Architecture Overview. Continue through the CKA study guide to build a complete picture of the exam.
Done with this chapter?