CKA Practice Question: Cluster Architecture, Installation and Configuration

Answer analysis

Option-by-option breakdown

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

• ✗

  Drain the worker nodes and downgrade them to v1.28

  Why it's wrong here

  Downgrading Kubernetes components, including worker nodes, is generally unsupported and highly discouraged due to the potential for data corruption, inconsistent states, or complete cluster failure. Rolling back etcd schema changes and API incompatibilities between versions makes downgrades extremely risky. Furthermore, the standard upgrade path dictates that the control plane must be upgraded before or concurrently with worker nodes to maintain API compatibility, making a worker node downgrade an incorrect and destabilizing action in this scenario.

• ✗

  Uncordon the worker nodes

  Why it's wrong here

  Uncordoning worker nodes that are running a higher Kubernetes version (v1.29) than the control plane's API server (v1.28) would allow the scheduler to place new pods onto them. This version skew creates significant compatibility issues, as the newer kubelet might attempt to utilize API features or object schemas not recognized by the older API server. Such a mismatch can lead to pod failures, unexpected operational behavior, or even prevent nodes from properly registering and functioning within the cluster, compromising overall stability.

• ✓

  Upgrade the control plane nodes to v1.29

  Why this is correct

  Kubernetes upgrade best practices mandate that the control plane components, particularly the kube-apiserver, must be at a version equal to or higher than the kubelet running on worker nodes. Since the worker nodes have already been upgraded to v1.29, the immediate and correct next step is to upgrade the control plane nodes to v1.29. This action ensures API compatibility, allowing the kube-apiserver to properly communicate with and manage the newer kubelet versions, thereby preventing critical API mismatches and maintaining cluster health.

• ✗

  Restart the kubelet on all nodes

  Why it's wrong here

  Restarting the kubelet service on all nodes will only reinitialize the kubelet process and re-register the node with the API server; it does not perform any version upgrade of the kubelet itself. More importantly, restarting kubelet has no effect on the version of the control plane components, such as the kube-apiserver, kube-controller-manager, or kube-scheduler. The fundamental problem here is a version mismatch between the control plane and worker nodes, which a simple kubelet restart cannot resolve, requiring a full upgrade process instead.

Go deeper

Related to this question