LFCE 136 🐧 Kubernetes — Cluster Concepts - KandZ

⏱️ Estimated read: 11 min | |

A Kubernetes cluster is not a single program. It is a set of machines divided into two roles: the control plane, which makes global decisions about the cluster, and the worker nodes, which run the application workloads. The control plane decides where a Pod should run, stores the desired state, and responds when the actual state diverges. The worker nodes execute the containers, report their status, and provide the network plumbing that lets Pods communicate. Neither role is useful alone. A control plane without workers has nowhere to run Pods. A worker without a control plane has no instructions to follow.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

This chapter covers the conceptual architecture of a Kubernetes cluster: the components of the control plane and their individual responsibilities, the components that run on every worker node, the add-ons that provide cluster-wide services like DNS and networking, and the declarative reconciliation loop that connects the desired state in etcd to the running containers on the nodes.

Key point: The control plane does not run application containers. It runs the components that decide where containers should run. The worker nodes run the containers. The separation is what allows the control plane to be replicated across multiple machines for high availability without affecting the workload capacity.

Why the cluster has this architecture

The declarative problem. Kubernetes is not a system that executes commands. It is a system that stores a desired state and continuously works to make the actual state match it. The kube-apiserver receives a YAML manifest that says “I want three replicas of this image.” The etcd stores that desired state. The kube-scheduler assigns the Pods to nodes. The kubelet on each node starts the containers. The kube-controller-manager watches for discrepancies—a Pod died, a node went offline—and creates or deletes resources to restore the desired state. This reconciliation loop is the core of the architecture .

The high-availability problem. In a production cluster, the control plane runs across multiple machines. The kube-apiserver is stateless and can be scaled horizontally. The etcd is replicated across an odd number of members for quorum. The kube-scheduler and kube-controller-manager use leader election so that only one instance is active at a time, with the others ready to take over if the leader fails . The worker nodes are separate machines, and the control plane can lose a node without losing the Pods that are running on the remaining nodes.

The node problem. A worker node must provide three things: a way to run containers, a way to report status to the control plane, and a way to route traffic to the containers. The container runtime (containerd, CRI-O) runs the containers. The kubelet is the agent that receives Pod specifications from the API server and ensures the containers are running . The kube-proxy maintains the network rules that implement Services, although some CNI plugins provide their own proxying and make kube-proxy optional .

a. The control plane components

The control plane makes global decisions about the cluster and detects and responds to events. It can run on any machine in the cluster, but in practice it runs on dedicated machines that do not host user workloads .

The kube-apiserver is the front end of the control plane. It exposes the Kubernetes HTTP API, and every interaction with the cluster—kubectl, the scheduler, the controller manager, the kubelets—goes through it. It is stateless and designed to scale horizontally by running multiple instances behind a load balancer .

The etcd is the backing store for all cluster data. It is a consistent and highly available key-value store. Every object in the cluster—Pods, Services, Deployments, Secrets—is stored in etcd. If etcd is lost, the cluster’s state is lost. A backup plan for etcd is not optional .

The kube-scheduler watches for newly created Pods that have no assigned node and selects a node for them to run on. The scheduling decision considers resource requirements, hardware and software constraints, affinity and anti-affinity rules, data locality, and deadlines .

The kube-controller-manager runs the controller processes. Each controller is a separate logical process, but they are compiled into a single binary and run in a single process. The Node controller notices when nodes go down. The Job controller creates Pods for one-off tasks. The EndpointSlice controller populates the link between Services and Pods. The ServiceAccount controller creates default ServiceAccounts for new namespaces .

The cloud-controller-manager is optional. It embeds cloud-specific control logic and links the cluster to the cloud provider’s API. It runs only the controllers that are specific to the cloud provider. In a self-hosted cluster or a learning environment, it is not present .

b. The node components

Node components run on every worker node. They maintain the running Pods and provide the Kubernetes runtime environment .

The kubelet is the primary node agent. It receives Pod specifications from the API server and ensures that the containers described in those specifications are running and healthy. It does not manage containers that were not created by Kubernetes .

The kube-proxy is a network proxy that runs on each node. It maintains network rules that allow communication to Pods from inside or outside the cluster. The rules implement the Service abstraction. Some network plugins provide their own proxying, and in that case, the node does not need to run kube-proxy .

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

c. Cluster add-ons

Add-ons are cluster-wide features that extend the functionality of Kubernetes. They are not part of the core control plane or node components, but most clusters depend on them.

CoreDNS is the cluster DNS server. It provides name resolution for all Pods in the cluster, which is what allows a Service to be reached by its name rather than its IP address .

CNI plugins provide the cluster network. They assign IP addresses to Pods and implement the network policies that control traffic between them. The choice of CNI plugin determines the network model: overlay or native routing, the IP address range, and the support for NetworkPolicy .

The Kubernetes Dashboard is a web-based UI for the cluster. It is optional but useful for visualizing the state of resources.

Complete Example Session

# ============================================
# PART 1: THE CLUSTER ROLES
# ============================================
# Control plane: makes global decisions
# Worker nodes: run application containers
#
# A cluster needs at least one control plane
# and at least one worker node.

# ============================================
# PART 2: kube-apiserver
# ============================================
# The front end of the control plane.
# Every kubectl command goes through it.
# Stateless, horizontally scalable.

# ============================================
# PART 3: etcd
# ============================================
# The backing store for all cluster data.
# A key-value store with consistency and HA.
# Losing etcd means losing the cluster state.

# ============================================
# PART 4: kube-scheduler
# ============================================
# Watches for Pods without a node.
# Selects a node for each Pod.
# Considers resources, affinity, constraints.

# ============================================
# PART 5: kube-controller-manager
# ============================================
# Runs the control loops.
# Node controller: notices node failures.
# Job controller: creates Pods for Jobs.
# EndpointSlice controller: links Services and Pods.

# ============================================
# PART 6: kubelet
# ============================================
# Runs on every worker node.
# Receives Pod specs from the API server.
# Ensures the containers are running.

# ============================================
# PART 7: kube-proxy
# ============================================
# Runs on every worker node.
# Maintains network rules for Services.
# Optional if the CNI plugin provides proxying.

# ============================================
# PART 8: CONTAINER RUNTIME
# ============================================
# containerd or CRI-O.
# Runs the containers.
# Implements the CRI interface.

# ============================================
# PART 9: ADD-ONS
# ============================================
# CoreDNS: cluster DNS.
# CNI plugin: cluster networking.
# Dashboard: web UI (optional).

# ============================================
# PART 10: THE RECONCILIATION LOOP
# ============================================
# Desired state (YAML) → etcd
# Controller manager watches for divergence
# Scheduler assigns Pods to nodes
# Kubelet starts containers
# Status reported back to API server

The ten parts covered the cluster roles, the API server, etcd, the scheduler, the controller manager, the kubelet, kube-proxy, the container runtime, the add-ons, and the reconciliation loop.

Quick Reference

Control plane components

Component	Responsibility
`kube-apiserver`	Exposes the Kubernetes API, front end
`etcd`	Backing store for all cluster data
`kube-scheduler`	Assigns Pods to nodes
`kube-controller-manager`	Runs controller loops
`cloud-controller-manager`	Cloud provider integration (optional)

Node components

Component	Responsibility
`kubelet`	Ensures Pods and containers are running
`kube-proxy`	Maintains network rules for Services (optional with some CNIs)
Container runtime	Runs the containers (containerd, CRI-O)

Add-ons

Add-on	Purpose
CoreDNS	Cluster DNS resolution
CNI plugin	Pod networking and NetworkPolicy
Dashboard	Web UI (optional)

High availability

Component	HA mechanism
`kube-apiserver`	Horizontal scaling, multiple instances
`etcd`	Replicated members, quorum
`kube-scheduler`	Leader election
`kube-controller-manager`	Leader election

Best Practices

✅ Do This:

# Back up etcd regularly
etcdctl snapshot save backup.db                             # ✅

# Run the control plane on dedicated machines
# Do not schedule user workloads there                     # ✅

# Use three or more etcd members for quorum
# Odd number for majority voting                             # ✅

# Deploy a CNI plugin before creating Pods
# Pods cannot network without it                             # ✅

❌ Don’t Do This:

# Run a single etcd member in production
# No quorum, no high availability                            # ❌

# Schedule application Pods on control plane nodes
# Without taints and tolerations, they compete with control plane # ❌

# Assume kube-proxy is always required
# Some CNI plugins replace it                                # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Cluster loses state	`etcd` data lost, no backup	Back up `etcd` regularly
Pods stay Pending	No worker nodes or insufficient resources	Check `kubectl get nodes` and resource requests
Pods cannot communicate	No CNI plugin installed	Deploy a CNI plugin
Service name does not resolve	CoreDNS not running	Check the `kube-system` namespace for CoreDNS Pods
Control plane is single point of failure	One `kube-apiserver`, one `etcd`	Replicate the control plane

Real-World Examples

1. Check control plane health

kubectl get componentstatuses

2. Check nodes

kubectl get nodes

3. Check control plane Pods

kubectl get pods -n kube-system

4. Check CoreDNS

kubectl get pods -n kube-system -l k8s-app=kube-dns

5. Check etcd

kubectl exec -n kube-system etcd-controlplane -- etcdctl member list

6. Check scheduler

kubectl get pods -n kube-system -l component=kube-scheduler

7. Check controller manager

kubectl get pods -n kube-system -l component=kube-controller-manager

8. Describe a node

kubectl describe node worker-1

9. Check kubelet

systemctl status kubelet

10. Check CNI

ls /etc/cni/net.d/

Visual

The cluster architecture

┌─────────────────────────────────────────────────────────────┐
│  CONTROL PLANE                                               │
│                                                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ kube-        │  │   etcd       │  │ kube-        │      │
│  │ apiserver    │  │              │  │ scheduler    │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│  ┌──────────────────────────────────────────────────────┐  │
│  │ kube-controller-manager                              │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                              │
│  ─────────────────────────────────────────────────────────  │
│                                                              │
│  WORKER NODE 1              WORKER NODE 2                    │
│  ┌──────────────┐           ┌──────────────┐                │
│  │ kubelet      │           │ kubelet      │                │
│  │ kube-proxy   │           │ kube-proxy   │                │
│  │ runtime      │           │ runtime      │                │
│  │ ┌──────────┐ │           │ ┌──────────┐ │                │
│  │ │ Pod      │ │           │ │ Pod      │ │                │
│  │ └──────────┘ │           │ └──────────┘ │                │
│  └──────────────┘           └──────────────┘                │
└─────────────────────────────────────────────────────────────┘

The reconciliation loop

┌─────────────────────────────────────────────────────────────┐
│  RECONCILIATION                                              │
│                                                              │
│  Desired state (YAML)                                        │
│       │                                                      │
│       ▼                                                      │
│  kube-apiserver ──► etcd                                     │
│       │                                                      │
│       ▼                                                      │
│  Controller manager watches for divergence                   │
│       │                                                      │
│       ├── Pod died ──► create replacement                   │
│       ├── Node down ──► reschedule Pods                     │
│       └── Replica count low ──► create more                 │
│       │                                                      │
│       ▼                                                      │
│  Scheduler assigns new Pods to nodes                         │
│       │                                                      │
│       ▼                                                      │
│  Kubelet starts containers                                   │
└─────────────────────────────────────────────────────────────┘

Control plane HA

┌─────────────────────────────────────────────────────────────┐
│  HIGH AVAILABILITY                                           │
│                                                              │
│  kube-apiserver × 3 (load balanced)                          │
│  etcd × 3 (quorum, one leader)                               │
│  kube-scheduler × 3 (leader election)                        │
│  kube-controller-manager × 3 (leader election)               │
│                                                              │
│  One node fails: quorum survives, leader re-elected.         │
└─────────────────────────────────────────────────────────────┘

Add-ons

┌─────────────────────────────────────────────────────────────┐
│  ADD-ONS                                                     │
│                                                              │
│  CoreDNS                                                     │
│    └── Service name resolution                               │
│                                                              │
│  CNI plugin                                                  │
│    ├── Pod IP assignment                                     │
│    └── NetworkPolicy enforcement                             │
│                                                              │
│  Dashboard (optional)                                        │
│    └── Web UI                                                │
└─────────────────────────────────────────────────────────────┘

Summary

Item	Value
Control plane	Makes global decisions
Worker nodes	Run application Pods
API server	Front end, exposes the Kubernetes API
etcd	Backing store for all cluster data
Scheduler	Assigns Pods to nodes
Controller manager	Runs reconciliation loops
Kubelet	Node agent, ensures Pods run
kube-proxy	Network rules for Services
Container runtime	Runs containers
CoreDNS	Cluster DNS
CNI plugin	Pod networking

Key takeaways:

The cluster is divided into a control plane and worker nodes. The control plane makes global decisions, and the worker nodes run the application containers. Every cluster needs at least one control plane and at least one worker node .
The kube-apiserver is the front door. Every interaction with the cluster goes through it. It is stateless and can be scaled horizontally for high availability .
etcd is the source of truth. Every object in the cluster is stored there. Losing etcd means losing the cluster’s state. A backup plan is mandatory .
The kubelet is the node agent. It receives Pod specifications from the API server and ensures the containers are running. The container runtime does the actual running .
kube-proxy is optional with some CNI plugins. It maintains the network rules for Services, but a CNI plugin that provides its own proxying can replace it .
Add-ons are not optional in practice. CoreDNS provides name resolution, and a CNI plugin provides Pod networking. A cluster without them is not functional for application workloads .

Remember: The Kubernetes cluster architecture is a separation of concerns. The control plane decides, and the worker nodes execute. The kube-apiserver is the interface, etcd is the memory, the scheduler is the placement decision, and the controller manager is the reconciliation loop. The kubelet on each node is the agent that carries out the instructions. The add-ons provide the cluster-wide services—DNS and networking—that the application workloads depend on. Understanding which component is responsible for which decision is what makes debugging a cluster tractable: a Pod that stays Pending is a scheduling problem, a Service that does not resolve is a CoreDNS problem, and a node that goes NotReady is a kubelet problem.

Was this helpful?

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!