| Your local machine | Kubernetes Master Node / Control Plane | Kubernets Nodes / Workers |
|--------------------|----------------------------------------|---------------------------|
| You CLI | api-server | kublet |
| | etcd database | |
| | scheduler | |
| | controller-manager | |
- #localmachine CLI sends to the api-server a command like "k create deployment web --image nginx —replicas=3"
- #controlplain api-server asks to etcd db to save a new deployment object
- #controlplain api-server returns to CLI a “created” message. It means the specs about the deployment have been successfully stored in the etcd db rather than be actually created in the actual nodes.
- #controlplain controller-manager (through api-server) pulls info from etcd db and asks to etcd db to save the resource specified by the saved deployment object which is a replica-set.
- #controlplain controller-manager (through api-server) pulls info from etcd db and asks to etcd db to save the resource specified by the saved replica-set object which are some pods. The pods are saved in the etcd db with PENDING status
- #controlplain scheduler (through api-server) pulls info from etcd db finding some pods in PENDING status, so it runs some algos in order to understand where (node1, node2…) is better to create those pods and saves the info in the etcd db.
- #workers kublet (through api-server) checks if any new pods have been assigned to its node. It finds them and (through container runtime - docker) creates them. As soon as they are running kublet (through api-server) will update the pods status to RUNNING in the etcd db.