Kubernetes – Architecture

Kubernetes comes with a client-server architecture. It consists of master and worker nodes, with the master being installed on a single Linux system and the nodes on many Linux workstations. The master node, contains the components such as API Server, controller manager, scheduler, and etcd database for stage storage. kubelet to communicate with the master, the kube-proxy for networking, and a container runtime such as Docker to manage containers.

Kubernetes Components

Kubernetes is composed of a number of components, each of which plays a specific role in the overall system. These components can be divided into two categories:

  • nodes: Each Kubernetes cluster requires at least one worker node, which is a collection of worker machines that make up the nodes where our container will be deployed.
  • Control plane: The worker nodes and any pods contained within them will be under the control plane. 
Kubernetes Architecture

Control Plane Components

It is basically a collection of various components that help us in managing the overall health of a cluster.  For example, if you want to set up new pods, destroy pods, scale pods, etc. Basically, 4 services run on Control Plane:

1. Kube-API server

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. It is like an initial gateway to the cluster that listens to updates or queries via CLI like Kubectl. Kubectl communicates with API Server to inform what needs to be done like creating pods or deleting pods etc. It also works as a gatekeeper. It generally validates requests received and then forwards them to other processes. No request can be directly passed to the cluster, it has to be passed through the API Server.

2. Kube-Scheduler

When API Server receives a request for Scheduling Pods then the request is passed on to the Scheduler. It intelligently decides on which node to schedule the pod for better efficiency of the cluster.

3. Kube-Controller-Manager

The kube-controller-manager is responsible for running the controllers that handle the various aspects of the cluster’s control loop. These controllers include the replication controller, which ensures that the desired number of replicas of a given application is running, and the node controller, which ensures that nodes are correctly marked as “ready” or “not ready” based on their current state.

4. Etcd

It is a key-value store of a Cluster. The Cluster State Changes get stored in the etcd. It acts as the Cluster brain because it tells the Scheduler and other processes about which resources are available and about cluster state changes.

Node Components

Worker nodes in Kubernetes are the machines that actually run application workloads. Each worker node contains several key components that help deploy, manage, and maintain Pods. These components work together to ensure containers run smoothly, stay healthy, and communicate effectively.

Container Runtime

The container runtime runs and manages containers inside Pods. Kubernetes relies on it to start, stop, and maintain containers according to the defined specifications. Popular container runtimes include Docker, containerd, and CRI-O. The runtime ensures that applications inside Pods launch quickly and run reliably.

kubelet

The kubelet is the primary agent on a worker node. It communicates with the Kubernetes control plane, monitors Pods, and ensures containers are running as expected. If a container fails, the kubelet restarts it immediately. It also reports the status of Pods and node resources back to the control plane so that Kubernetes can take corrective action if needed.

kube-proxy

The kube-proxy manages networking for the worker node. It routes traffic from Services to the correct Pods using efficient rules. kube-proxy ensures that applications remain reachable, balanced, and fault-tolerant, even when Pods are restarted or scaled up or down.

Node Status Monitor

The Node Status Monitor tracks the health, resource usage, and availability of the node. It continuously reports metrics such as CPU, memory, and disk usage to the control plane. Kubernetes uses this data to decide where to schedule new Pods or when to reschedule existing ones to maintain optimal performance.

Logging & Metrics Agent

Worker nodes often run agents that collect logs and performance metrics from Pods and containers. These agents send data to centralized monitoring tools like Prometheus, Grafana, or Fluentd, helping administrators debug issues, optimize performance, and maintain observability across the cluster.

Node Components

Addons Plug-in

Kubernetes add-ons are plug-ins that enhance the cluster’s functionality, often installed as Kubernetes resources like DaemonSets, Deployments, and more. These add-ons are typically deployed within the kube-system namespace, providing cluster-level capabilities and extending the native features of Kubernetes.

  1. CoreDNS: A flexible, extensible DNS server that provides name resolution services for Kubernetes clusters, ensuring efficient service discovery and network routing.
  2. KubeVirt: Allows the running of virtual machines alongside containers, providing a unified management platform for both VMs and containerized applications.
  3. ACI (Application Containerization Interface): Facilitates the integration and management of containers across different environments, improving the portability and scalability of applications.
  4. Calico: A network policy engine that provides secure, high-performance networking for Kubernetes clusters, supporting both network policy enforcement and advanced routing capabilities.

How components interact when a pod is scheduled on a node

  1. Scheduling the Pod: When you create a pod, the Kubernetes Control Plane selects a node for the pod to run on.
  2. Kubelet’s Role: Once the pod is assigned to a node, the Kubelet on that node is informed that a new pod has been assigned to it. The Kubelet reads the PodSpec, pulls the required container images, and starts the containers.
  3. Container Runtime: The container runtime on the node then runs the containers based on the specifications provided by the Kubelet.
  4. Kube-proxy and Networking: Meanwhile, Kube-proxy updates the node’s network rules to allow communication to and from the containers in the pod according to the Service definitions.

Commands for Kubectl

Here are some common commands for interacting with a Kubernetes cluster:

To view a list of all the pods in the cluster, you can use the following command:

kubectl get pods
List-of-pods

To view a list of all the nodes in the cluster, you can use the following command:

kubectl get nodes
Listing-nodes

Conclusion

Kubernetes architecture provides a robust and scalable framework to manage containerized applications efficiently. By separating the control plane and worker nodes, it ensures centralized management while distributing workloads across the cluster. The components on both master and worker nodes work together to handle scheduling, self-healing, networking, and monitoring, keeping applications reliable and resilient.

Understanding Kubernetes architecture helps developers and DevOps teams design, deploy, and maintain applications that can scale seamlessly, recover automatically from failures, and stay available even under heavy traffic. As a result, Kubernetes remains an essential tool for modern cloud-native application management.