Kubernetes Ep 2: Architecture - Control Plane & Worker Nodes

TL;DR (Quick Summary)

#

• Control Plane Components: kube-apiserver (API gateway & auth), etcd (distributed key-value store), kube-scheduler (node selector), and kube-controller-manager (state reconciliation).
• Worker Node Components: kubelet (node agent supervising pods), kube-proxy (network rules & service routing), and Container Runtime (containerd/CRI-O executing OCI containers).
• Control Flow: kubectl talks only to kube-apiserver. No external component communicates directly with etcd or kubelet.

1. High-Level Architecture Overview

#

graph TB
    subgraph ControlPlane["Control Plane (Master Node)"]
        API["kube-apiserver"]
        ETCD["('etcd
(Key-Value DB)')"]
        SCHED["kube-scheduler"]
        CM["kube-controller-manager"]
        
        API <--> ETCD
        API <--> SCHED
        API <--> CM
    end

    subgraph WorkerNode1["Worker Node 1"]
        KUBELET1["kubelet"]
        KPROXY1["kube-proxy"]
        CR1["Container Runtime
(containerd)"]
        POD1["Pod A (App)"]
        
        KUBELET1 <--> CR1
        CR1 --> POD1
    end

    subgraph WorkerNode2["Worker Node 2"]
        KUBELET2["kubelet"]
        KPROXY2["kube-proxy"]
        CR2["Container Runtime
(containerd)"]
        POD2["Pod B (App)"]
        
        KUBELET2 <--> CR2
        CR2 --> POD2
    end

    API <-->|TLS Port 6443| KUBELET1
    API <-->|TLS Port 6443| KUBELET2
    KPROXY1 -.->|iptables / IPVS| POD1
    KPROXY2 -.->|iptables / IPVS| POD2

2. Control Plane Components (The Brain)

#

The Control Plane makes global cluster decisions (such as scheduling workloads), handles API requests, and maintains cluster state.

1. kube-apiserver

#

• The central frontend for the Control Plane.
• Exposes the Kubernetes REST API (default port 6443).
• Handles authentication, authorization (RBAC), admission control validation, and mutation.
• Key Rule: The API Server is the only component authorized to read from or write to etcd.

2. etcd

#

• A strongly consistent, distributed key-value database built on the Raft consensus algorithm.
• Stores the entire state of the cluster (all specs, status, secrets, and configurations).
• Production Tip: Always run etcd in multi-node HA topologies (minimum 3 or 5 nodes) and take regular automated snapshot backups (etcdctl snapshot save).

3. kube-scheduler

#

• Watches for newly created Pods that have no node assigned (nodeName: "").
• Evaluates worker nodes using a two-step process: Filtering (Predicates: sufficient CPU/RAM, taints/tolerations, affinity) and Scoring (Priorities: optimal node selection).
• Binds the Pod to the winning node by updating the Pod’s nodeName field via the API Server.

4. kube-controller-manager

#

• Runs a collection of distinct control loops bundled into a single binary.
• Examples include:
  • DeploymentController: Manages ReplicaSets and rolling updates.
  • NodeController: Monitors node health and handles node eviction after timeouts.
  • ServiceAccountController: Creates default ServiceAccounts for new namespaces.

3. Worker Node Components (The Muscle)

#

Worker Nodes host the Pods that constitute your application workloads.

1. kubelet

#

• An agent running on every worker node in the cluster.
• Registers the node with the API Server (kube-apiserver).
• Receives PodSpecifications (PodSpecs) from the API Server and ensures that the containers described in those PodSpecs are running and healthy.
• Interacts with the local Container Runtime via the Container Runtime Interface (CRI).

2. kube-proxy

#

• Maintains network rules on worker nodes to allow network communication to Pods from inside or outside the cluster.
• Implements the Kubernetes Service abstraction by translating virtual IP (VIP) addresses into backend Pod IPs using iptables, IPVS, or eBPF (Cilium).

3. Container Runtime

#

• The underlying engine responsible for pulling container images from registries and running containers.
• Implements the OCI (Open Container Initiative) standard. Popular runtimes include containerd and CRI-O (Docker shim was deprecated in K8s 1.24).

4. End-to-End Execution Flow: Deploying a Pod

#

Let’s trace what actually happens under the hood when a user executes kubectl apply -f nginx-pod.yaml:

sequenceDiagram
    autonumber
    actor User
    participant CLI as kubectl
    participant API as kube-apiserver
    participant DB as etcd
    participant SCHED as kube-scheduler
    participant KUB as kubelet
    participant CR as containerd

    User->>CLI: kubectl apply -f pod.yaml
    CLI->>API: POST /api/v1/namespaces/default/pods
    API->>API: Authenticate & Authorize (RBAC)
    API->>DB: Persist Pod Spec (Unscheduled)
    DB-->>API: ACK
    SCHED->>API: Watch detects pending Pod (nodeName="")
    SCHED->>SCHED: Filter & Score Nodes
    SCHED->>API: Bind Pod to Node 2 (nodeName="node-2")
    API->>DB: Persist Binding Update
    KUB->>API: Watch detects Pod bound to Node 2
    KUB->>CR: CRI call: RunPodSandbox & CreateContainer
    CR-->>KUB: Container Started
    KUB->>API: Update Status: Running

5. Summary & Next Steps

#

Understanding the Control Plane and Worker Node components gives you the mental model needed to debug cluster issues efficiently.

In Episode 03: kubectl CLI & Launching Your First Pod, we will install kubectl, configure cluster context, run imperative commands, and deploy our first declarative Pod manifest!