CKA Practice Question: Cluster Architecture, Installation and Configuration
Which THREE components run on every worker node in a Kubernetes cluster? (Choose THREE.)
⚠ Common exam trap
CNCF often tests the misconception that etcd or kube-apiserver are distributed across all nodes, but in a standard Kubernetes cluster, they are strictly control plane components and never run on worker nodes.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
kube-proxy
kube-proxy (B) is correct because it runs on every worker node and maintains the node's network rules (via iptables/IPVS) to implement Kubernetes Service load balancing and ClusterIP routing. kubelet (C) is correct because it is the node agent that runs on every worker node, registers the node with the API server, and manages Pod lifecycle by instructing the container runtime via the CRI. The container runtime (E) is correct because every worker node must have a CRI-compliant runtime (e.g., containerd or CRI-O) to actually pull images and run containers for Pods. In contrast, etcd (A) is the cluster's distributed key-value datastore and runs on control plane nodes, not worker nodes, and kube-apiserver (D) is the control plane's API front end, also not part of the worker node's required components.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
etcd
Why it's wrong here
etcd is a distributed key-value store that serves as the single source of truth for the entire Kubernetes cluster, persisting all objects, configurations, and state. It is a foundational control plane component, typically co-located on control plane nodes or run as an external cluster, and worker nodes do not need to maintain authoritative cluster state. Running etcd on a worker node would violate security boundaries and introduce unnecessary network latency for quorum operations.
- ✓
kube-proxy
Why this is correct
kube-proxy is a lightweight network proxy that runs on every node as a DaemonSet, implementing Kubernetes Service semantics by managing traffic rules via iptables, IPVS, or other compatible backends. Its core job is to translate a Service's virtual ClusterIP to the specific Pod endpoints selected by that Service, enabling automatic load balancing and service discovery across workers. A node without kube-proxy would fail to route service traffic, breaking connectivity to applications exposed through ClusterIP, NodePort, or LoadBalancer Services.
- ✓
kubelet
Why this is correct
The kubelet is the primary node agent that runs on every node, registering the node with the Kubernetes API server and watching for Pod assignments. It continuously reconciles the desired state by creating, starting, stopping, and deleting containers through the container runtime, as well as reporting node and pod health back to the control plane. Without a kubelet, a node is invisible to the cluster and cannot execute Pods, making it essential for worker node functionality.
- ✗
kube-apiserver
Why it's wrong here
The kube-apiserver is the frontend of the Kubernetes control plane, exposing the official API for all cluster interactions including authentication, authorization, admission control, and serving REST operations. As a centrally scaled component, it runs only on control plane nodes to maintain a consistent view of cluster state and apply centralized policies. Worker nodes do not host the API server; instead, they act as clients that send pod updates and resource status reports to it over the network.
- ✓
container runtime
Why this is correct
The container runtime is the underlying software responsible for actually running containers on a node, with common implementations including containerd, CRI-O, and (historically) Docker via the CRI bridge. The kubelet talks to the runtime through the Container Runtime Interface, issuing commands to pull images, create sandboxes, and launch containers. Since every Pod ultimately translates to one or more containers, a functioning container runtime is mandatory on all worker nodes—and also on control plane nodes that host system containers, though the question focuses on workers.
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
Key term
Container Runtime
A container runtime is software that runs containers by using the host operating system's kernel to isolate processes, manage filesystem layers, and handle networking.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.