Orchestration Core
Pods, Deployments & the reconcile loop
Lesson 1 of 5
What you'll learn
- Understand the Pod as the atomic scheduling unit and the Deployment as its manager
- See how a Deployment owns ReplicaSets which own Pods
- Internalize the declarative control loop that drives actual state toward desired
A Pod is the smallest thing Kubernetes schedules: one or more containers sharing a network namespace and storage. You rarely create Pods directly. Instead you declare a Deployment — your desired end state — and let the system maintain it.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: myorg/api:1.4.2
The ownership chain
A Deployment doesn't manage Pods directly. It creates a ReplicaSet, and the ReplicaSet ensures replicas Pods exist. This indirection is what makes rolling updates possible: a new ReplicaSet can scale up while the old one scales down.
kubectl apply -f api.yaml
kubectl get deploy,rs,pods -l app=api
The control loop
Every controller runs the same loop forever: observe actual state, compare to desired, act to close the gap. You never tell Kubernetes how to reach three replicas — you declare replicas: 3 and the ReplicaSet controller creates or deletes Pods until reality matches.
Declarative, not imperative
You describe the destination, not the route. If a node dies and takes a Pod with it, the same loop notices the shortfall and reschedules — no human in the path.
Run it. The controller scales actual replicas toward desired one step per tick, in either direction.
In a declarative Deployment, what is the controller's job when actual state drifts from the replicas you declared?
Saved on this device. Sign in to sync your progress everywhere.