The cluster's components

You have spent the whole course asking Kubernetes for things. This lab goes to the other side of the counter: a guided walk, without writing a single line of YAML, to put a face to the machinery that has been serving you.

It comes at the end on purpose. Each of these components is explained in the book where it is needed and not all together (kube-proxy in the Networking chapter, the kube-scheduler in the Scheduling one), so until now you would have had nothing to relate them to. Now you do. Next to each one you will see where the book covers it, in case you want to go back.

And it is a special cluster for the occasion. The rest of the course uses k3s, a distribution that packs all of Kubernetes into a single binary (extremely convenient, but opaque). Today the playground is vanilla Kubernetes installed with kubeadm, where each component runs separately and in plain view. A control plane on the cplane-01 machine and worker nodes where the applications will run.

Step 1: The nodes

Open the dev-machine tab and ask for the map:

kubectl get nodes -o wide

There is the cluster's fundamental division: cplane-01 with the control-plane role (the brain) and the worker nodes (the muscle). That command you just ran, by the way, has already crossed half the cluster: kubectl has talked over HTTPS to the API server, which is Kubernetes's single front door. Nobody (not you, not the internal components) talks to anyone except through it.

Step 2: The control plane, component by component

The brain's components are not mysterious daemons: in a kubeadm cluster they are Pods, and they live in the kube-system namespace. Look at them:

kubectl get pods -n kube-system -o wide

Find these four, all with the -cplane-01 suffix because they run on the control plane:

• kube-apiserver: the front door. It validates and serves every API request. → the Kubernetes architecture chapter, and its admission chain in the Security one.
• etcd: the memory. A key-value database where the whole state of the cluster lives; it is the only thing Kubernetes needs backed up. → Appendix D.
• kube-scheduler: the assigner. It decides on which node each new Pod should run (and it only decides: it runs nothing). → the Scheduling chapter, where you also find everything you can do to influence that decision.
• kube-controller-manager: the persistent one. It runs the control loops that tirelessly compare the desired state with the current one and correct the difference. Kubernetes's declarative "magic" comes from here. → Appendix D, and the loop itself in the Extensibility chapter, where you write one.

Notice also the ones that do not carry the control plane suffix: the kube-proxy Pods (there is one per node in the cluster, control plane included) and the coredns ones. We will come back to those in step 5.

Leave a record of the tour by saving the full inventory to a file:

kubectl get pods -n kube-system -o wide > /home/laborant/componentes.txt

Step 3: The static Pods and their secret folder

Here is a delicious chicken-and-egg problem: if the scheduler is a Pod, who scheduled the scheduler? The answer is on the node itself. Open the cplane-01 tab and look inside the Kubernetes configuration:

sudo ls -l /etc/kubernetes/manifests

Four YAML files, one per control plane component. They are static Pods: this node's kubelet watches that folder and directly runs any manifest it finds in it, without going through the API server or the scheduler. That is how the control plane starts: first the kubelet, which brings up these four Pods by reading the disk, and with them the cluster starts. You can peek into one (you won't understand every field yet, and that's fine):

sudo head -20 /etc/kubernetes/manifests/kube-scheduler.yaml

Step 4: The kubelet, the one that cannot be a Pod

You are still on cplane-01. The kubelet is the agent that runs on every node and turns the cluster's decisions into real containers, talking to the runtime (here, containerd). And it has a peculiarity you may already have deduced from the previous step:

systemctl status kubelet

It is a systemd service, an operating system process. It cannot be a Pod, by pure logic: someone has to be there before the Pods to run them. It is the only component in this lesson that lives outside the cluster it holds up.

The book covers it in the Kubernetes architecture chapter, and how it talks to the container runtime (CRI, containerd, runc) in Appendix D.

Step 5: The ones that are on every node

Go back to the dev-machine tab for the last two protagonists:

kubectl get daemonset,deployment -n kube-system

• kube-proxy shows up as an object called DaemonSet, whose mission is to guarantee one copy on every node. It programs each machine's local network rules so that Service traffic reaches its destination. → open the Networking chapter, because it makes no sense without the Service; the DaemonSet, in the Workloads one.
• CoreDNS is the cluster's internal DNS server, and it runs as an ordinary Deployment, the same kind of object you use for your applications. → the Networking chapter, CoreDNS section.

If you feel like seeing it all drawn out, the Explorer tab shows the object graph of kube-system live.

The summary to take with you to the rest of the course

• Everything goes through the API server; everything is remembered in etcd.
• The scheduler decides where; the controllers insist until the current state matches the desired one.
• The kubelet runs things on every node (and it is systemd, not a Pod); kube-proxy routes on every node; CoreDNS gives things names.
• kubeadm's control plane is static Pods read from /etc/kubernetes/manifests.

Notice that you have been using almost everything in this lesson without seeing it: every kubectl apply in the course has gone through the API server, ended up in etcd, been placed by the scheduler and been run by a kubelet.

And there is one thing left to do with this machinery, which is to break it. The next lesson closes the course by turning off the kube-scheduler of this same kind of cluster, to see what stops working and (what surprises almost everyone) what keeps working, unbothered.