Courseiva

CKA Practice Question: Cluster Architecture, Installation and Configuration

Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?

⚠ Common exam trap

Many exam-takers confuse the container runtime (which actually runs containers) with the kubelet (which orchestrates them), leading them to pick 'container runtime' because they think it directly ensures containers are running, but the kubelet is the agent that manages the pod lifecycle and delegates to the runtime.

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

kubelet

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in PodSpecs are running and healthy by communicating with the container runtime via the CRI (Container Runtime Interface). Without the kubelet, no pod or container lifecycle management can occur on that node.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • kubelet

    Why this is correct

    The kubelet is the Kubernetes node agent that runs on every node, including control-plane nodes. It registers the node with the API server, watches for Pod objects bound to that node, and continually drives the actual state of containers toward the desired PodSpec. It performs liveness, readiness, and startup probes and reports pod/node status back to the API server. Because it is the component that owns the pod lifecycle on a node, it is the only component in this list that is a required Kubernetes component on every node.

  • kube-scheduler

    Why it's wrong here

    kube-scheduler is a control-plane component, not a node agent. It runs on the control plane (or as multiple replicas for high availability) and watches the API server for unscheduled Pods—those with no nodeName set—then selects a suitable node based on resource requests, constraints, affinity, and topology. It makes a binding decision but never executes or supervises containers on a node. Therefore it is not installed or running as a per-node agent.

  • container runtime

    Why it's wrong here

    The container runtime—such as containerd or CRI-O—is indeed installed on every node, but it is not the Kubernetes component that manages pods on a node. It is an external software tool that uses Linux kernel features (namespaces, cgroups) to start/stop containers, using a lower-level interface (CRI/OCI) that kubelet calls. A node without a kubelet cannot be a Kubernetes node even if a runtime is present; the runtime alone does not communicate with the API server and does not enforce the desired pod state.

  • kube-proxy

    Why it's wrong here

    kube-proxy runs on every node as a DaemonSet, but it is a network reflector, not a pod-lifecycle manager. It watches the API server for Services and EndpointSlices and programs iptables/IPVS rules to load balance traffic to Pod backends over the cluster IP or nodePort. It never creates, reads, updates, or deletes pods, and it does not interact with the container runtime to manage containers. Thus it cannot be the node component that is responsible for pod management on every node.

About these practice questions

One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.