Kubernetes Architecture Explained for CKA- Part 1

Control Plane, Worker Nodes, and the Truth About Controllers

Kubernetes often feels complex not because it is chaotic, but because its responsibilities are sharply divided. Once you understand who decides, who acts, and who stores state, Kubernetes stops being “magic” and becomes a predictable system.

This article explains Kubernetes as it really works, not as oversimplified diagrams suggest.

We will cover:

• Control Plane vs Worker Nodes
• The real role of each core component
• The exact lifecycle of a Pod
• Where the Controller Manager fits (and where it does not)
• Common misconceptions that confuse even experienced engineers

1. Control Plane vs Worker Nodes (The Big Picture)

At the highest level, Kubernetes is split into two logical parts:

Control Plane

Responsible for decision-making and state management.

The Control Plane decides what should happen.

Worker Nodes

Responsible for executing workloads.

Worker Nodes execute what was decided.

This separation is fundamental and never violated in Kubernetes’ architecture.

2. Control Plane Components (Responsibilities, Not Buzzwords)

2.1 API Server — The Heart of Kubernetes

The kube-apiserver is the front door and the central hub.

Entry point for:

• kubectl
• Controllers
• Scheduler
• kubelets

Handles:

• Authentication
• Authorization
• Validation

The only component that communicates with etcd

A critical rule:

No Kubernetes component talks directly to another component. Everything goes through the API server.

📚 Official reference: https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/

2.2 etcd — The Source of Truth

etcd is a distributed key-value store.

Stores:

• Desired state
• Current state metadata

Highly consistent

Does not act, schedule, or monitor

etcd stores state — it never enforces it.

📚 Official reference: https://kubernetes.io/docs/concepts/overview/components/#etcd

2.3 Scheduler — Node Selection Only

The kube-scheduler is responsible for placement, nothing more.

Watches the API server for Pods with no assigned node

Selects the best node based on:

• Resource availability
• Constraints
• Policies

Writes the decision back via the API server

Important clarification:

The scheduler decides where, not how or when containers run.

📚 Official reference: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

2.4 Controller Manager — The Most Misunderstood Component

The kube-controller-manager runs multiple controllers that implement reconciliation loops.

What it does

Watches the API server

Compares:

• Desired state
• Current state
• Creates, updates, or deletes Kubernetes objects to reconcile the difference

What it does NOT do

• Does not run containers
• Does not deploy Pods directly
• Does not communicate with kubelet

Examples of controllers it runs:

• Deployment controller
• ReplicaSet controller
• Job controller
• Node controller
• Endpoint controller
• Namespace controller

Key mental model:

Controllers manage objects, not containers.

📚 Official reference: https://kubernetes.io/docs/concepts/architecture/controller/

3. Worker Node Components

3.1 kubelet — The Executor

The kubelet runs on every worker node.

Watches the API server

Detects Pods assigned to its node

• Pulls images
• Starts containers via the container runtime
• Reports status back to the API server

Another critical rule:

kubelet pulls instructions — nothing is pushed to it.

📚 Official reference: https://kubernetes.io/docs/concepts/overview/components/#kubelet

3.2 Container Runtime

Examples:

• containerd
• CRI-O

Responsibilities:

• Pull images
• Create containers
• Manage container lifecycle

📚 Official reference: https://kubernetes.io/docs/setup/production-environment/container-runtimes/

3.3 kube-proxy — Networking Glue

• Programs iptables or IPVS rules
• Enables Service → Pod communication

📚 Official reference: https://kubernetes.io/docs/concepts/services-networking/service/

4. Pod Creation: The Exact Lifecycle

Let’s walk through what actually happens when you create a Pod.

Step 1: Apply the Manifest

kubectl apply -f pod.yaml

• kubectl sends the request to the API server
• API server authenticates, authorizes, validates
• Pod object is stored in etcd

At this point:

• Desired state exists
• Nothing is running yet

Step 2: Scheduler Assigns a Node

• Scheduler detects a Pod with no spec.nodeName
• Selects a suitable node
• Updates the Pod object via the API server

The Pod is now assigned, but still not running.

Step 3: kubelet Executes

kubelet on the selected node:

• sees the Pod assignment
• pulls container images
• starts containers
• Updates PodStatus via the API server

Containers are now running.

📚 Pod lifecycle reference: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

5. Where Is the Controller Manager in This Flow?

This is a crucial insight.

Standalone Pod (pod.yaml)

• Controller Manager is mostly not involved
• Pods do not self-heal
• If the Pod dies, it stays dead

Controlled Workloads (Real-World Usage)

For Deployments, Jobs, StatefulSets, etc.:

• Deployment controller → creates ReplicaSet
• ReplicaSet controller → creates Pods
• Job controller → recreates Pods until completion

Self-healing comes from controllers, not from Pods.

📚 Deployment flow reference: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

6. Core Mental Models

1. Everything goes through the API server
2. Controllers reconcile objects
3. Scheduler assigns nodes
4. kubelet runs containers
5. Pods are not self-healing — controllers are

8. Final One-Sentence Summary

Kubernetes is a pull-based, declarative system where controllers reconcile state, the scheduler assigns nodes, and kubelets execute containers — all coordinated through the API server.