Kubernetes
Kubernetes is an orchestration system for containers. It doesn’t replace Docker; it manages many Docker containers (or other container runtimes) across multiple machines.
Problems using Docker
Single Host - Imagine 100 containers running, 1 container uses more memory, it affects other container maybe 50th 99th or any because this container does not get enough resources, it may also kill that container based on the priority.
Docker does not provide auto-healing - If container is killed app becomes inaccessible and container has to be started manually
It does not have auto scaling.
Docker does not provide Enterprise support
These issues can be fixed by Kubernetes
Kubernetes Architecture
There are 2 parts
1) Control Plane - API Server, Scheduler, etcd, Control manager, Cloud control manager
2) Data Plane - Kubelet, Kube-proxy, Container Runtime
We'll start with Data plane
1) Container runtime - It is necessary to run containers like java runtime is required to run java applications
Container runtimes for Kubernetes include containerd and CRI-O (Dockershim was deprecated).
2) Kube-proxy - It handles the networking between the containers and services, like sending or distributing requests to pods/nodes i.e., load balancing, it also does assignment of IP addresses
3) Kubelet - It ensures Pods assigned to its node are running and healthy. It communicates with the control plane and uses the container runtime to start containers inside Pods.
Control plane
1) API Server - It is the core component of Kubernetes; it is the front door. All commands go through here. It stores objects (like Pods) and exposes them to other components.
2) Scheduler- It decides which node runs which pod. It watches for Pods that don’t have a node yet (unscheduled pods) evaluates all candidate nodes, and picks the best node based on policies and resource availability.
3) etcd - A key-value store for cluster state (like a database for configs). Entire cluster information is stored in it.
4) Controller manager - Ensures desired state (e.g., if you said 3 replicas, it keeps 3 running).
The flow step-by-step
1) You (or a controller like a Deployment) create a Pod → it’s sent to the API Server.
2) The API Server stores the Pod (in etcd) and marks it as unscheduled (no nodeName).
3) The Scheduler notices the unscheduled Pod, filters nodes that can’t run it, scores the remaining nodes, and binds the Pod to the chosen node via the API Server.
4) The Kubelet on that node sees the bound Pod and starts the containers (via the container runtime).
Top comments (0)