Analogy between ships and Kubernetes Cluster.
Kubernetes Cluster = Cargo Ships (Orange=Worker Node) and Control Ships (Red=Master Node)
A worker node hosts applications (Containers)
Many containers (same or different) can be on the same worker node (Cargo Ship).
Master Node
Keeping track/deploying of all these containers is done on the Master Nodes by Control Plane Components
Tracking (Ships Manifest) is done by the etcd cluster.
Deployment happens by the kube-scheduler checking all constraints. (The crane on the Red Control ship)
Monitoring of Worker Nodes happens with controller-manager. (Maintenance Crew on Control Ship)
controller manager = node controller (node monitoring)+ replication controller (number of same containers)
Letting these processes work together happens through the kube-apiserver. (The bridge of the Control Ship)
The API-server exposes all these processes to outside users for management purposes even the worker node processes.
Worker Node
Container Runtime Interface (CRI)= Software able to understand the containers and run them. For example : Containerd or Rkt. Each node (Worker and Master) have this. (Nerdctl to control containerd [same style as docker] ; crictl is normally for debugging, should not be used. Also Rkt is kinda dead.)
kubelet = Agent running on nodes. Deploying or destroying containers @ request. kube-api requests regularly status update on nodes.
kube-proxy = Allows communication between some containers on different worker nodes.
