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 we run a pod and a Deployment with kubectl from a workstation.
A working Kubernetes cluster: five computers, and a cluster admin running kubectl against them.
- A node is a computer.
- A pod is a group of one or more containers, running on one node.
- We look inside the nodes first, then run a pod, then a Deployment, then delete it.
Reading the drawing
- Solid purple is the control plane; teal is a node component.
- The kubelet is a port on each node's edge: the control plane reaches the node only through it.
- etcd's records are drawn as a disk under the etcd pod.
- A lit button marks the card whose turn it is; Step does the same.
Nodes and pods: computers and processes
- Two services run on every node, outside any pod:
- containerd, which runs the containers;
- the kubelet, the node's agent.
- A container is a process the kernel keeps apart.
ps on the node lists it. - A pod is its containers plus one address, which lasts as long as the pod.
The control plane: five programs running as pods
The control plane is programs, not a kind of computer: here it runs on two ordinary nodes.
- etcd: the database. Every object is one record.
- kube-apiserver: the hub.
- Every kubelet, the scheduler and the controllers talk to it.
- We reach it over HTTPS, on port 6443.
- Only it reads and writes etcd.
- kube-scheduler: picks a node for every new pod.
- kube-controller-manager: runs the controllers, loops that close the gap between what is asked
for and what exists.
- cloud-controller-manager: connects the cluster to its cloud, here AWS.
kube-proxy runs on every node. It is a node component, like the kubelet, not part of the control
plane.
manage-1 carries a taint that keeps our pods off it; manage-2 has none, so it takes our pods too.
A pod: from a YAML file to a running process
kubectl apply -f hello.yaml passes through four programs:
- kubectl sends the pod to kube-apiserver, which stores it with no node.
- The scheduler picks worker-2.
- The kubelet on worker-2 has containerd create the pod: its network, then the container.
- The kubelet reports the pod Running.
Deleting the pod stops the process for good: no controller owns a bare pod.
A Deployment: pods a controller keeps running
- The Deployment controller creates a ReplicaSet.
- The ReplicaSet controller creates the pods, and the scheduler spreads them over the nodes.
- When a pod goes, the ReplicaSet controller creates a replacement, with a new name and a new
address.
Deleting the Deployment: owners and the garbage collector
- Deleting the Deployment leaves its ReplicaSet and pods, owned by nothing.
- The garbage collector deletes them, down the chain of owners.
- Each kubelet stops its pod. The cluster is as it was before we ran anything.
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.