Cluster Architecture and Lifecycle Management

A Kubernetes cluster is a group of computers that work together to run your applications. Think of it as a team. The team has a captain (the control plane) and several players (the worker nodes). Setting up, upgrading, and managing these nodes is called lifecycle management. Without it, your applications would stop working when a computer fails or when you need to install security patches.

First, cluster setup. To start a cluster, you need at least one control plane node and one worker node. The control plane runs several critical components. The most important is the API server (kube-apiserver). It is the front door. Every command you send to the cluster — like 'run this app' or 'scale up' — goes through the API server. It checks your identity and decides if you are allowed to do that action (authentication and authorisation). Next is the scheduler (kube-scheduler). It is the matchmaker. When you say 'I want 3 copies of my app running', the scheduler decides which worker node gets each copy. It looks at how much memory and CPU each node has free, and picks the best fit. Then there is the controller manager (kube-controller-manager). Think of it as the quality inspector. It constantly checks that the cluster is doing what you asked. If a node dies, the controller manager sees that your app only has 2 copies instead of 3, and it tells the scheduler to start a third copy on a healthy node. Finally, there is etcd. This is the cluster's brain. It stores all the configuration data — what apps are running, where they are, what their settings are. Everything is written to etcd. If etcd is lost, the cluster forgets everything.

Worker nodes are the computers that actually run your applications. Each worker node has three main parts. The container runtime (like Docker or containerd) is the engine that actually starts and stops the containers. The kubelet is the agent that talks to the control plane. The kubelet receives instructions from the API server and tells the container runtime what to do. It also reports back — 'I am healthy', 'I have 10% CPU left'. The kube-proxy handles networking. It makes sure that traffic from the internet reaches the right container on the right node.

Now, cluster upgrade. Software gets old and vulnerable. You must update the control plane and worker nodes regularly. A common method is a rolling upgrade. You upgrade one node at a time. First, you tell the cluster to stop sending new work to a node (cordon it). Then you move the running applications off that node to other nodes (drain it). Then you upgrade the node's software. Then you bring it back into service (uncordon it). Repeat for every node. This way, your applications never stop running.

Node management is about keeping nodes healthy. If a node runs out of disk space or has a hardware failure, you need to replace or repair it. You might also need to add more nodes if your application becomes popular. This is called scaling the cluster. You install the necessary software on a new machine and join it to the cluster using a token. The control plane then recognises it and starts assigning work to it.

Why does all this matter? Without planned upgrades, your cluster becomes insecure. Without node management, a single hardware failure can crash your entire application. The KCNA exam tests whether you understand these steps because real companies depend on clusters being reliable. A misconfigured cluster means lost customers and lost money.

Imagine you work for a company called FoodBox, a food delivery app that runs on Kubernetes. You are the junior platform engineer, and it is your first week. The senior engineer, Maria, asks you to help with the monthly cluster upgrade. The production cluster has 10 worker nodes and 3 control plane nodes. Your task is to upgrade the worker nodes from Kubernetes version 1.28 to 1.29 without dropping any customer orders.

What do you actually do step by step?

First, you log into the central management server (a bastion host). You check the cluster's current version by running a command like kubectl get nodes. This shows every node and its version. You see all nodes are at 1.28. You also check the pod status to see where the food-ordering app runs. It is on nodes 3, 5, and 7. You note that there are 5 replicas of the app, meaning if one node goes down, the other four keep serving.

Then you cordon the first node (node 3). You run kubectl cordon node3. This tells the scheduler: 'Do not put any new pods on node 3.' Node 3 still runs its existing pods, but no new work arrives. Next, you drain node 3. You run kubectl drain node3 --ignore-daemonsets. This moves all the pods off node 3 to other healthy nodes. The food-ordering app pods get rescheduled onto nodes 1, 2, 4, and 6. The system automatically spreads them. You watch the app's metrics dashboard. The customer orders keep flowing — no downtime.

Now you upgrade node 3. You SSH into the node (secure shell). You update the package manager and install the new kubelet and kubeadm packages. You run sudo apt update && sudo apt install kubelet=1.29 kubeadm=1.29. Then you restart the kubelet. You verify the node is running version 1.29 by running kubectl get nodes again. It shows node 3 at 1.29. You uncordon it: kubectl uncordon node3. Now node 3 is back in service and will receive new work.

You repeat this process for every node. Node by node. The whole upgrade takes 2 hours. Maria checks the logs and sees zero errors. The customers never felt a thing.

Node management is similar. Last month, node 8 started reporting disk pressure — its disk was 90% full. You cordoned and drained it. Then you logged in and found that old container logs were piling up. You cleaned up the logs and checked the disk space. It dropped to 30%. You uncordoned the node and it was back in service. If you had not cleaned it, the node would have become NotReady and the app pods would have been rescheduled anyway, but with unnecessary stress on the other nodes.

These real-world actions — cordoning, draining, upgrading, monitoring — are exactly what the KCNA exam expects you to describe.