Kubernetes: the Top View

A working Kubernetes cluster seen from above — five nodes, the control plane running as pods on two of them, kube-proxy on every one — and what happens when you run a pod and a Deployment with kubectl from your workstation.

A Kubernetes cluster is a set of computers, called nodes, and a pod is a few processes running on one of them. The simulator shows a working cluster of five nodes and you at a workstation across the internet: first what runs on each node, then what happens when you run a single pod, then a Deployment, and finally what deleting the Deployment removes. Later viewers take one subject at a time, starting with the pod.

The simulator's layout

The five nodes are in the middle, manage-1 and manage-2 on top and three workers under them. Each starts as a picture of a computer marked with the Kubernetes node symbol, and opens into a card showing what runs on it.
The kubelet is a port on each node's edge, on the side facing the rest of the cluster: what the control plane connects to in order to control the node. Every pod reaches the node through it.
Every component and kind carries its Kubernetes symbol: etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kube-proxy, the kubelet, and your pods and Deployment.
A node's card reads top to bottom: its pods, the system's own and yours, and at the bottom containerd and the computer itself. The control plane's pods are solid purple; the node components (the kubelet, containerd and kube-proxy) are teal.
The tour steps spotlight what they name: the rest of the cluster dims while those parts pulse.
You are at a workstation on the left, below the internet. Your wire runs through the internet to kube-apiserver, and every command you type travels along it; a terminal holds every command and its output.
etcd's records are on manage-1, drawn as a disk under the etcd pod that keeps them: each node and each of your objects, and one entry counting the system's own. In the etcd step the disk is written to, one record after another.
The cloud providers are at the top right: AWS, Google Cloud and Azure, with AWS as this cluster's. cloud-controller-manager, on manage-2, is linked to it.
The events are on the right, under the cloud providers. Every step so far, grouped by scene, with the current step's explanation open; a click opens any other, and Go back to this step returns to it.
The lit button is on the card whose turn it is; Step does the same. Messages fly between the programs that exchange them, and a YAML file that reaches the API server bursts into its pieces.

Nodes and pods: computers and processes

A node is a computer and a pod is a few processes on it:

Two services run on every node, outside any pod: containerd, the container runtime, and the kubelet, the node's agent. Nothing runs in a pod on a computer unless its kubelet started it.
A container is a process that the kernel keeps apart, with its own view of the files, the network and the other processes. The page gives each one its process number: ps on the node lists it.
A pod is its containers plus one network address, taken from its node's range, which lasts as long as the pod.

The control plane: five programs running as pods

The control plane is a group of programs, not a kind of computer: here it runs as pods on two ordinary nodes, manage-1 and manage-2.

etcd is the database. Every object (a node, a pod, a Deployment) is one record in it.
kube-apiserver is the hub: every node's kubelet keeps a connection open to it, the scheduler and the controller manager work through it, and you reach it across the internet, over HTTPS on port 6443. It alone reads and writes etcd, and it checks, for every request, who is asking, whether they may, and whether the object is valid.
kube-scheduler chooses a node for every pod that has none, and writes the choice into the pod.
kube-controller-manager runs the controllers: loops that compare what an object asks for with what exists, and create or delete objects to close the gap.
cloud-controller-manager connects the cluster to its cloud provider, here AWS. It learns which virtual machine stands behind each node and makes load balancers for Services; each provider ships its own, and a cluster outside any cloud runs none.

kube-proxy is a node component, like the kubelet and containerd: it runs as a pod on every node, the manage nodes included, and turns Services into forwarding rules in the node's kernel. Its pods live in the kube-system namespace beside the control plane's, because that namespace holds all of Kubernetes's own pods; the namespace does not make it part of the control plane. manage-1 carries a taint, node-role.kubernetes.io/control-plane:NoSchedule, that keeps your pods off it; manage-2's was removed, so the scheduler gives it your pods too.

A pod: from a YAML file to a running process

kubectl apply -f hello.yaml passes through four programs before a process runs:

kubectl reads the API server's address and your credentials from ~/.kube/config and sends the pod to kube-apiserver, which stores it in etcd with no node.
The scheduler sees a pod with no node, picks worker-2, and writes a binding.
The kubelet on worker-2 sees a pod bound to its node and has containerd create it: a sandbox with an address from the network plug-in, then the container.
The kubelet reports the pod Running, into the same record.

Deleting the pod stops the process, and nothing brings it back: no controller owns a bare pod.

A Deployment: pods a controller keeps running

A Deployment asks for a number of copies of a pod template, and the controllers make them:

The Deployment controller creates a ReplicaSet, named after a hash of the pod template.
The ReplicaSet controller creates the pod records, and the scheduler spreads them over the nodes that take them: the three workers and manage-2.
When a pod goes, the ReplicaSet controller counts one too few and creates a replacement, with a new name and a new address.

Deleting the Deployment: owners and the garbage collector

Deleting one pod only got it replaced; deleting the Deployment removes the application, down a chain of owners:

kubectl delete deployment web removes the Deployment's record. The ReplicaSet and its pods are still there, owned by an object that no longer exists.
The garbage collector, one more controller in kube-controller-manager, deletes the ReplicaSet, then the pods it owned: each object names its owner, so an owner's deletion reaches everything under it.
Each kubelet stops its pod's process, and the records go. kubectl get pods answers No resources found in default namespace., and the cluster is as it was before you ran anything.

Simplifications in the simulator

The control plane is spread over two nodes to show that its parts are separate programs. A real cluster runs a copy of each on every manage node, usually three of them, with one etcd member each.
Some system pods are left out: the network plug-in's agent on every node (Calico's calico-node, for example) and the cluster's DNS server, CoreDNS.
Your wire reaches the API server directly. A cluster in a cloud usually puts a load balancer in front of the manage nodes' port 6443, so kubectl keeps working when one of them is down.
Steps that happen within milliseconds of each other are drawn one at a time, and each controller's work is one step.

The symbols for the node, the components, the pod and the Deployment come from the Kubernetes Icons Set , licensed under Apache-2.0 or CC-BY-4.0. AWS, Google Cloud and Azure and their logos are trademarks of Amazon, Google and Microsoft, shown only to name the providers.

The course Kubernetes for DevOps works through the same objects on your own cluster.