Kubernetes architecture

Docker Compose runs a stack on one machine. Production systems need more: dozens or thousands of containers spread over many machines, restarted automatically when they fail, updated without downtime and scaled with demand. Kubernetes is the system most companies use to do this, and it is built around one powerful idea.

Desired state and reconciliation

With Kubernetes you don’t issue commands like “start three containers on server 7”. You declare what you want:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: shop-web:1.4.2
          ports:
            - containerPort: 80
          resources:
            requests: { cpu: 250m, memory: 256Mi }

kubectl apply -f web.yaml

Kubernetes stores this desired state. Then controllers run in endless loops: observe the actual state, compare it with the desired state, and act to close the gap. Crashed container? Start another. Node lost? Reschedule its pods. This reconciliation loop is what makes Kubernetes self-healing.

Here is a controller at work. Change the desired number of replicas, kill pods, or pause the controller:

InteractiveThe reconciliation loopKill a pod or change the replicas

Loading visual…

The controller never follows a script of commands; it only compares desired and actual state and closes the gap, pass after pass. Real controllers react to changes within moments; this loop is slowed down so you can watch each pass.

Inside a cluster

Follow the Deployment above through a cluster:

Scroll storyA Kubernetes cluster, from kubectl to running podsStep 1 of 7

Loading 3D model…

1
The cluster
A control plane makes decisions; worker nodes run your containers. Each node runs a kubelet, which manages pods on that node, and kube-proxy, which handles service networking.
2
Declare the desired state
kubectl (or your CI pipeline) sends the Deployment to the API server — the front door of the cluster. It authenticates the request and validates the object.
3
Store it in etcd
The API server saves the object in etcd, a consistent key-value store that holds the entire state of the cluster.
4
Controllers create pods
The deployment and ReplicaSet controllers notice that three replicas are wanted and none exist, and create three Pod objects — not yet assigned to any node.
5
The scheduler places them
The scheduler sees unassigned pods and chooses a node for each, considering requested CPU and memory, constraints and spreading replicas apart.
6
Kubelets start containers
Each node’s kubelet sees a pod assigned to it, pulls the image and starts the containers through the container runtime, then reports status back to the API server.
7
A Service fronts the pods
A Service gives the three pods one stable name and virtual IP. kube-proxy on every node routes traffic for it to healthy pods, wherever they run.

The components

API server: The single entry point. Every component and every kubectl command talks to it.
etcd: The cluster’s database: a replicated key-value store holding all objects and their state.
Scheduler: Assigns new pods to nodes based on resources, constraints and policies.
Controller manager: Runs the reconciliation loops for Deployments, ReplicaSets, nodes, jobs and more.
kubelet: The agent on each node that starts, stops and health-checks the pods assigned to it.
kube-proxy: Programs each node’s networking so traffic to a Service reaches one of its pods.

Managed services — Amazon EKS, Google GKE, Azure AKS — run the control plane for you. Your team mostly deals with nodes, workloads and configuration.

Pods, not containers

The smallest thing Kubernetes schedules is a pod: one or more containers that always run together on the same node, share a network identity (one IP address) and can share volumes. Most pods have a single application container; sometimes a helper “sidecar” container runs alongside, for example to forward logs.

Pods are disposable. They are replaced on every deploy, crash or node failure, each time with a new IP address. That is why clients never talk to pods directly — they talk to a Service, which always points at the current set of healthy pods matching its label selector.

Be the scheduler’s customer. Request resources for a new pod and schedule it; push the request up until no node can take it:

InteractiveWhere will the pod land?Set the requests, then schedule

Loading visual…

The scheduler looks only at requests — what each pod reserved — not at how busy the node really is. A node with idle CPU is still full if its capacity is already requested. This model scores nodes only by how much stays free; the real scheduler also balances CPU against memory and spreads replicas. The event lines match what kubectl describe pod shows.

We have seen how pods get created. In the next lecture you get your hands on the controls: crash pods, scale, roll out a new version and take down a node — and watch Kubernetes put everything back.

In this lecture you will

Desired state and reconciliation

Inside a cluster

The components

Pods, not containers

Key takeaways

Check your understanding