Upgrade the cluster node compute-0 to match the version of the control plane node. You must connect to the correct host. Failure to do so may result in a zero score. [candidate@base] $ ssh cks000034 C

Question

Explanation

Kubernetes Worker Node Upgrade - Exam Explanation

Overall Goal

You are upgrading a single worker node (compute-0) so its kubelet and kubeadm versions match the control plane. In a kubeadm cluster, the control plane is upgraded first; worker nodes are upgraded independently afterward. A version skew between a worker's kubelet and the control plane's API server can cause scheduling issues and is unsupported beyond ±1 minor version.

The Correct Procedure

Step 0 - SSH through the correct jump hosts

# From your local machine:
ssh cks000034          # jump to the exam bastion

# From the bastion:
ssh compute-0          # hop to the worker node

Why: The exam grades you based on the node state. If you run commands on the wrong host, your changes won't register and you'll score zero. Always confirm your prompt hostname before proceeding.

Step 1 - Identify the target version (on the control plane node)

Before touching the worker, open a separate session to the control plane (or check from the bastion):

kubectl get nodes
# Look at the VERSION column for the control-plane node

Or on the control plane itself:

kubelet --version

Why: You need to know the exact version string (e.g., 1.29.4) so you install the right package. Guessing will break things.

Step 2 - Drain the worker node (from the control plane)

kubectl drain compute-0 --ignore-daemonsets --delete-emptydir-data

Why: This safely evicts all pods off the node before you touch system components. Without draining, you risk disrupting running workloads mid-upgrade. --ignore-daemonsets skips DaemonSet pods (they can't be evicted). --delete-emptydir-data allows pods using ephemeral storage to be evicted.

If skipped: Pods continue running on the node while you restart kubelet, causing brief unexplained pod failures or worse - corrupted state.

Step 3 - Upgrade kubeadm on the worker node

# On compute-0:
sudo apt-mark unhold kubeadm
sudo apt-get update
sudo apt-get install -y kubeadm=1.29.4-1.1   # match exact control plane version
sudo apt-mark hold kubeadm

Why: kubeadm on the worker applies the node-level config. It must be upgraded before running kubeadm upgrade node because the new command logic lives in the new binary. Packages are held to prevent accidental auto-upgrades.

Step 4 - Run kubeadm upgrade node

sudo kubeadm upgrade node

Why: This pulls the updated kubelet configuration from the control plane API server and applies it locally. It does NOT touch the control plane components - it's safe to run on a worker. This step is unique to workers (control plane uses kubeadm upgrade apply).

If skipped: The kubelet binary gets upgraded but runs with the old configuration, which can cause subtle misbehavior or certificate issues.

Step 5 - Upgrade kubelet (and kubectl) on the worker node

sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.29.4-1.1 kubectl=1.29.4-1.1
sudo apt-mark hold kubelet kubectl

Why: kubelet is the actual node agent - it must be at the target version. kubectl is optional on workers but good practice for consistency.

Step 6 - Restart and verify kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Why: daemon-reload is required whenever a systemd unit file changes (kubeadm upgrade node may have updated it). Without daemon-reload, systemd runs the old unit definition even after restart.

Step 7 - Uncordon the node (from the control plane)

# Exit compute-0 first:
exit

# Back on the control plane or bastion:
kubectl uncordon compute-0

Why: Draining marks the node SchedulingDisabled. Without uncordoning, the scheduler will never place new pods on it, leaving you with reduced cluster capacity.

Verify:

kubectl get nodes
# compute-0 should now show Ready and the correct version

Step 8 - Exit the compute node

exit   # back to bastion/base

The question explicitly asks for this - exam environments sometimes check for dangling SSH sessions.

What Breaks If Steps Are Out of Order

Memory Tip

Think of it as "Drain → kubeadm → kubelet → Uncordon" - the same order you'd safely service a machine: stop traffic first, do the work, restart the service, restore traffic. The kubeadm step in the middle is the "fetch updated config" handshake between the node and the control plane.

No community discussion yet for this question.