Deployment, Replication Controller & ReplicaSet

A bare pod has no self-healing and no scaling: if it dies, it's gone, and there is no safe way to roll out a new version. We need controllers that keep a desired number of pod copies alive and manage rollouts.

Solution: Use a Deployment to manage a ReplicaSet that keeps N pod replicas running and enables rolling updates and rollbacks.

A shipping line files a standing order with the port: always keep three identical ships docked at this berth, no matter what. A dock supervisor walks the pier, and the moment one ship sinks or sails off he tugs in an identical replacement so the count is always three. A Kubernetes Deployment with its ReplicaSet is that standing order, and the ReplicaSet controller is the supervisor that keeps N identical pods running and recreates any that die.

The same cluster entities appear in every day's notes; the diagram below shows where this day's topic fits.

Graph legend — each node maps to the web nginx Deployment this day creates:

A lone pod has no self-healing and no scaling. If it dies, it's gone. Controllers keep a desired number of pod copies alive.

Controllers stack on top of each other — a Deployment owns ReplicaSets, which own the Pods.

Graph legend — each node maps to the layers of the web Deployment:

• Replication Controller (RC): the OLD way to keep N pods (legacy).
• ReplicaSet (RS): the newer RC, supports set-based label selectors.
• Deployment: manages ReplicaSets; adds rolling updates & rollbacks. -> Use Deployments in practice.

The ReplicaSet constantly compares actual vs desired pod count and recreates any that die.

Graph legend — each node maps to the self-healing of the web ReplicaSet:

A Deployment manifest wraps a Pod template plus a replica count and a label selector.

deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web            # MUST match template labels
  template:               # this is the Pod spec
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

kubectl apply -f deploy.yaml
kubectl get deploy,rs,pods           # see all three layers
kubectl get pods -l app=web          # filter by label

Change the replica count to scale up or down — imperatively or by editing the YAML.

kubectl scale deployment web --replicas=5     # imperative
# or edit replicas in YAML and re-apply (declarative)

Deployments swap pods gradually between old and new ReplicaSets, giving zero-downtime updates you can undo.

Graph legend — each node maps to a rolling update of the web Deployment:

kubectl set image deployment/web nginx=nginx:1.28   # trigger update
kubectl rollout status deployment/web               # watch progress
kubectl rollout history deployment/web              # revisions
kubectl rollout undo deployment/web                 # rollback!

The key upgrade from ReplicationController to ReplicaSet is set-based label selectors.

  ReplicationController: equality only   ->  app = web
  ReplicaSet: set-based too              ->  app in (web, api)

Deployment to ReplicaSet to Pods, plus a zero-downtime rolling update that swaps an old ReplicaSet for a new one.

Graph legend — each node maps to the web Deployment lifecycle:

• Hierarchy: Deployment -> ReplicaSet -> Pods.
• selector.matchLabels MUST match template.metadata.labels.
• Deployments add rolling updates + rollback; prefer them over RS/RC.

• [ ] Created a Deployment with 3 replicas
• [ ] Killed a pod, watched it self-heal
• [ ] Scaled up/down
• [ ] Did a rolling update and an undo rollback