Control Plane (Master) & Worker Nodes
Control Plane components:
- API Server
- Scheduler
- Control Manager
- etcd
Worker Node components:
- Container Runtime
- Kubelet
- Kube-proxy
Node Processes
- Each node has multiple Pods on it.
- 3 processes must be installed on every node — used to schedule and manage those Pods.
- Nodes are cluster services that actually do the work.
Container Runtime
Examples: Docker, containerd, CRI-O.
- containerd is used in worker nodes — it’s lightweight in nature.
- This should be installed on every node because application Pods need to run containers inside the node.
Kubelet
The process which schedules the Pods and containers underneath is Kubelet.
- Kubelet interacts with both the container and the node.
- Kubelet starts the Pod with the container inside.
- Communication between two nodes is because of Services.
- Creation of Pod: Kubelet insures the Pod is always running — if not, it will inform etcd.
Kube-proxy
- Kube-proxy forwards the request from Pod to Service.
- Makes use of the communication, with load balancing.
- Provides networking (container ID, IP address).
- Load balancing — basically using IP tables.
- It makes sure to send the request to the same machine instead of sending it to others (from same node communications).
So, how do you interact with this cluster?
- Schedule the Pod
- Monitor
- Re-schedule/restart the Pod
- Join a new node
Managing processes are done by master nodes (the control plane).
API Server
- When you, as a user, want to deploy a new application in a Kubernetes cluster, you interact with the API server using some client — could be UI or CLI.
- It’s a cluster gateway — it gets the initial request of any update into the cluster, even the queries from the cluster.
- It also acts as gatekeeper for authentication.
- It means when you want to schedule new Pods, deploy new applications, create new services, or any other components — you have to talk to it first.
Flow: Some request → API server → Validates request → Other processes → Pods
Only one entry point to the cluster.
Scheduler
- If you send an API request to schedule a new Pod, it validates the request and hands it over to the Scheduler to start the application Pod on one of the worker nodes.
- It’s not randomly allocating — Scheduler has an intelligent way of deciding on which specific worker node the Pod will be scheduled.
- First it will analyze how much CPU it needs, then which node has the least storage among them — there it will be scheduled.
- Scheduler just decides on which node the Pod has to be assigned, but starting the scheduling with containers is done by Kubelet.
Flow: Client → Schedule the Pod → API server → Scheduler → Where to put the Pod → Kubelet
Controller Manager
- When Pods die on any node, there must be a way to detect that the node died, then reschedule those Pods as soon as possible.
- What Controller Manager does is detect cluster state changes (crashing of Pod) and tries to recover the cluster state as soon as possible.
Flow: Controller manager → Scheduler → Kubelet → Pod recovery
etcd
Only cluster data storage — the cluster brain.
- It’s a key-value store of a cluster state.
- etcd is a cluster brain.
- Cluster changes (Pod dies, restarted) get stored.
- What resources are available?
- Did the cluster state change — cluster health.
- Actual application data is not stored here.
Example of Cluster Set-up
2 master nodes
3 worker nodes
Master: much more important, handful of master processes. Worker nodes: higher workload, more resources.
