Kubernetes Architecture for the KCNA Exam: Control Plane, Nodes & Core Objects Explained

The Kubernetes Fundamentals domain is the single largest part of the Kubernetes and Cloud Native Associate (KCNA) exam — roughly 46% of your score. Almost half of the questions assume you can picture how a cluster is wired together: which component decides where a Pod runs, what actually starts the container, where cluster state is stored, and how a Service finds the Pods behind it.

If you can hold that mental model in your head, the architecture questions stop being memorization and become reasoning. This guide walks through Kubernetes architecture the way a practitioner thinks about it — control plane first, then worker nodes, then the core objects — with the specific distinctions the KCNA exam likes to test.

How the KCNA Exam Tests Architecture

The KCNA is a multiple-choice, proctored exam. It does not ask you to run kubectl commands, but it absolutely asks you to know what each command does and which component is responsible for the result. Expect questions phrased like:

“Which control plane component is responsible for assigning a Pod to a node?”
“Where does Kubernetes persist the cluster’s desired state?”
“What runs on every worker node and reports node and Pod status back to the control plane?”
“Which object guarantees a specified number of identical Pod replicas?”

Every one of those maps directly to a single component or object. Learn the responsibilities cleanly and you can answer by elimination even when the wording is unfamiliar.

The Two Planes: Control Plane vs Data Plane

A Kubernetes cluster is split into two logical groups of machines:

Plane	Also called	Job	Key components
Control plane	Master / management plane	Decides what should happen — the cluster’s brain	API server, etcd, scheduler, controller manager, cloud controller manager
Data plane	Worker nodes	Actually runs the workloads	kubelet, kube-proxy, container runtime

The recurring exam signal: the control plane makes decisions and stores state; worker nodes execute. If a question is about scheduling, state, or reconciliation, it lives in the control plane. If it’s about running containers, networking on the node, or reporting status, it’s a worker node component.

Production clusters run multiple control plane nodes for high availability, but for the exam the responsibilities matter more than the count.

Control Plane Components

kube-apiserver — the front door

The API server is the only component that talks to etcd, and it is the central hub every other component communicates through. When you run kubectl apply, your request hits the API server. When the scheduler wants to place a Pod, it goes through the API server. When kubelet reports status, it reports to the API server.

Key facts the exam rewards:

It exposes the Kubernetes REST API over HTTPS.
It handles authentication, authorization (RBAC), and admission control for every request.
It is stateless itself — all persistent state lives in etcd. This is why you can run several API server replicas behind a load balancer.

If a question asks “what is the single point all components communicate through,” the answer is the API server.

etcd — the cluster’s source of truth

etcd is a distributed, consistent key-value store that holds the entire state of the cluster: every object, its spec, and its status. If etcd is lost and unrecoverable, the cluster’s state is gone — which is why backing up etcd is a core operational task.

Exam-critical distinctions:

etcd stores desired and current state, not container images or application data.
Only the API server reads from and writes to etcd; no other component touches it directly.
It uses the Raft consensus algorithm, so production deployments run an odd number of members (3 or 5) to maintain quorum.

A common trap answer puts the scheduler or kubelet “writing to etcd.” They never do — they go through the API server.

kube-scheduler — placement decisions

The scheduler watches for newly created Pods that have no node assigned and selects the best node for each one. It does not start the Pod; it only decides where it should run by writing the chosen node name back through the API server.

How it decides, at a level the KCNA expects:

Filtering — eliminate nodes that can’t run the Pod (not enough CPU/memory, taints the Pod doesn’t tolerate, node selectors that don’t match).
Scoring — rank the remaining feasible nodes and pick the highest.

Concepts that influence scheduling and appear on the exam:

Resource requests — the scheduler uses a Pod’s requests, not its actual usage, to find a node with room.
nodeSelector, affinity/anti-affinity — constrain or prefer certain nodes.
Taints and tolerations — a node repels Pods that don’t tolerate its taint.

If a question is about which node a Pod lands on, the scheduler owns it.

kube-controller-manager — the reconciliation engine

Kubernetes is built on controllers — control loops that continuously compare desired state (what you declared) against current state (what exists) and take action to close the gap. The controller manager runs many of these controllers in a single process, including:

Node controller — notices when nodes go down.
ReplicaSet controller — ensures the right number of Pod replicas exist.
Deployment controller — manages rollouts and rollbacks.
Job controller — runs Pods to completion.

The big idea the exam keeps returning to is the reconciliation loop: you declare what you want, and controllers work continuously to make reality match. This is why Kubernetes is called declarative rather than imperative.

cloud-controller-manager — the cloud integration layer

When a cluster runs on a cloud provider, the cloud controller manager connects Kubernetes to that provider’s APIs — provisioning load balancers for Service type LoadBalancer, attaching storage volumes, and managing node lifecycle. Pulling cloud-specific logic into its own component is what lets the core Kubernetes code stay provider-agnostic. You don’t need deep detail here for KCNA, just recognize its role.

Worker Node Components

Every worker node runs three things, regardless of how many Pods it hosts.

kubelet — the node agent

The kubelet is the primary agent on each node. It:

Registers the node with the API server.
Watches the API server for Pods assigned to its node.
Instructs the container runtime to pull images and start/stop containers.
Runs liveness, readiness, and startup probes and reports Pod and node status back to the control plane.

Crucial distinction: the kubelet manages Pods that Kubernetes knows about. It does not manage arbitrary containers you start manually with Docker. If a question asks “what actually ensures the containers described in a Pod spec are running on the node,” it’s the kubelet.

kube-proxy — node networking

kube-proxy maintains the network rules on each node that implement the Service abstraction. When traffic is sent to a Service’s virtual IP (ClusterIP), kube-proxy’s rules (typically via iptables or IPVS) forward that traffic to one of the healthy backend Pods.

What to remember:

kube-proxy implements Service load balancing at the node level.
It does not route Pod-to-Pod traffic directly — that’s the job of the CNI plugin (the cluster’s networking implementation, e.g. Calico, Cilium, Flannel).

The exam likes to separate these: Pod-to-Pod connectivity = CNI; Service-to-Pod forwarding = kube-proxy.

Container runtime — running the containers

The container runtime is the software that actually pulls images and runs containers. Kubernetes talks to it through the Container Runtime Interface (CRI). Common runtimes include containerd and CRI-O.

A frequently tested historical point: Kubernetes removed the Dockershim in v1.24, so Docker Engine is no longer a directly supported runtime — though images you built with Docker still run fine, because they follow the OCI (Open Container Initiative) image standard that all CRI runtimes understand.

Core Kubernetes Objects

With the components understood, the objects you deploy build on top of them. These appear constantly on the KCNA.

Pods — the smallest deployable unit

A Pod is the smallest unit you can schedule. It wraps one or more containers that:

Share a network namespace — the same IP address and port space, so containers in a Pod reach each other over localhost.
Can share storage volumes.
Are always scheduled together onto the same node.

Most Pods run a single container. Multi-container Pods exist for tight helper patterns like sidecars (e.g. a logging agent next to the app). Pods are ephemeral — if one dies, it isn’t resurrected on its own. Something has to recreate it, which is why you rarely create bare Pods directly.

ReplicaSets — keeping N copies alive

A ReplicaSet ensures that a specified number of identical Pod replicas are running at all times. If a Pod crashes or its node fails, the ReplicaSet controller notices the gap and creates a replacement. You almost never create ReplicaSets directly — you create them indirectly through Deployments.

Deployments — declarative updates and rollbacks

A Deployment manages ReplicaSets to give you declarative updates, rolling upgrades, and rollbacks. When you change a Deployment’s image, it creates a new ReplicaSet and gradually shifts Pods over, keeping the app available throughout. If the rollout goes wrong, you can roll back to the previous ReplicaSet.

The hierarchy the exam expects you to recite:

Deployment  →  manages  →  ReplicaSet  →  manages  →  Pods  →  contain  →  Containers

For stateless applications, the Deployment is the workload object you reach for by default.

Services — stable networking for ephemeral Pods

Because Pods are ephemeral and get new IPs when recreated, you need a stable endpoint in front of them. A Service provides a constant virtual IP and DNS name and load-balances across the set of Pods that match its label selector.

The Service types the KCNA expects you to know:

Service type	What it does	Typical use
ClusterIP (default)	Stable internal IP, reachable only inside the cluster	Service-to-service traffic
NodePort	Exposes the Service on a static port on every node	Simple external access, dev/testing
LoadBalancer	Provisions an external cloud load balancer	Production external access on a cloud
ExternalName	Maps the Service to an external DNS name	Pointing to an out-of-cluster dependency

Services find their Pods through labels and selectors — the loose-coupling mechanism that ties almost every Kubernetes object together. A Service selecting app=web automatically routes to any Pod carrying that label, no matter which Deployment or node created it.

Putting It Together: The Life of a Deployment

Tracing a single request ties every piece together — and this end-to-end story is exactly the reasoning the exam rewards:

You run kubectl apply -f deployment.yaml. The request hits the API server, which authenticates it, validates it, and writes the Deployment object to etcd.
The Deployment controller (in the controller manager) sees a new Deployment and creates a ReplicaSet.
The ReplicaSet controller sees it needs N Pods and creates Pod objects — initially with no node assigned.
The scheduler notices the unscheduled Pods, filters and scores nodes, and binds each Pod to a node via the API server.
The kubelet on each chosen node sees a Pod assigned to it and tells the container runtime to pull the image and start the containers.
You create a Service; kube-proxy programs node network rules so traffic to the Service IP reaches the new Pods.

Every box in the architecture diagram played its part — control plane decided and recorded, worker nodes executed.

Common KCNA Architecture Mistakes

Confusing kubelet and kube-proxy. kubelet runs Pods; kube-proxy handles Service networking. Both run on every node, but their jobs are distinct.
Thinking the scheduler starts containers. It only decides placement; the kubelet and runtime start them.
Believing components write to etcd directly. Only the API server does.
Mixing up CNI and kube-proxy. Pod-to-Pod networking is the CNI plugin; Service routing is kube-proxy.
Treating Pods as durable. Pods are ephemeral; ReplicaSets and Deployments provide durability.

Practicing Until the Model Is Automatic

Architecture questions on the KCNA reward recognition speed. You want “which component assigns Pods to nodes?” to trigger “scheduler” instantly, without re-deriving it. The most reliable way to build that reflex is to work through realistic, scenario-based questions with detailed explanations, so each component’s responsibility gets reinforced under exam-like conditions.

The Kubernetes and Cloud Native Associate (KCNA) Mock Exam Bundle is built around full-length, performance-focused practice exams that cover the Kubernetes Fundamentals domain in depth, so you encounter these architecture patterns repeatedly before exam day and walk in with the whole cluster diagram in your head.

To go further, pair this with our KCNA study guide for a structured plan, the KCNA exam guide for 2026 for format and domain weightings, and KCNA practice questions to test yourself. If you’re mapping out where KCNA fits in your broader journey, the Kubernetes certification path guide and our CKA vs KCNA comparison show what comes next.

Frequently Asked Questions

How much of the KCNA exam is about architecture?

The Kubernetes Fundamentals domain — which includes architecture, the API, core objects, and containers — is the largest at roughly 46%. Understanding the control plane and worker node components is foundational to nearly half the exam.

Do I need to memorize kubectl commands for the KCNA?

You don’t run commands during the exam, but you should know what common kubectl operations do and which component produces the result. Conceptual understanding matters more than syntax for the KCNA.

What is the difference between the control plane and worker nodes?

The control plane makes decisions and stores cluster state (API server, etcd, scheduler, controller manager). Worker nodes run the actual workloads (kubelet, kube-proxy, container runtime). Decisions and state live in the control plane; execution happens on worker nodes.

Which component schedules Pods onto nodes?

The kube-scheduler. It watches for unscheduled Pods, filters and scores feasible nodes, and binds each Pod to the best one. It does not start the containers — the kubelet and container runtime do that.

Why are Pods considered ephemeral?

A Pod is not automatically recreated if it dies on its own. Durability comes from higher-level objects: a ReplicaSet maintains a target number of replicas, and a Deployment manages ReplicaSets to provide rolling updates and rollbacks.

What replaced Docker as the container runtime?

Kubernetes removed the Dockershim in v1.24. Clusters now use CRI-compatible runtimes like containerd or CRI-O. Images built with Docker still run, because they follow the OCI image standard.

Conclusion

Kubernetes architecture is the backbone of the KCNA exam, and it rewards a clean mental model over rote memorization. Remember the split: the control plane decides and stores (API server as the front door, etcd as the source of truth, scheduler for placement, controllers for reconciliation), and worker nodes execute (kubelet runs Pods, kube-proxy handles Service networking, the runtime runs containers). On top of that sit the core objects — Pods, ReplicaSets, Deployments, and Services — connected by labels and selectors.

Internalize how a single kubectl apply flows through every component, and the Kubernetes Fundamentals domain becomes the most reliable points on your exam. Reinforce the model with realistic practice, and you’ll walk in able to reason through any architecture scenario the KCNA puts in front of you.