Skip to content
docktionary

Kubernetes

Cluster architecture

A Kubernetes cluster is two kinds of machine doing two different jobs: a control plane that makes decisions, and worker nodes that run your containers.

The control plane

The control plane doesn't run your application — it runs the components that decide what should be running and where.

  • kube-apiserver — the front door. Every read and write, including everything kubectl does, goes through it as a REST call.
  • etcd — a distributed key-value store holding the entire cluster state. Lose etcd without a backup and you've lost the cluster.
  • kube-scheduler — watches for Pods with no node assigned yet, and picks a node for each based on resource requests, constraints, and affinity rules.
  • kube-controller-manager — runs the reconciliation loops (the Deployment controller, the Node controller, and others) that continuously push actual state toward desired state.
  • cloud-controller-manager — talks to the cloud provider's API for things Kubernetes doesn't know natively: provisioning a LoadBalancer, attaching a disk, labeling a node with its region.

Worker nodes

Every worker node runs three things:

  • kubelet — watches the API server for Pods assigned to this node, and tells the container runtime to start or stop them accordingly.
  • container runtime — containerd or CRI-O, actually pulling images and running containers via the Container Runtime Interface (CRI).
  • kube-proxy — maintains the network rules that let traffic to a Service's virtual IP reach the right Pods.

The reconciliation loop

Kubernetes is declarative: you submit a manifest describing the state you want, and a controller spends forever nudging reality toward it. This is the same pattern behind a Deployment maintaining replica count, a Service updating its endpoints, and an Operator managing a database — watch, compare, act, repeat.

text
you:        "I want 3 replicas of this Pod running"
apiserver:  stores that desired state in etcd
controller: "currently 1 is running" -> creates 2 more
kubelet:    starts the containers for those new Pods on its node
controller: watches again, sees 3/3, does nothing until state drifts

Seeing it for yourself

terminal
kubectl get nodes -o wide
kubectl cluster-info
kubectl get pods -n kube-system   # the control plane's own components,
                                   # if running a self-hosted control plane

On managed Kubernetes (EKS, GKE, AKS) the control plane is run for you and usually isn't visible as Pods you can list — see managed Kubernetes for what that split of responsibility looks like in practice.