Overview #

Kubernetes is not a single monolithic application. Behind its remarkable capabilities, Kubernetes is actually a distributed system made up of a collection of independent microservice components, each with a very specific and limited responsibility.

This modular design was deliberately chosen to guarantee cluster resilience: every component can fail, be shut down, restarted, or upgraded independently without destabilizing the cluster as a whole. Understanding Kubernetes architecture means understanding each component’s specific role and how they coordinate with each other.

The Two Big Cluster Layers: Control Plane and Worker Nodes #

Architecturally, a Kubernetes cluster is divided into two large layers with different functions and components. Both layers communicate centrally through the API Server.

1. Control Plane (The Cluster’s Brain): Makes global decisions, tracks cluster state, schedules Pod placement, and keeps the cluster in its desired state. Control plane components include: kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.
2. Worker Nodes (The Cluster’s Muscle): Execute the actual application container workloads. Worker node components include: kubelet, kube-proxy, and the Container Runtime (such as containerd).

Component Interaction Map (Pipeline Workflow) #

To see how all these components work together harmoniously, let’s break down the complete workflow happening behind the scenes from the moment you run an application deployment command until the container is actually running on a server.

sequenceDiagram
    actor Developer
    participant Kubectl
    participant API as kube-apiserver
    participant DB as etcd
    participant Controller as kube-controller-manager
    participant Scheduler as kube-scheduler
    participant Kubelet as kubelet (Worker Node)
    participant CRI as Container Runtime (containerd)

    Developer->>Kubectl: kubectl apply -f deployment.yaml
    Kubectl->>API: HTTP POST Request (YAML/JSON payload)
    
    Note over API: 1. Authentication & Authorization (RBAC)<br/>2. Mutating & Validating Admission Webhooks
    
    API->>DB: Write Deployment object to etcd
    DB-->>API: Confirm data storage
    API-->>Kubectl: Response: Deployment Created/Updated
    
    Note over Controller: Deployment Controller detects the<br/>new Deployment via API Watch
    Controller->>API: Create new Pod objects (Replicas)
    API->>DB: Write Pod objects to etcd
    
    Note over Scheduler: Scheduler detects new Pods<br/>without a node assignment yet
    Scheduler->>API: Write Node Assignment to Pod (Binding)
    API->>DB: Update Pod status in etcd
    
    Note over Kubelet: The kubelet on the chosen worker node<br/>detects the new Pods via API Watch
    Kubelet->>CRI: Instruct the Container Runtime Interface (CRI)
    CRI->>CRI: Pull image from registry & run the container
    CRI-->>Kubelet: Container running
    Kubelet->>API: Update Pod status: Running
    API->>DB: Update Pod status in etcd

The most crucial point of the workflow above: no component ever communicates directly with another. The kubelet never talks directly to the Scheduler; the Controller Manager never touches the Container Runtime. All coordination, synchronization, and state storage must pass through kube-apiserver as the cluster’s single source of truth.

Four Architectural Design Principles of Kubernetes #

Kubernetes architecture rests on four core design principles that keep the system scalable, resilient, and production-reliable:

1. Watch, Not Poll (Watch-based Propagation) #

In traditional distributed systems, components typically poll the central server periodically: “Do you have any new tasks for me?”. This pattern is very inefficient because it eats bandwidth and puts heavy CPU load on the central server as the node count grows into the thousands.

Kubernetes throws away polling. Components like kubelet and kube-controller-manager open persistent HTTP/2 (gRPC) connections to kube-apiserver using the Watch API feature. When an object changes in etcd, the API Server immediately pushes the change event in real-time to the listening components. This makes state propagation fast and resource-efficient.

2. Level-driven, Not Edge-driven (State Reconciliation) #

Kubernetes control loops use a Level-driven approach. That means controller components don’t react to momentary change events (e.g. the event “Pod X died”), but periodically compare the cluster’s real condition against the condition declared by the user.

Main advantages of the Level-driven approach:

• If a network disruption causes the controller to miss several event notifications (edges), the system isn’t damaged.
• When the connection recovers, the controller re-reads the entire state and immediately reconciles any differences. The system becomes highly tolerant of partial component failures.

3. Optimistic Concurrency Control (OCC) #

When thousands of components run in parallel, there’s a chance two components try to modify the same object simultaneously in etcd. Instead of locking objects (pessimistic locking), which can trigger deadlocks and slow the system, Kubernetes uses a resource versioning mechanism (metadata.resourceVersion).

Every object in etcd has a unique version string. When a component wants to update an object, it must include the last version it read. If the etcd version has already changed (because another component updated it first), the request is rejected with a conflict error. The losing component just re-reads the latest version and retries the update request.

4. The API as the Single Contract #

In Kubernetes, the API Server is the only stable interface. Kubernetes’ built-in internal components (like the Scheduler) use the same gRPC/HTTP API as third-party tools (like kubectl or Terraform) and the custom controllers you write yourself. The advantage of this design is that the cluster ecosystem can be customized without limits without changing Kubernetes’ internal architecture.

Architectural Implications for Application Developers #

Understanding Kubernetes’ internal architecture helps explain many system behaviors that initially feel strange or unintuitive to application developers:

• Eventual Consistency: When you run kubectl apply, the Pod doesn’t instantly appear in Running status. That’s normal — the manifest has to pass through the API validation pipeline, replica calculation by the Controller, node selection by the Scheduler, image download by the Kubelet, and finally the runtime starting the container. Kubernetes clusters are eventually consistent, not instantly consistent.
• The Importance of the Audit Trail (Events): Because cluster components work asynchronously, the best way to diagnose failures is reading the event history each component writes to the API Server using kubectl get events or kubectl describe pod.

Summary #

• A Modular Distributed System — Kubernetes consists of independent components (API Server, etcd, Scheduler, Controller, Kubelet, Proxy), each with a limited responsibility.
• API-Centric Communication — All communication between cluster components must pass through the API Server. No direct ad-hoc communication between components.
• Pipeline Workflow — The deployment process flows asynchronously from Kubectl ➔ API Server ➔ etcd ➔ Controller Manager ➔ Scheduler ➔ Kubelet ➔ Container Runtime.
• Watch over Poll — Cluster components listen to change events in real-time through persistent HTTP/2 gRPC connections, saving cluster bandwidth.
• Level-driven Control Loops — Controllers periodically compare the cluster’s real condition against the desired state, making the system highly tolerant of temporary connection loss.

← Previous: Infrastructure Contract   Next: Control Plane →