LFCA 79 🐧 Kubernetes Architecture — Nodes, Pods, Control Plane - KandZ

The previous chapter introduced Kubernetes and the declarative model. This chapter covers the architecture that makes the model work: the components that make decisions, the components that run workloads, and the resource that sits between them.

Kubernetes has two halves. The control plane makes global decisions about the cluster and responds to cluster events . The worker nodes run the actual workloads. Every cluster needs at least one worker node to run Pods, and production clusters run multiple nodes and multiple control plane instances for fault tolerance and high availability . The LFCA exam places containers and deployment environments under DevOps Fundamentals, which carries 16% of the total weight. Understanding the architecture is the foundation for every Kubernetes topic that follows.

Key point: The control plane does not run user workloads. It decides where they run. The worker nodes do not make scheduling decisions. They run what the control plane assigns to them. The kubelet is the bridge: it runs on every node, watches the API server for Pod assignments, and starts the containers that match .

Why the architecture matters

You can run a single container without knowing any of this. You cannot debug a Kubernetes cluster without it.

The scheduling problem. A Pod is created, but it has no node. The scheduler watches for Pods with no assigned node and picks one based on resource requirements, affinity rules, and policy constraints . If the scheduler is not running, the Pod stays in Pending forever. Knowing the scheduler exists tells you where to look when a Pod never starts.

The reconciliation problem. A Deployment says three replicas. Two are running. Who creates the third? The controller manager. It runs the controllers that watch the cluster’s state and act when it drifts from the desired state . The Node controller notices when a node goes down. The Job controller creates Pods for one-off tasks. Without the controller manager, nothing self-heals.

The state problem. Every object you create — Pods, Services, Deployments, ConfigMaps — is stored in etcd. It is the single source of truth for the cluster . If etcd is lost and not backed up, the cluster’s state is lost. The Kubernetes documentation is explicit: “make sure you have a backup plan for these data” .

The communication problem. Every component talks to the API server. The kubelet talks to it to report node status and receive Pod assignments. The scheduler talks to it to update Pod assignments. The controller manager talks to it to read and write state. The API server is the front end for the entire control plane .

The trade-off. The architecture adds components. A single machine with Docker has one process. A Kubernetes cluster has an API server, a datastore, a scheduler, a controller manager, and a kubelet and container runtime on every node. Each component is a point of failure. The complexity is the cost of the capabilities.

a. The Control Plane Components

The control plane makes global decisions about the cluster and detects and responds to cluster events . It runs five components.

kube-apiserver exposes the Kubernetes API. It is the front end for the control plane. Every component and every user talks to the API server. It is designed to scale horizontally: you can run multiple instances and balance traffic between them . The API server is the only component that writes to etcd. Everything else reads and writes through the API server.

etcd is a consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data . It stores the state of every object in the cluster. If etcd is not running, the cluster cannot function. If etcd is lost, the cluster’s state is lost. Backups of etcd are the most critical backup in a Kubernetes cluster .

kube-scheduler watches for newly created Pods with no assigned node and selects a node for them to run on . The scheduler’s decision is based on resource requirements, hardware and software constraints, affinity and anti-affinity specifications, data locality, and deadlines . The scheduler does not start the Pod. It only assigns it to a node. The kubelet on that node does the actual work.

kube-controller-manager runs controller processes . Each controller is logically a separate process, but they are compiled into a single binary and run as a single process to reduce complexity . The controllers include the Node controller (notices when nodes go down), the Job controller (creates Pods for one-off tasks), the EndpointSlice controller (links Services to Pods), and the ServiceAccount controller (creates default accounts for new namespaces) .

cloud-controller-manager embeds cloud-specific control logic . It links the cluster to the cloud provider’s API and separates the components that interact with the cloud platform from those that only interact with the cluster . It runs controllers for node deletion detection, route setup, and load balancer management . If you are running Kubernetes on your own premises, the cluster does not have a cloud controller manager .

b. The Worker Node Components

Worker nodes host the Pods that are the components of the application workload . Every node runs three components.

kubelet is the agent that runs on every node. It ensures that Pods are running, including their containers . The API server communicates with the kubelet to ensure that the node is correctly registered and that the Pods assigned to it are running. The kubelet reads Pod specifications, sets up the required storage volumes, and checks the health of the running containers.

Container runtime is the software responsible for running containers . It pulls container images from registries, runs containers, stops containers, and responds to container queries. The default container runtime is containerd. Docker’s dockershim integration was removed from Kubernetes in version 1.24, but Docker can still be used with Kubernetes by installing the Docker Engine on each node .

kube-proxy maintains network rules on nodes to implement Services . It tracks the IP addresses and ports associated with Pods and routes traffic to the correct destination. Some network plugins provide their own proxy implementations, and in those cases, the node does not need to run kube-proxy .

c. The Pod

The Pod is the smallest deployable unit in Kubernetes . It is a group of one or more containers that share storage, network, and the specification for how to run the containers . The containers in a Pod are always co-located and co-scheduled on the same physical or virtual machine .

The single-container Pod is the most common use case. You can think of the Pod as a wrapper around a single container. Kubernetes manages Pods rather than managing containers directly .

The multi-container Pod is used when containers are tightly coupled and need to share resources. The containers in a Pod share a network namespace, including the IP address and port space. They can communicate with each other using localhost . They share storage volumes, which allows them to share data and allows persistent data to survive a container restart .

Each Pod is assigned a unique IP address. Every container in the Pod shares that address. When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources, such as ports .

Pods are ephemeral. They are designed as relatively temporary, disposable entities . When a Pod is created, it is scheduled on a node and remains there until it finishes, is deleted, is evicted due to resource constraints, or the node fails . You rarely create Pods directly. You use workload resources like Deployments, StatefulSets, and DaemonSets to manage Pods .

Complete Example Session

This session demonstrates the architecture by examining a Pod’s journey from creation to running.

# ============================================
# PART 1: CREATE A POD VIA A DEPLOYMENT
# ============================================

kubectl create deployment web --image=nginx --replicas=3

# The deployment is stored in etcd.
# The controller manager creates a ReplicaSet.
# The ReplicaSet controller creates three Pods.

# ============================================
# PART 2: THE SCHEDULER ASSIGNS THE PODS
# ============================================

kubectl get pods -o wide

# Output:
# NAME                   READY   STATUS    NODE
# web-7d9f8b6c5-2x4kz    1/1     Running   node-1
# web-7d9f8b6c5-8m3np    1/1     Running   node-2
# web-7d9f8b6c5-q7r5t    1/1     Running   node-3

# The scheduler picked a node for each Pod.
# The kubelet on each node started the container.

# ============================================
# PART 3: THE KUBELET STARTS THE CONTAINER
# ============================================

kubectl describe pod web-7d9f8b6c5-2x4kz

# Output (excerpt):
# Node: node-1/10.0.0.5
# Container ID: containerd://abc123...
# Image: nginx:latest
# State: Running

# The kubelet pulled the image.
# The container runtime started the container.

# ============================================
# PART 4: THE API SERVER IS THE HUB
# ============================================

# Every component talks to the API server:
# - kubectl sends commands to the API server
# - The scheduler reads and writes Pod assignments
# - The controller manager reads and writes state
# - The kubelet on each node watches for Pod assignments

# ============================================
# PART 5: THE CONTROLLER MANAGER RECONCILES
# ============================================

# Delete a Pod
kubectl delete pod web-7d9f8b6c5-2x4kz

# The controller manager notices the actual state (2 Pods)
# does not match the desired state (3 Pods).
# It creates a replacement Pod.
# The scheduler assigns it to a node.
# The kubelet starts it.

kubectl get pods

# Three Pods are running again.

# ============================================
# PART 6: THE NODE CONTROLLER DETECTS FAILURE
# ============================================

# Simulate a node failure (conceptually)
# The Node controller notices the node is unreachable.
# The Pods on that node are marked as lost.
# The controller manager creates replacements on other nodes.

# ============================================
# PART 7: THE ETCD BACKUP
# ============================================

# etcd stores the entire cluster state.
# A backup is essential.
# The exact command depends on the etcd deployment.
# The Kubernetes documentation recommends a backup plan.

# ============================================
# PART 8: THE CLOUD CONTROLLER MANAGER
# ============================================

# On a cloud provider, the cloud-controller-manager:
# - Checks if a node has been deleted in the cloud
# - Sets up routes in the cloud infrastructure
# - Creates and manages cloud load balancers

# On a self-managed cluster, this component is absent.

# ============================================
# PART 9: THE KUBE-PROXY
# ============================================

# kube-proxy maintains network rules for Services.
# When you create a Service, kube-proxy on each node
# updates the network rules to route traffic to the
# correct Pods.

kubectl expose deployment web --port=80 --type=ClusterIP

# The Service is created.
# kube-proxy configures the routing.

# ============================================
# PART 10: THE ARCHITECTURE SUMMARY
# ============================================

# Control plane:
#   kube-apiserver: front end for the API
#   etcd: cluster state storage
#   kube-scheduler: assigns Pods to nodes
#   kube-controller-manager: reconciles state
#   cloud-controller-manager: cloud integration

# Worker nodes:
#   kubelet: runs Pods on the node
#   container runtime: runs containers
#   kube-proxy: network rules for Services

# Pods:
#   Smallest deployable unit
#   One or more containers
#   Shared network and storage

The ten parts cover creating a Pod via a Deployment, the scheduler assigning Pods, the kubelet starting the container, the API server as the hub, the controller manager reconciling, the Node controller detecting failure, the etcd backup, the cloud-controller-manager, kube-proxy, and the architecture summary.

Quick Reference

The Control Plane Components

Component	Purpose
kube-apiserver	Exposes the Kubernetes API; front end for the control plane
etcd	Consistent and highly-available key-value store for cluster data
kube-scheduler	Watches for new Pods and assigns them to nodes
kube-controller-manager	Runs controllers that reconcile desired state
cloud-controller-manager	Integrates with cloud provider APIs

The Node Components

Component	Purpose
kubelet	Ensures Pods are running on the node
Container runtime	Runs containers (containerd, CRI-O)
kube-proxy	Maintains network rules for Services

The Pod

Aspect	Description
Definition	Smallest deployable unit
Containers	One or more, co-located and co-scheduled
Network	Shared IP address and port space
Storage	Shared volumes
Communication	Containers use localhost
Lifecycle	Ephemeral; scheduled until finished, deleted, or evicted

The Controllers

Controller	Responsibility
Node controller	Notices and responds when nodes go down
Job controller	Creates Pods for one-off tasks
EndpointSlice controller	Links Services to Pods
ServiceAccount controller	Creates default accounts for new namespaces

Best Practices

✅ Do This:

# Use Deployments for stateless applications
kubectl create deployment web --image=nginx                       # ✅

# Check which node a Pod is running on
kubectl get pods -o wide                                          # ✅

# Back up etcd regularly
# The cluster state is stored there.                              # ✅

# Use multi-container Pods for tightly coupled containers
# For example, a web server and a sidecar.                        # ✅

❌ Don’t Do This:

# Don't create Pods directly for production workloads
kubectl run my-pod --image=nginx  # no self-healing               # ❌

# Don't run user workloads on control plane nodes in production
# Dedicate control plane nodes to the control plane.             # ❌

# Don't skip etcd backups
# Losing etcd means losing the cluster state.                    # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Pod stuck in Pending	Scheduler cannot find a suitable node	Check resource requests and node labels
Pod stuck in ContainerCreating	Image pull failure or volume issue	Check `kubectl describe pod`
Node NotReady	Kubelet not running or node unreachable	Check kubelet status on the node
Service not routing	kube-proxy not running or misconfigured	Check kube-proxy status
etcd backup missing	No backup plan	Configure etcd backups

Real-World Examples

1. API Server

kubectl cluster-info

2. Scheduler

kubectl describe pod my-pod | grep Node

3. Controller Manager

kubectl get deployments

4. Kubelet

# Runs on every node
systemctl status kubelet

5. Container Runtime

# containerd or CRI-O
crictl ps

6. kube-proxy

kubectl get services

7. Pod with Multiple Containers

# web server + sidecar

8. Pod IP Address

kubectl get pods -o wide

9. Node Status

kubectl get nodes

10. etcd Backup

# Command depends on the etcd deployment

Visual

The Kubernetes Architecture

┌──────────────────────────────────────────────┐
│  CONTROL PLANE                               │
│    kube-apiserver  ← front end               │
│    etcd            ← state store             │
│    kube-scheduler  ← assigns Pods            │
│    kube-controller-manager ← reconciles      │
│    cloud-controller-manager ← cloud APIs     │
│                                              │
│  WORKER NODES                                │
│    ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│    │ Node 1  │ │ Node 2  │ │ Node 3  │       │
│    │ kubelet │ │ kubelet │ │ kubelet │       │
│    │ runtime │ │ runtime │ │ runtime │       │
│    │ kube-   │ │ kube-   │ │ kube-   │       │
│    │ proxy   │ │ proxy   │ │ proxy   │       │
│    │ Pods    │ │ Pods    │ │ Pods    │       │
│    └─────────┘ └─────────┘ └─────────┘       │
│                                              │
│  Every component talks to the API server.    │
│  The kubelet runs Pods on each node.         │
│                                              │
└──────────────────────────────────────────────┘

The Pod

┌──────────────────────────────────────────────┐
│  POD                                         │
│    Shared IP address                         │
│    Shared network namespace                  │
│    Shared storage volumes                    │
│                                              │
│    ┌─────────────┐ ┌─────────────┐           │
│    │ Container 1 │ │ Container 2 │           │
│    │ (web server)│ │ (sidecar)   │           │
│    └─────────────┘ └─────────────┘           │
│                                              │
│  Containers communicate via localhost.       │
│  Pods are ephemeral.                         │
│                                              │
└──────────────────────────────────────────────┘

The Reconciliation Loop

┌──────────────────────────────────────────────┐
│  RECONCILIATION                              │
│                                              │
│  Desired state: 3 replicas                   │
│  Actual state: 2 replicas                    │
│       │                                      │
│       ▼                                      │
│  Controller manager notices mismatch         │
│       │                                      │
│       ▼                                      │
│  Creates a new Pod                           │
│       │                                      │
│       ▼                                      │
│  Scheduler assigns it to a node              │
│       │                                      │
│       ▼                                      │
│  Kubelet starts the container                │
│       │                                      │
│       ▼                                      │
│  Desired state: 3 replicas                   │
│  Actual state: 3 replicas                    │
│                                              │
└──────────────────────────────────────────────┘

The Communication Flow

┌──────────────────────────────────────────────┐
│  EVERYTHING TALKS TO THE API SERVER          │
│                                              │
│  kubectl ──> API server                      │
│  Scheduler ──> API server                    │
│  Controller manager ──> API server           │
│  Kubelet ──> API server                      │
│  kube-proxy ──> API server                   │
│                                              │
│  Only the API server writes to etcd.         │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
Cluster composition	Control plane + worker nodes
Control plane components	kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager
Node components	kubelet, container runtime, kube-proxy
API server	Front end; only writer to etcd
etcd	Key-value store for all cluster data
Scheduler	Assigns Pods to nodes
Controller manager	Reconciles desired state with actual state
Kubelet	Ensures Pods are running on the node
Pod	Smallest deployable unit
Pod sharing	Network namespace, IP address, storage volumes
LFCA weight	DevOps Fundamentals, 16%

Key takeaways:

A Kubernetes cluster consists of a control plane and worker nodes. The control plane makes global decisions about the cluster. The worker nodes run the application workloads. Every cluster needs at least one worker node .
The API server is the front end for the control plane. Every component and every user talks to the API server. It is the only component that writes to etcd .
etcd stores the entire cluster state. If etcd is lost and not backed up, the cluster’s state is lost. The Kubernetes documentation recommends a backup plan for etcd data .
The scheduler assigns Pods to nodes. It watches for newly created Pods with no assigned node and selects a node based on resource requirements, affinity rules, and policy constraints .
The controller manager runs the reconciliation loop. It notices when the actual state differs from the desired state and acts to fix the difference. The Node controller notices when nodes go down. The Job controller creates Pods for one-off tasks .
The kubelet runs on every node and ensures Pods are running. It communicates with the API server, reads Pod specifications, and starts the containers .
The Pod is the smallest deployable unit. It is a group of one or more containers that share network and storage. Pods are ephemeral. They are scheduled, run, and replaced .

Remember: The Kubernetes architecture is a set of components that work together to maintain the desired state of the cluster. The control plane decides. The worker nodes run. The API server is the hub. etcd is the memory. The scheduler places. The controller manager reconciles. The kubelet executes. The Pod is the unit of work. Understanding the architecture is understanding who does what and why a Pod that never starts is a scheduler problem, not a container problem.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!