Skip to main content

Command Palette

Search for a command to run...

Kubernetes Architecture Explained: Control Plane, Worker Nodes, and Pod Lifecycle

Updated
4 min read

Introduction

Kubernetes simplifies the management of containerized applications, but its real strength lies in the architecture that powers scheduling, self-healing, and scalability. Rather than being a single monolithic system, Kubernetes is composed of multiple components that work together to manage cluster state and application workloads.

This article breaks down Kubernetes architecture in a clear and structured way, focusing on the roles of the control plane and worker nodes.

If you’re a beginner, this article will help you visualize how Kubernetes works 🧠
If you already know K8s, it will serve as a quick architecture refresh 🔁


What is Kubernetes (Quick Recap)

Kubernetes is an open-source container orchestration platform that helps you:

  • Deploy containerized applications

  • Scale them automatically

  • Keep them running even when things fail

At a high level, Kubernetes follows a master–worker (control plane–data plane) architecture.


What is a Pod?

Before diving into architecture, let’s clarify the smallest unit in Kubernetes.

Pod
A Kubernetes Pod is a collection of one or more containers that:

  • Share the same network (IP + ports)

  • Share storage volumes

  • Are scheduled together on the same node

👉 In simple terms: Kubernetes never runs containers directly — it runs Pods.


Kubernetes Architecture

Kubernetes follows a control plane – data plane architecture.

  • Control Plane: Responsible for cluster state, scheduling, and decision-making

  • Worker Nodes (Data Plane): Responsible for running application workloads

Cluster Architecture | Kubernetes


Control Plane (Master Node)

The control plane is responsible for decision-making and cluster state management.
It does not run application workloads.

1️⃣ API Server

The core component of Kubernetes.

  • Accepts all incoming requests (kubectl, UI, CI/CD tools)

  • Acts as the entry point to the cluster

  • Validates requests and updates the cluster state

👉 Think of it as the front door of Kubernetes 🚪


2️⃣ Scheduler

The Scheduler decides where a Pod should run.

  • Watches for newly created Pods without a node assigned

  • Evaluates available worker nodes

  • Considers:

    • CPU and memory availability

    • Pod requirements

    • Scheduling constraints

  • Assigns the Pod to the most suitable node

⚠️ The scheduler does not start Pods — it only selects the node.


3️⃣ etcd

etcd is a distributed key-value store used to persist cluster state.

It stores:

  • Pod specifications

  • Node details

  • ConfigMaps and Secrets

  • Cluster metadata

etcd is the single source of truth for the cluster.
👉 If etcd goes down, the cluster loses its memory


4️⃣ Controller Manager

The Controller Manager runs multiple controllers that ensure the cluster behaves as expected.

Examples include:

  • ReplicaSet controller

  • Deployment controller

  • Node controller

Controllers continuously:

  • 👀 Observe the current state

  • 🎯 Compare it with the desired state

  • 🔧 Take corrective action when needed

This is what enables self-healing in Kubernetes ♻️


5️⃣ Cloud Controller Manager

The Cloud Controller Manager integrates Kubernetes with cloud-provider-specific services.

It manages:

  • Load balancers

  • Cloud storage volumes

  • Node lifecycle in cloud environments

This separation allows Kubernetes core logic to remain cloud-agnostic.


Worker Nodes (Data Plane)

Worker nodes are where your applications actually run. Each worker node contains components required to execute Pods.


1️⃣ Kubelet

The kubelet is an agent that runs on every worker node.

Its responsibilities are very specific:

  • Watches the API Server for Pod assignments

  • Ensures assigned Pods are running on the node

  • Communicates with the container runtime to start containers

  • Reports node and Pod health back to the API Server

📝 Kubelet does not schedule Pods and does not store cluster state.
It strictly ensures that Pods run exactly as declared.


2️⃣ Container Runtime

The container runtime is responsible for running containers inside Pods.

Common runtimes include:

  • containerd

  • CRI-O

It handles:

  • Pulling container images

  • Creating and running containers

  • Managing the container lifecycle

Kubernetes interacts with the runtime through the Container Runtime Interface (CRI).


3️⃣ Kube-Proxy

kube-proxy manages networking on the worker node.

It provides:

  • Pod-to-Pod communication

  • Service-level networking

  • Basic load balancing using iptables or IPVS

kube-proxy ensures that traffic sent to a Service reaches the correct Pod.


Why Kubernetes Architecture Matters

Understanding this architecture helps you:

  • Debug cluster issues faster

  • Design better deployments

  • Prepare for interviews

  • Move from Docker → Kubernetes confidently

Once this picture is clear, concepts like Deployments, Services, Autoscaling, and Networking become much easier.


🧩 Final Thoughts

Kubernetes may look complex at first, but its architecture follows a clear separation of concerns:

  • Control Plane = decision making

  • Data Plane = execution

If you’re coming from a Docker background, Kubernetes is simply Docker plus orchestration, automation, and intelligence.

More from this blog

codeops-labs.hashnode.dev

16 posts