Kubernetes Architecture

What is Kubernetes Architecture?

Kubernetes Architecture defines how different components of Kubernetes work together to manage, deploy, and scale containerized applications.

It is designed in a way that separates control logic from execution, making the system scalable and efficient.

👉 In simple words: Kubernetes architecture is the structure that controls how containers run across multiple machines.

Kubernetes Cluster Overview

A Kubernetes cluster is the core environment where applications run. It consists of two main parts:

• Control Plane (Master Node) → Manages the cluster and makes decisions
• Worker Nodes → Execute those decisions by running applications

👉 The control plane acts as the brain, while worker nodes act as the execution layer.

Example

Let’s say you want to run a web app with 2 instances:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx-container
        image: nginx

kubectl apply -f deployment.yaml

Kubernetes automatically:

• Decides where to run pods
• Creates 2 containers
• Keeps them running

Master Node (Control Plane)

The Control Plane is responsible for managing the entire cluster and ensuring everything works as expected.

API Server (Entry Point)

The API Server is the central entry point for all Kubernetes operations. Every request—whether from kubectl, a web UI, or external APIs—is first received and processed by the API Server.

It performs the following tasks:

• Receives requests from users and tools
• Validates and authenticates the requests
• Stores the desired state in the cluster database (etcd)
• Forwards instructions to other components like the Scheduler and Controller Manager

Example

When you run the following command:

kubectl apply -f deployment.yaml

The process works like this:

1. The request is sent to the API Server
2. The API Server validates the request
3. The configuration is stored in etcd
4. Other components act on this information to deploy the application

Scheduler (Pod Placement)

The Scheduler is responsible for deciding which worker node will run a pod. It ensures that workloads are distributed efficiently across the cluster.

It evaluates multiple factors before placing a pod:

• Available CPU and memory
• Node health and status
• Current resource usage
• Scheduling policies and constraints

Example

When you deploy an application:

kubectl apply -f deployment.yaml

The process works like this:

1. The API Server receives the request
2. The Scheduler checks all available worker nodes
3. It selects the most suitable node based on resources
4. The pod is assigned to that node

Controller Manager (Cluster State Management)

The Controller Manager is responsible for ensuring that the cluster always matches the desired state defined by the user.

It continuously monitors the system and makes adjustments whenever there is a difference between the desired state and the actual state.

It performs tasks like:

• Maintaining the required number of pods
• Replacing failed or crashed containers
• Managing replication and system health

Example

Suppose you define a deployment with 2 replicas:

spec:
  replicas: 2

What happens:

1. Kubernetes creates 2 pods
2. One pod crashes or stops unexpectedly
3. Controller Manager detects the issue
4. It automatically creates a new pod

etcd (Key-Value Store)

etcd is the core database of Kubernetes that stores all the cluster data in a key-value format.

It acts as the single source of truth, meaning Kubernetes relies on it to know what is happening inside the cluster.

It stores:

• Cluster state
• Configuration data
• Pod and node details

Example

When you create a deployment:

kubectl apply -f deployment.yaml

What happens:

1. The API Server receives the request
2. The configuration is stored in etcd
3. All components read data from etcd
4. Kubernetes ensures the system matches this stored state

Worker Node Components

Worker nodes are responsible for running your actual applications inside containers. Each node includes key components that ensure applications run smoothly and communicate properly.

Kubelet

Kubelet is an agent that runs on every worker node and ensures containers are running as expected.

It:

• Receives instructions from the control plane
• Starts and manages containers
• Monitors pod health and status

Example

When a pod is assigned to a worker node:

kubectl apply -f deployment.yaml

What happens:

1. The Scheduler assigns the pod to a node
2. Kubelet receives instructions from the API Server
3. It pulls the required image
4. Starts the container and keeps it running

👉 If the container crashes, Kubelet reports it and helps restart it.

Kube Proxy

Kube Proxy is responsible for managing network communication inside the cluster.

It:

• Routes traffic between pods
• Enables communication through services
• Handles internal load balancing

Example

👉 If multiple pods are running your app:

• A request comes to a Service
• Kube Proxy distributes the request across pods
• Ensures smooth and balanced traffic flow

Container Runtime (Docker / containerd)

The container runtime is responsible for actually running containers on the node.

It:

• Pulls images from a container registry
• Starts and stops containers
• Manages container lifecycle

Example

👉 When a pod is created:

• Kubelet asks the container runtime to run the container
• The runtime pulls the image (e.g., nginx)
• Starts the container inside the pod

How Kubernetes Works

Here’s the real working flow:

1. User runs the command:

kubectl apply -f deployment.yaml

1. The request is sent to the API Server
2. The API Server validates the request and stores it in etcd
3. The Scheduler selects the most suitable worker node
4. The Kubelet on that node pulls the image and starts the container
5. Kube Proxy manages networking and routes traffic to the pod

Difference Between Control Plane vs Worker Node

Internal Communication Between Components

Kubernetes components communicate with each other using APIs and internal networking, ensuring smooth coordination across the cluster.

• API Server acts as the central communication hub
• All components interact through the API Server
• Kubelet communicates with the Control Plane to receive instructions
• Kube Proxy manages networking and communication between pods

👉 This centralized communication model keeps the system consistent, reliable, and easy to manage.

Practical Flow Example

Suppose a pod crashes:

1. Kubelet detects that the container has failed
2. It reports the issue to the API Server
3. The Controller Manager checks the desired state
4. It creates a new pod to replace the failed one
5. The Scheduler assigns the new pod to a suitable node
6. The Kubelet starts the new container on that node

👉 This entire process happens automatically without any manual intervention.

Conclusion

Kubernetes architecture is designed to efficiently manage containerized applications by clearly separating control (decision-making) from execution (running applications). This design makes the system highly scalable, reliable, and easy to manage in real-world environments.

The Control Plane handles all the decisions and maintains the desired state, while Worker Nodes execute those decisions by running applications smoothly. All components work together in an automated way to ensure high availability and performance.