Control plane and node components

What each part of a Kubernetes cluster does, in plain words, how it is started, and where to read its settings.

A Kubernetes cluster is a group of machines that work together to run your apps. A few parts make the decisions; together they are called the control plane. The other machines, the worker nodes, do the actual work of running your apps. This lesson shows what each part does, how it is started, and where to read its settings. That last part matters most: the exam never asks you to draw the diagram below, it asks you to find things, such as which setting the API server runs with.

kubeadm, kubectl and kubelet: three names, three jobs

These three names look alike and confuse almost everyone at first, but they are completely different things:

What each part does

Here is every part with its job in plain words. kind, the tool behind this course's lab, builds its clusters with kubeadm, so these are the same parts and the same file paths you will meet on exam day.

What breaks when each part stops is a topic of its own. You will meet it in Control plane failures and Worker node failures.

Three ways the parts are started

Each part is started in one of three ways. Knowing which group a part is in tells you which tool to use when it breaks.

• As a normal Linux service: the kubelet and the container runtime. They start when the machine boots, and you check them with systemctl status kubelet.
• As static Pods: the API server, etcd, the scheduler and the controller manager. The kubelet starts them from files on the control plane node, as the next section shows.
• As ordinary Pods: kube-proxy and the network plugin (Calico in this lab), in the kube-system namespace. You check them with kubectl -n kube-system get pods.

Static Pods

Normally you create a Pod through the API server: kubectl sends it, the API server saves it, the scheduler picks a node, and that node's kubelet starts it. But the API server is itself a Pod. Who starts it, when there is no API server yet? The kubelet does, from a file.

A static Pod is a Pod defined by a YAML file in a folder on the node: /etc/kubernetes/manifests on kubeadm clusters. The kubelet runs every file in that folder and restarts the Pod if it stops. No API server and no scheduler are involved.

So that you can still see these Pods with kubectl, the kubelet also puts a read-only copy in the API, called a mirror Pod. Its name is the Pod's name plus the node's name, for example kube-apiserver-cka-control-plane. Deleting the mirror Pod changes nothing. To change or stop a static Pod, edit or delete its file.

# exam: ssh <node>    lab: docker exec -it cka-control-plane bash
grep staticPodPath /var/lib/kubelet/config.yaml
ls /etc/kubernetes/manifests
# etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

# From your workstation: a mirror Pod is owned by a Node and sourced from a file
kubectl -n kube-system get pod kube-apiserver-cka-control-plane \
  -o jsonpath='{.metadata.ownerReferences[0].kind}{" "}{.metadata.annotations.kubernetes\.io/config\.source}{"\n"}'
# Node file

Reading a part's settings

Exam questions often ask for a setting, such as the range of IP addresses that Services get. There are three places to read it; use whichever is quickest.

# 1. What the kubelet was told to run: the static Pod's file on the node
docker exec cka-control-plane grep -- --service-cluster-ip-range /etc/kubernetes/manifests/kube-apiserver.yaml

# 2. The same through the API, no node shell needed
kubectl -n kube-system get pod -l component=kube-apiserver \
  -o jsonpath='{.items[0].spec.containers[0].command}' | tr ',' '\n' | grep service-cluster

# 3. The kubelet keeps its own settings in a config file on each node
docker exec cka-control-plane grep -E 'staticPodPath|containerRuntimeEndpoint|cgroupDriver' /var/lib/kubelet/config.yaml

Always read the value from the cluster in front of you, never from memory. For example, kubeadm's default Service range is 10.96.0.0/12, but this lab uses 10.96.0.0/16.