How do you manage dozens or hundreds of computer programs running across many servers without going crazy? That is the problem Kubernetes solves. For your KCNA exam, understanding the architecture — the brain (control plane) and the body (worker nodes) of Kubernetes — is essential because nearly every question about how Kubernetes works ties back to this split between planning and doing.
Jump to a section
A simple way to picture Kubernetes Overview and Core Components
Have you ever watched a busy restaurant kitchen during a dinner rush? How does a chef manage dozens of orders without burning everything?
In a restaurant, the head chef acts like the control plane. They decide the menu (the specifications for each dish), assign tasks to different stations (the node components), and monitor the overall flow of orders. The head chef does not chop vegetables or grill steak themselves. Instead, they give instructions to the line cooks, who work at specific stations: the grill cook, the vegetable prep cook, the sauce chef. Each cook is like a node in a Kubernetes cluster. They have their own tools and ingredients (CPU, memory, storage) and execute the tasks the head chef gives them.
When a new order comes in — say, a table orders a steak and a salad — the head chef checks the order against the menu, decides which station should handle each part, and ensures the cooks have the right ingredients. If the grill cook is overwhelmed, the head chef might route the steak order to another available cook. This is exactly how the Kubernetes scheduler works: it decides which server (node) should run each application container based on available resources. If a cook calls in sick, the head chef reassigns their tasks to someone else, just like the Kubernetes control plane detects a failed node and moves its workloads to a healthy one.
The waiters (users or external traffic) interact only with the head chef or the expediter (the API server). They never walk into the kitchen to tell a specific cook what to do — that would cause chaos. Similarly, in Kubernetes, all communication goes through the API server, which records every request in a central log (the etcd database) so the whole team knows what is happening. The restaurant runs smoothly because the head chef enforces the menu and the cooks follow orders, just like Kubernetes runs applications reliably by separating decision-making (control plane) from the actual cooking (worker nodes).
Kubernetes is an open-source system for automating the deployment, scaling, and management of containerised applications. Containers are lightweight, portable packages that include an application and all its dependencies so it runs consistently on any machine. Before Kubernetes, IT teams managed applications on individual servers. If a server failed, the application went down until someone manually fixed it. If traffic spiked, someone had to manually add more servers. Kubernetes automates all of that.
The architecture has two main parts: the control plane and the worker nodes. Think of the control plane as the brain and the worker nodes as the muscles. The control plane makes global decisions about the cluster — a cluster is a group of servers that Kubernetes treats as a single pool of resources. It decides what applications to run, where to run them, and what to do if something fails. The nodes are the servers that actually run your applications.
Let us break down the control plane components:
API Server (kube-apiserver): This is the front door. All communication inside the cluster or from outside goes through the API server. It validates and processes requests, then stores the results in the etcd database. Think of it as the receptionist who logs every request and makes sure it is formatted correctly before sending it to the right department.
etcd: This is the cluster's brain memory. It is a highly reliable key-value store that holds all configuration data and the current state of the cluster — what applications are running, where they are, what their health status is. If etcd goes down, the cluster cannot make decisions. However, etcd does not run applications; it just stores facts.
Scheduler: This component watches for new application requests (called Pods — the smallest deployable unit in Kubernetes) and decides which node should run each one. It considers node resources (CPU, memory), any constraints the application requires, and load balancing. The scheduler does not actually run the Pod; it assigns it to a node.
Controller Manager: This is a collection of controllers, each responsible for a different aspect of the cluster. For example, the Node Controller watches for nodes that go offline and reassigns their workloads. The Replication Controller ensures the desired number of Pod replicas are running. If a Pod crashes, the controller manager notices and creates a new one.
Now the worker node components:
Kubelet: This is the agent that runs on every node. It receives instructions from the API server about what Pods to run, then ensures those containers are actually running. It reports back to the control plane about the node's health and the status of each Pod.
Kube-proxy: This handles networking. It maintains network rules on each node, allowing traffic to reach the correct Pods inside the cluster. It can do simple load balancing across Pods.
Container Runtime: This is the software that actually runs the containers. Docker is one example, but Kubernetes supports others like containerd and CRI-O.
Why does this architecture exist? Because it separates concerns: the control plane manages the desired state (what you want to happen), and the nodes execute it. This makes the system scalable — you can add more nodes without touching the control plane — and resilient: if a node fails, the control plane simply moves its work to another node without human intervention. Before Kubernetes, operations teams wrote complex scripts or used configuration management tools like Puppet or Chef to achieve similar results, but those were slower, more fragile, and harder to scale. Kubernetes replaces manual labour with automated, declarative management.
A key concept is declarative management: you tell Kubernetes what you want (for example, 'run three copies of my web app') rather than how to get there. Kubernetes handles the how by continuously comparing the current state to the desired state and making changes to match. This is why the control plane components work together — they maintain a feedback loop that keeps your applications running as you intended.
User submits a deployment request
You use kubectl or a CI/CD pipeline to send a YAML file to the API server. This file defines the desired state: for example, 'run three replicas of my-web-app using image nginx:1.21'. The API server validates the request (checks permissions, formatting) and stores the specification in etcd.
API server records the desired state in etcd
etcd stores the entire cluster state as key-value pairs. The API server writes the new deployment specification into etcd. This ensures that if any component restarts, it can read the latest state from etcd.
Scheduler watches for unscheduled Pods
The scheduler constantly monitors the API server for new Pod objects that have not yet been assigned to a node. When it sees the new Pods (created by the controller manager based on the deployment), it evaluates each Pod's resource requests and constraints, checks available nodes, and runs a scoring algorithm to pick the best node.
Scheduler binds the Pod to a selected node
The scheduler updates the Pod object in etcd (through the API server) with the name of the chosen node. This binding is stored so that the kubelet on that node knows it is responsible for that Pod.
Kubelet on the node executes the Pod
The kubelet on the selected node watches the API server for Pods assigned to it. When it sees a new Pod, it communicates with the container runtime (e.g., containerd) to pull the container image and start the container. The kubelet also sets up the Pod's network namespace and mounts any volumes.
Kube-proxy updates network rules
Kube-proxy on each node updates iptables or IPVS rules so that traffic to the Service (the stable network endpoint) is forwarded to the new Pod's IP address. This ensures clients can reach the application without knowing the Pod's specific IP.
Controller manager ensures ongoing health
The controller manager's Replication Controller monitors the number of running Pod replicas. If a Pod crashes or a node fails, the controller sees that the actual count is below the desired count, and creates a new Pod request to replace it, repeating the scheduling and execution steps.
Imagine you are an IT administrator at a medium-sized e-commerce company. Your team has developed a new online store using microservices — dozens of small applications that each handle one task, like user login, product search, payment processing, and order tracking. Without Kubernetes, you would have to provision servers manually, install each service, set up networking between them, configure health checks, and write scripts to restart failed services. This is time-consuming and error-prone. Instead, your company has adopted Kubernetes.
Here is what a typical day might look like:
Morning: You receive a notice that the marketing team plans a flash sale next week, expecting traffic to triple. You log into the Kubernetes dashboard and update the deployment configurations for your web front-end and product search service, increasing the desired number of replicas from 5 to 20. You also set up horizontal pod autoscaling, which tells Kubernetes to automatically add more Pods when CPU usage exceeds 70%. You do not need to provision new servers manually; the cluster will schedule the Pods onto existing nodes or, if you use a cloud provider like AWS or Azure, automatically add nodes through cluster autoscaler.
Midday: A node goes offline due to a hardware failure. The Kubernetes control plane detects this within seconds because the kubelet stops sending heartbeats to the API server. The controller manager immediately schedules the Pods that were running on that failed node onto healthy nodes. Customers continue shopping without noticing any interruption. You receive an alert about the node failure, but your only action is to request a replacement from the data centre team; Kubernetes handles the workload migration automatically.
Afternoon: The development team deploys a new version of the payment service. They use a rolling update: Kubernetes gradually replaces old Pods with new ones, ensuring no downtime. If the new version has a bug, the health checks fail, and Kubernetes automatically rolls back to the previous version. You watch the deployment progress in the dashboard and approve the rollout once all Pods are healthy.
Evening: You perform routine maintenance on one of the nodes — updating the operating system kernel. You use the command 'kubectl drain' to evict the Pods gracefully from that node, then apply updates, and then 'kubectl uncordon' to bring it back into service. The scheduler moves the Pods back as needed.
The tools you use daily include kubectl (the command-line tool to interact with the Kubernetes API), the Kubernetes dashboard (a web UI), and monitoring tools like Prometheus and Grafana. In a team setting, you might also use GitOps practices: storing all cluster configurations in a Git repository, then letting a tool like Argo CD sync those configurations to the cluster automatically. This ensures that any changes are reviewed, tested, and auditable.
In summary, an IT professional uses Kubernetes to automate the heavy lifting of deploying and managing applications, freeing them to focus on architecture, security, and improving the developer experience, rather than babysitting individual servers.
The KCNA exam tests your understanding of Kubernetes architecture and core components in several ways. First, know the two main divisions: control plane (master node components) and worker nodes. The exam loves to ask which component does what, especially distinguishing the API server from etcd, and the scheduler from the controller manager.
Key exam topics to memorise:
The API server is the only component that talks directly to etcd. No other component can write to etcd except through the API server.
The scheduler does not run Pods; it only assigns them to nodes. The kubelet on the node actually runs them.
The controller manager contains multiple controllers; know the names of at least three: Node Controller, Replication Controller, Endpoints Controller.
etcd is a distributed key-value store; it must be backed up because if the cluster state is lost, you cannot recover applications.
Kube-proxy handles networking rules, not DNS. DNS in Kubernetes is typically provided by CoreDNS, which is a separate add-on.
The container runtime (e.g., containerd) is the lowest-level component that actually runs containers, not the kubelet. The kubelet instructs the runtime but does not execute containers itself.
Common traps on the exam:
They might describe a scenario and ask 'which component performs this action?' If the action involves deciding where to place a Pod, the answer is scheduler. If it involves ensuring a crashed Pod is replaced, it is the controller manager (specifically the Replication Controller). If it involves storing the configuration, it is etcd. If it involves authenticating a user request, it is the API server.
They might ask what happens if the scheduler fails. The correct answer is that existing Pods continue running, but no new Pods can be scheduled until the scheduler is restored. The control plane components are designed to be independent for the most part.
They may present a list of components and ask which are part of the control plane versus worker node. A common mistake is including kubelet or kube-proxy in the control plane list. They are always on worker nodes.
They might ask about the function of etcd. Remember: etcd stores configuration and cluster state, not application data. Application data is stored in persistent volumes, which are separate concepts.
To memorise, create flashcards: one side has the component name, the other has its primary function and which part of the cluster it belongs to. Practise drawing the architecture diagram by hand — this helps during the exam. Focus on understanding the flow: a user (or script) sends a request to the API server -> the API server validates and stores it in etcd -> the scheduler watches for new Pods and assigns them to nodes -> the kubelet on the assigned node pulls the container image and runs it -> kube-proxy updates networking so traffic reaches the Pod. This end-to-end flow is tested repeatedly.
The control plane components (API server, etcd, scheduler, controller manager) manage the cluster state and make decisions, while worker nodes run the actual application containers.
The API server is the only entry point for all operations; every request to the cluster must go through it, and it stores all state in etcd.
The scheduler assigns Pods to nodes based on resource availability and constraints, but does not run them — that is the kubelet's job on each node.
The controller manager runs multiple controllers that continuously enforce the desired state, such as ensuring the correct number of Pod replicas are running.
If a node fails, the control plane detects the failure through missing heartbeats and reschedules its Pods onto healthy nodes automatically.
Kubernetes uses a declarative model: you specify the desired state (e.g., 'run 3 copies'), and the control plane works to make the current state match it.
etcd is a key-value store for cluster configuration, not application data; it is critical and must be backed up regularly.
Worker nodes must run three essential processes: kubelet (agent), kube-proxy (networking), and a container runtime (e.g., containerd).
These come up on the exam all the time. Here's how to tell them apart.
Control Plane (Brain)
Runs the API server, scheduler, controller manager, and etcd
Makes global decisions about the cluster (what to run, where, and how many)
Does not run application containers directly
Worker Nodes (Muscles)
Runs kubelet, kube-proxy, and container runtime
Executes the actual application containers (Pods)
Reports back to the control plane on health and status
API Server
Validates and processes all external and internal requests
Stateless; can be scaled horizontally
Only component that writes to etcd
etcd
Stores all cluster state and configuration data
Stateful; requires backups and high-availability setup
Does not accept direct requests from users; only API server talks to it
Scheduler
Decides which node a new Pod will run on
Only watches for unscheduled Pods (without node assignment)
Does not ensure the Pod continues running after scheduling
Controller Manager
Watches the overall state of the cluster and ensures desired state
Contains multiple controllers (Node, Replication, Endpoints, etc.)
Creates replacement Pods when ones crash or are deleted
kubelet
Acts as the node agent, ensuring Pods are running as instructed
Reports node health and Pod status to the API server
Interacts with the container runtime to start and stop containers
kube-proxy
Handles network rules for Service traffic routing and load balancing
Does not interact with containers directly; only configures iptables or IPVS
Does not report node health; that is the kubelet's job
Mistake
The control plane and the master node are the same thing; there is only one master node in a cluster.
Correct
The control plane is a set of processes (API server, etcd, scheduler, controller manager) that can run on one or more nodes. In production, you run multiple copies across at least three nodes for high availability. The term 'master node' is deprecated; the KCNA uses 'control plane nodes'.
Beginners often think of a single server doing all the thinking, but Kubernetes is designed for resilience. The exam tests this distinction explicitly.
Mistake
Kubernetes runs containers directly on nodes without any intermediate agent.
Correct
Kubernetes uses a daemon called kubelet on each node, which receives instructions from the API server and communicates with the container runtime to run the containers. The kubelet is a mandatory component on every node.
People confuse containers with Pods and think the scheduler directly launches processes. In reality, the node must have an agent that takes orders from the central brain.
Mistake
The scheduler decides which applications to run; it prioritises workload types.
Correct
The scheduler only decides where to place a Pod (which node), not what to run. What to run is defined by the user in Deployment or Pod specifications. The scheduler uses resource availability and constraints to choose a suitable node.
The word 'scheduler' suggests it plans the entire workload, but its role is narrowly focused on placement. The controller manager handles the number of replicas and ensures the desired state.
Mistake
If the API server goes down, the cluster stops running all applications immediately.
Correct
Existing applications continue to run because the kubelet on each node continues executing the Pods it was told to run. However, you cannot deploy new applications, scale existing ones, or respond to node failures until the API server is restored. The cluster becomes 'stuck' in its current state.
Beginners assume the API server is a runtime dependency, but it acts more like a command centre: once orders are given, the nodes execute independently until new orders arrive.
Mistake
etcd stores application data like user uploads or database records.
Correct
etcd stores only cluster configuration and state data — what Pods exist, their IP addresses, secrets, ConfigMaps, and other metadata. Application data is stored separately using persistent volumes, cloud storage, or in-memory caches.
The word 'database' suggests application data, but etcd is a specialised configuration store. Mixing up state storage and data storage is a common exam trap.
Mistake
Kubernetes can only run on Linux; Windows containers are fully supported without limitations.
Correct
Kubernetes has supported Windows containers since version 1.14, but there are limitations: Windows nodes cannot be control plane nodes, they require specific CSI and CNI plugins, and many advanced networking features are not available. Linux is the primary platform for Kubernetes.
The official documentation highlights Windows limitations, but beginners often assume parity. The exam may test awareness that Windows support exists but is not equal to Linux.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A container is a running instance of a container image, like a single process. A Pod is a group of one or more containers that share the same network namespace and storage, and are scheduled together on the same node. In most cases, a Pod runs a single container.
No, etcd is a core component of the control plane. Without it, the API server has no place to store cluster state, so the cluster cannot function. There is no alternative for etcd in a standard Kubernetes cluster.
Existing Pods continue running, but no new Pods can be scheduled until the scheduler is restored. The cluster remains in its current state, but you cannot deploy new applications or scale existing ones.
In production, you run multiple replicas of the API server (typically 3 or more) behind a load balancer. If one API server instance fails, another handles requests. The API server itself is stateless; the state is in etcd, which also runs as a clustered service.
Kube-proxy manages network rules on each node to implement Service networking. It forwards traffic from a Service's stable IP address to the actual Pod IPs, and can provide basic load balancing across Pod replicas.
Yes, Kubernetes requires a container runtime installed on each node. Common choices are containerd, CRI-O, or Docker (via cri-dockerd). The kubelet communicates with the runtime through the Container Runtime Interface (CRI).
You've finished Kubernetes Overview and Core Components. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?