Solutions
Audit & Optimization Platform Design Automation Team Structure
Documentation Blog
Get Started

Kubernetes Architecture

Understanding Kubernetes architecture is essential for effectively using, troubleshooting, and operating Kubernetes clusters. The architecture determines how Kubernetes makes decisions, stores state, schedules workloads, and maintains desired configurations.

Kubernetes follows a distributed systems architecture with clear separation between the control plane (decision-making) and data plane (execution). Think of it like a company: the control plane is management making decisions and coordinating work, while the data plane (worker nodes) is the workforce executing those decisions.

Architecture Overview

Kubernetes clusters consist of two main parts:

graph TB subgraph "Control Plane" API[API Server] Scheduler[Scheduler] CM[Controller Manager] etcd[etcd<br/>State Store] end subgraph "Worker Nodes" Node1[Node 1] Node2[Node 2] Node3[Node 3] end subgraph Node1 Kubelet1[Kubelet] KubeProxy1[kube-proxy] Runtime1[Container Runtime] Pods1[Pods] end subgraph Node2 Kubelet2[Kubelet] KubeProxy2[kube-proxy] Runtime2[Container Runtime] Pods2[Pods] end subgraph Node3 Kubelet3[Kubelet] KubeProxy3[kube-proxy] Runtime3[Container Runtime] Pods3[Pods] end API --> etcd API --> Scheduler API --> CM API --> Kubelet1 API --> Kubelet2 API --> Kubelet3 Scheduler --> API CM --> API Kubelet1 --> Runtime1 Kubelet2 --> Runtime2 Kubelet3 --> Runtime3 style API fill:#e1f5ff style etcd fill:#fff4e1 style Scheduler fill:#fff4e1 style CM fill:#fff4e1

Control Plane - Makes global decisions about the cluster (scheduling, responding to events) and maintains the desired state of the cluster.

Worker Nodes - Run the containerized applications. Each node can run multiple pods.

Control Plane vs Data Plane

Control Plane (Master Components)

The control plane is the “brain” of Kubernetes. It’s responsible for:

  • Making decisions - Where to schedule pods, how to respond to failures
  • Maintaining state - Storing cluster configuration and current state
  • Exposing API - Providing the interface for all cluster interactions
  • Watching and reconciling - Ensuring actual state matches desired state

Control plane components can run on dedicated machines or be co-located on the same machines. For production, they’re typically distributed across multiple machines for high availability.

Data Plane (Worker Nodes)

The data plane is where your applications actually run. It consists of:

  • Worker nodes - Machines that run containerized applications
  • Kubelet - Agent that communicates with the control plane
  • Container runtime - Software that runs containers (containerd, CRI-O)
  • kube-proxy - Network proxy that maintains network rules

The data plane executes the decisions made by the control plane.

Control Plane Components

The control plane consists of several components that work together:

API Server

The API server is the front end of the Kubernetes control plane. It’s the only component that directly communicates with etcd and exposes the Kubernetes API. All other components and users interact with Kubernetes through the API server.

Responsibilities:

  • Validates and processes API requests
  • Authenticates and authorizes requests
  • Reads from and writes to etcd
  • Serves the Kubernetes API

etcd

etcd is a distributed, consistent key-value store used as Kubernetes’ backing store for all cluster data. It’s the “memory” of Kubernetes—everything the cluster knows is stored here.

Responsibilities:

  • Stores cluster state (pods, services, deployments, etc.)
  • Provides watch functionality for change notifications
  • Ensures consistency across the cluster

Scheduler

The scheduler watches for newly created pods with no assigned node and selects a node for them to run on.

Responsibilities:

  • Watches for unscheduled pods
  • Evaluates node resources, constraints, and policies
  • Assigns pods to nodes
  • Considers resource requests, affinity rules, taints, and tolerations

Controller Manager

The controller manager runs controllers that watch the cluster state and make changes to move the current state toward the desired state.

Responsibilities:

  • Runs controllers (Deployment, ReplicaSet, Service, etc.)
  • Watches for changes in cluster state
  • Takes corrective action to achieve desired state
  • Handles node failures, pod failures, and other events

Cloud Controller Manager (Optional)

In cloud environments, the cloud controller manager integrates Kubernetes with cloud provider APIs for load balancers, storage, and networking.

Worker Node Components

Each worker node runs several components:

Kubelet

The kubelet is an agent that runs on each node and ensures containers are running in pods.

Responsibilities:

  • Registers the node with the API server
  • Watches for pod assignments
  • Starts and stops containers via the container runtime
  • Reports node and pod status to the API server
  • Runs liveness and readiness probes

Container Runtime

The container runtime is the software responsible for running containers. Kubernetes supports any runtime that implements the Container Runtime Interface (CRI), such as containerd or CRI-O.

Responsibilities:

  • Pulling container images
  • Starting and stopping containers
  • Managing container lifecycle
  • Providing container isolation

kube-proxy

kube-proxy is a network proxy that runs on each node and maintains network rules that allow communication to pods.

Responsibilities:

  • Implementing Service abstraction
  • Load balancing traffic to pods
  • Maintaining iptables or IPVS rules
  • Handling service discovery

Component Communication

Components communicate through well-defined patterns:

sequenceDiagram participant User participant API as API Server participant etcd participant Scheduler participant CM as Controller Manager participant Kubelet participant Runtime as Container Runtime User->>API: Create Pod API->>etcd: Store Pod Spec API-->>Scheduler: Watch for unscheduled pods Scheduler->>API: Bind Pod to Node API->>etcd: Update Pod Status API-->>Kubelet: Watch for pod assignments Kubelet->>Runtime: Create Container Runtime-->>Kubelet: Container Running Kubelet->>API: Update Pod Status API->>etcd: Store Pod Status

API Server as Central Hub

The API server is the central communication hub. All components communicate through it:

  • Components watch the API server for changes
  • Components update the API server with status
  • The API server validates and stores everything in etcd

Watch Pattern

Kubernetes uses a watch pattern for efficient change notification:

  • Components watch for changes to resources
  • The API server streams changes as they occur
  • Components react to changes immediately

This is more efficient than polling and ensures components stay in sync.

How Components Work Together

Pod Creation Flow

  1. User creates pod - Sends request to API server
  2. API server validates - Checks request and stores in etcd
  3. Scheduler watches - Detects unscheduled pod
  4. Scheduler assigns - Selects node and updates pod
  5. Kubelet watches - Detects pod assignment to its node
  6. Kubelet creates - Instructs container runtime to create container
  7. Status updates - Kubelet reports status back to API server

Self-Healing Flow

  1. Pod fails - Container crashes or node fails
  2. Kubelet detects - Reports status to API server
  3. Controller watches - Deployment controller detects mismatch
  4. Controller reconciles - Creates new pod to replace failed one
  5. Scheduler assigns - New pod scheduled to available node
  6. Kubelet creates - New container starts

High Availability Architecture

For production clusters, the control plane should be highly available:

graph TB subgraph "Load Balancer" LB[Load Balancer] end subgraph "Control Plane Nodes" CP1[Control Plane 1<br/>API Server<br/>Scheduler<br/>Controller Manager] CP2[Control Plane 2<br/>API Server<br/>Scheduler<br/>Controller Manager] CP3[Control Plane 3<br/>API Server<br/>Scheduler<br/>Controller Manager] end subgraph "etcd Cluster" etcd1[etcd 1] etcd2[etcd 2] etcd3[etcd 3] end LB --> CP1 LB --> CP2 LB --> CP3 CP1 --> etcd1 CP2 --> etcd2 CP3 --> etcd3 etcd1 <--> etcd2 etcd2 <--> etcd3 etcd3 <--> etcd1 style LB fill:#e1f5ff style CP1 fill:#fff4e1 style CP2 fill:#fff4e1 style CP3 fill:#fff4e1 style etcd1 fill:#e8f5e9 style etcd2 fill:#e8f5e9 style etcd3 fill:#e8f5e9
  • Multiple API servers - Behind a load balancer for redundancy
  • etcd cluster - Typically 3 or 5 nodes for quorum
  • Multiple schedulers - Leader election ensures only one active scheduler
  • Multiple controller managers - Leader election ensures only one active controller manager

Topics

Key Takeaways

  • Kubernetes has a clear separation between control plane (decisions) and data plane (execution)
  • The API server is the central hub for all communication
  • etcd stores all cluster state
  • The scheduler assigns pods to nodes
  • Controllers maintain desired state
  • Worker nodes run your applications via kubelet and container runtime
  • Components use watch patterns for efficient change notification
  • High availability requires multiple control plane nodes and etcd cluster

See Also