Before the details, meet the crew behind the scenes. A
API server · the harbor master’s office
The only door into the cluster. Every command you type with kubectl arrives here, gets checked, and is written down.
etcd · the logbook
The single record of what you want: every Deployment, Service and setting. If it isn’t in the logbook, Kubernetes doesn’t know about it.
Scheduler · the helmsman
Picks a ship for every new Pod, based on room on board and any rules you set.
Controller manager · the clerks
Endlessly compare the logbook with reality and fix any difference, like replacing a missing Pod.
kubelet · the bosun aboard each ship
Lives on each ship, starts the Pods it was given, restarts a container that crashes, and keeps checking on them (more in chapter 6).
Container runtime · the deckhands
Actually pulls container images and runs them, for example containerd.
kube-proxy · the signalman
Sets up each ship’s networking so traffic for a Service reaches its Pods.
You run kubectl create deployment shop --image=shop:1.0 --replicas=3. kubectl sends it to the API server.
The API server checks you're allowed, then writes the Deployment into etcd. That's all your command does: it records a wish.
A controller notices the new Deployment and creates a ReplicaSet, which creates 3 Pod records. They have no ship yet.
The scheduler spots Pods without a ship and assigns each one to a Node.
Each Node's kubelet sees Pods assigned to it and has the runtime start the containers. Then it reports back: Running.