Kubernetes Architecture
Kubernetes is so powerful because of its architecure. Before understanding how Kubernetes work, we first need to the understand its architecure - a carefully designed structure that can manage thousands of containers, deployments, and performs load balancing.
I feel that what people call the Kubernetes architecure is not exactly an architecture but a design with multiple components that work together as a single and unified system.
Let us understand how the Kubernetes is designed.
We are already aware, from the previous tutorial, that Kubernetes, unlike Docker, is a cluster.
As with any cluster, Kubernetes cluster also has multiple servers or hosts or compute nodes. Similar to a team in company which is lead by a team lead, when multiple servers need to work as a single unit, there should be someone or something that leads or controls or manages other servers.
The one server that manages the other servers in the Kubernetes cluster is called a master node and the remaining are called as worker nodes.
The master node is responsible for maintaining the desired state of the cluster, scheduling and running applications (in Pods), and managing the overall cluster operations. The worker nodes are responsible for running the Pods (application workloads) assigned by the master node.
For a Kubernetes worker node to function in coordination with master, there exists a control plane within the Master Node which makes all the decisions about the cluster and the running workloads.
The control plane manages the worker nodes and the Pods in the cluster.
Note: Every cluster needs at least one worker node in order to run Pods.
Info: In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
Architecture
In Kubernetes, it is not recommended to interact directly with the worker nodes. All our requests should go through the control plane in the master node via the Kubernetes API calls.
Master Node / Control Plane Components - Brain of Kubernetes
The control plane is the central management unit of a Kubernetes cluster. It keeps the cluster intact and looks after the cluster operations.
Its' components make all the decisions about the cluster like:
- scheduling the Pods
- detecting and responding to the cluster events
- maintaining the desired state. Example, bringing up a new Pod if a deployment's replicas are not satisifed
The control plane components include:
API Server (kube-apiserver) - Gateway to the Cluster
The API server is the front-end of the Kubernetes control plane. It exposes the Kubernetes API and serves as the entry point for all administrative tasks. It validates and processes API requests, and updates the corresponding objects in the database (etcd).
Every request to the cluster - whether from a user via UI or CLI (kubectl), or internal components - goes through the API server first. All other components depend on the API server.
Scheduler (kube-scheduler) - Task Distributor
The scheduler for the pod lifecycle management including creation, scaling, and deletion of pods.
When a pod is newly created, the Scheduler decides where it should run. It checks all the worker nodes and assigns Pods to the suitable nodes by considering the resource availability, constraints etc.
This makes sure that the workloads are evenly distributed across the cluster and none of the worker nodes gets overloaded.
Controller Manager (kube-controller-manager) - Cluster Orchestrator
The controller manager is responsible for running various controllers that manage the state of the cluster. It monitors the state of various objects in the cluster and takes corrective actions to ensure the desired state is maintained.
For example:
- If a node goes down, the controller manager detects it and reschedules the Pods that were running on that node to other healthy nodes.
- If a deployment's desired replicas are not met, the controller manager creates new Pods to meet the desired state.
- If a Pod is deleted, the controller manager creates a new Pod to replace it if it's part of a deployment.
The control manager does these activites with the help of controllers like Node Controller, Replication Controller, and Deployment Controller etc.
etcd - Cluster Memory
etcd is a highly available, reliable, distributed key-value database that stores all the cluster data.
It keeps a record of what is running, what should be running, and the configuration data of all the components or objects.
If something is not in etcd, it does not exist in Kubernetes.
Cloud Controller Manager (cloud-controller-manager)
The cloud controller manager is responsible for managing the interactions between the Kubernetes cluster and the underlying cloud infrastructure. It runs controllers that interact with the cloud provider's API to manage resources like load balancers, storage volumes, and network routes.
For example, if you are running your Kubernetes cluster on AWS, it needs AWS specific Cloud Controller Manager to create Elastic Load Balancers, EBS volumes, Auto Scaling Groups for auto-scaling etc.
Worker Node Components - Limbs of Kubernetes
The worker nodes are the machines where the actual application workloads (Pods) run. Each worker node has several components that work together to manage and run the Pods assigned by the control plane.
Kubelet - Node Agent
The kubelet is an agent that runs on each worker node. It ensures that the containers in the Pods are running and healthy. It communicates with the control plane to receive instructions about which pods to run and reports back the status of the Pods to the control plane.
It is also responsible to monitor and report the health of each node back to the API server.
Container Runtime - Container Engine
The container runtime is the software responsible for running containers on the worker node. Kubernetes supports multiple container runtimes, including Docker, containerd, and CRI-O. The kubelet interacts with the container runtime to start and stop containers as needed.
Kube Proxy - Network Proxy
The kube proxy is responsible for maintaining network rules on the worker nodes. It enables communication between Pods and services within the cluster. It also handles load balancing for services, ensuring that traffic is distributed evenly across the available Pods.
Conclusion
Understanding Kubernetes architecture is fundamental to effectively deploying and managing containerized applications at scale. The architecture elegantly separates concerns into a control plane (the brain) and worker nodes (the limbs).
The control plane, with its components like the API server, scheduler, and controller manager, orchestrates the entire cluster's operations and maintains the desired state.
Meanwhile, the worker nodes, powered by the kubelet, container runtime, and kube proxy, execute the actual workloads and handle networking.
This distributed yet coordinated design is what makes Kubernetes powerful—it abstracts away the complexity of managing individual containers and allows you to focus on deploying applications while the cluster intelligently manages resource allocation, fault tolerance, and load balancing.
With this foundation, you're now ready to explore how these components interact when you create and manage Kubernetes resources like Pods, Deployments, and Services.