CKA Practice Question: Cluster Architecture, Installation and Configuration
You need to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. After upgrading the control plane, what should you do on each worker node?
⚠ Common exam trap
Watch out — candidates often assume 'kubeadm upgrade node' alone handles pod eviction, but it only upgrades the node's components and does not automatically drain pods, making the drain step essential to avoid workload disruption.
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
✓
kubectl drain <node>; kubeadm upgrade node; kubectl uncordon <node>
The standard kubeadm upgrade workflow for worker nodes requires first draining the node to safely evict all pods, then running 'kubeadm upgrade node' to upgrade the kubelet and kube-proxy configuration, and finally uncordoning the node to make it schedulable again. This sequence ensures minimal disruption to workloads and follows the official Kubernetes upgrade documentation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubeadm upgrade node config --kubelet-version v1.29.0
Why it's wrong here
The kubeadm upgrade node command does not take a config subcommand; the correct syntax is simply kubeadm upgrade node, optionally with --kubelet-version v1.29.0 to override the kubelet version during the kubelet configuration upgrade. Running kubeadm upgrade node config would be rejected by kubeadm's argument parser, so no upgrade would occur. In the node upgrade workflow, kubeadm updates the local kubelet configuration, but the command must be invoked without the extraneous config token.
- ✗
kubectl delete node <node>; kubeadm upgrade node
Why it's wrong here
kubectl delete node removes the Node API object from the cluster rather than cordoning it and evicting its pods; if the kubelet is still running, it will simply re-register a new Node object, and pods running on the node are not gracefully rescheduled with respect to PodDisruptionBudgets. Draining is the required first step because it marks the node unschedulable, evicts all non-daemonset pods, and blocks rescheduling until the upgrade is complete. Deleting the node object can cause workloads to become Unknown and is not part of the supported kubeadm upgrade procedure.
- ✓
kubectl drain <node>; kubeadm upgrade node; kubectl uncordon <node>
Why this is correct
This is the correct per-node upgrade sequence: kubectl drain <node> first cordons the node and evicts its workloads—typically using --ignore-daemonsets in practice—then kubeadm upgrade node applies the new kubeadm and kubelet configuration to the node's local files, and finally kubectl uncordon <node> marks it schedulable again so new pods can be placed. Without draining, the kubelet may be restarted while pods are still running, and there is no graceful transition for the workloads. The uncordon step is essential after the upgrade, otherwise the node would remain unschedulable and workloads would not be scheduled back to it.
- ✗
kubeadm upgrade node; kubectl uncordon <node>
Why it's wrong here
The critical omission here is the kubectl drain <node> step before running kubeadm upgrade node; draining both cordons the node and evicts existing pods, which is necessary because kubeadm upgrade node stops and reconfigures the kubelet on that host. Since the node was never cordoned, running kubectl uncordon is a no-op and does nothing to preserve workload availability during the upgrade. This sequence would leave workloads vulnerable to interruption and does not match the documented kubeadm upgrade workflow.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Kubernetes Node Roles
Kubernetes Node Roles are labels assigned to machines in a cluster that define whether a node runs application containers (worker) or manages the cluster (control plane).
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 →
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.