Kubernetes Architecture: Control Plane, Nodes, Pods and Services

Kubernetes is a container orchestrator: you declare the state you want ("run five replicas of this image, reachable on this port") and it continuously works to make the cluster match. Its architecture splits into a control plane (the API server, the etcd database, the scheduler and controllers) and worker nodes that run your pods. Almost everything it does follows one pattern, the reconciliation loop: observe actual state, compare it with desired state, act to close the gap.

Control plane and nodes

The core objects

• Pod: the smallest unit, one or more containers sharing a network namespace and volumes, scheduled together on one node. Pods are disposable.
• Deployment: desired replicas and a pod template; it rolls out changes by managing ReplicaSets, with rolling updates by default. See deployment strategies.
• StatefulSet: pods with stable names and their own persistent volumes, for databases and other stateful systems.
• DaemonSet: one pod per node, for agents such as log shippers.
• Job / CronJob: run-to-completion work, once or on a schedule.
• Service: a stable virtual IP and DNS name in front of a changing set of pods selected by labels. See service discovery.
• Ingress / Gateway: HTTP routing from outside the cluster to services.
• ConfigMap and Secret: configuration and sensitive values injected into pods. See secrets management.

What happens when you deploy

1. You apply a Deployment manifest; the API server validates it and stores it in etcd.
2. The Deployment controller sees a new pod template and creates a new ReplicaSet, scaling it up while scaling the old one down, within surge and unavailability limits.
3. The ReplicaSet controller creates pod objects; they're unscheduled.
4. The scheduler picks a node for each pod and records the binding.
5. The kubelet on that node pulls the image, starts containers and runs probes. Once the readiness probe passes, the pod is added to its Service's endpoints and receives traffic.
6. If a container crashes, the kubelet restarts it; if a node dies, controllers recreate its pods elsewhere.

Readiness and liveness probes are different: readiness decides whether a pod gets traffic, liveness decides whether it gets restarted. A liveness probe that checks a database will restart every pod during a database blip. See health checks.

Resources, scaling and reliability

• Requests and limits: requests reserve CPU and memory for scheduling; limits cap usage. A container over its memory limit is killed; CPU over its limit is throttled.
• Autoscaling: the Horizontal Pod Autoscaler adds pods based on CPU or custom metrics, and a cluster autoscaler adds nodes when pods can't be scheduled. See autoscaling.
• Spreading: topology spread constraints and anti-affinity keep replicas across nodes and zones, so one failure doesn't take them all.
• PodDisruptionBudgets limit how many replicas voluntary disruptions (node upgrades) can take down at once.
• Control plane availability: run the API server and etcd replicated across zones; workloads keep running if the control plane is briefly down, but nothing new can be scheduled.