iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Architecture

Kubernetes architecture: the control plane (API server, scheduler, controllers, etcd) and the data plane (kubelet, kube-proxy, container runtime).

Kubernetes — architecture

EXAMPLE
# ===== Two halves =====
# Control plane: makes decisions (scheduling, reconciliation)
# Data plane:    runs the workloads (your pods)

# ===== Control plane components =====
# kube-apiserver
#   The single entry point. Every kubectl / controller / kubelet call hits it.
#   Validates + persists desired state to etcd.
#
# etcd
#   Distributed key-value store; the source of truth for cluster state.
#   Sized for control plane (small + fast); not for app data.
#
# kube-scheduler
#   Picks a node for each new pod (based on resources, taints, affinity).
#
# kube-controller-manager
#   Runs controllers (Deployment, ReplicaSet, Node, Endpoint, Job, ...).
#   Each controller reconciles desired state -> actual state.
#
# cloud-controller-manager (managed K8s)
#   Integrates with the cloud provider (load balancers, volumes, nodes).

# ===== Data plane (per node) =====
# kubelet
#   Talks to apiserver; ensures pods on this node match the spec.
#   Reports node + pod status back.
#
# kube-proxy
#   Maintains iptables / IPVS rules so Services route to pods.
#
# container runtime (containerd, CRI-O)
#   Actually starts containers via the Container Runtime Interface (CRI).
#
# CNI plugin (Calico, Cilium, Flannel, AWS VPC CNI)
#   Sets up pod networking (each pod gets an IP routable across the cluster).

# ===== Request flow: kubectl apply -f deploy.yaml =====
# 1. kubectl -> apiserver (auth + validate)
# 2. apiserver -> etcd (persist Deployment spec)
# 3. Deployment controller sees new Deployment -> creates ReplicaSet
# 4. ReplicaSet controller -> creates Pods
# 5. Scheduler picks nodes for Pods
# 6. kubelet on each node pulls images + starts containers via CRI
# 7. kube-proxy + CNI route traffic via Services

# ===== Add-ons (NOT core but typically present) =====
# CoreDNS                in-cluster DNS
# Metrics Server         CPU / memory metrics (for HPA)
# Ingress controller     nginx, Traefik, Contour, ALB ingress
# CSI drivers            persistent volumes (EBS, NFS, ...)
# Network policies       Calico / Cilium enforce traffic rules

# ===== Managed K8s differences =====
# EKS / GKE / AKS run the control plane FOR you.
# You manage worker nodes + workloads.
# Different add-ons + IAM integration per provider.

# ===== Multi-tier mental model =====
# Cluster = control plane + nodes
# Namespace = logical grouping
# Workload = Deployment / StatefulSet / DaemonSet / Job
# Pod = 1+ containers sharing network + storage
# Container = your process

# ===== Patterns to internalise =====
# - Everything is desired state in etcd; controllers reconcile
# - apiserver is the only door — every component talks to it
# - kubelet is the node-side agent; treat it as untouchable
# - Add-ons (CoreDNS, metrics, ingress) are not optional in real clusters

# ===== Pitfalls =====
# - Modifying etcd directly (almost always wrong)
# - Self-managing the control plane when managed K8s would do
# - Skipping CNI choice -> network policy + perf surprises
# - Treating kube-proxy as a load balancer (it's a routing rules manager)

Why it matters

Control plane decides; data plane runs. Apiserver + etcd + scheduler + controllers + kubelet + kube-proxy + CNI is the seven-piece mental model. Once you see kubectl as submit-desired-state-to-apiserver and controllers reconcile, the system stops being mysterious.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Control plane: api-server, etcd, scheduler, controller-manager.
# Nodes: kubelet + kube-proxy + container runtime.
Try it Yourself »

Discussion

Loading…