ReplicaSets and Deployments

ReplicaSets and Deployments

ReplicaSet - keep N copies running

graph LR RS[ReplicaSet replicas=3] --> P1[Pod] RS --> P2[Pod] RS --> P3[Pod] P2 -.node dies.-> X((gone)) RS -->|reconcile| P4[new Pod]

Count Pods matching the selector, compare with spec.replicas, create or delete the difference. Self-healing and scaling are the same loop.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web        # must match the selector
    spec:
      containers:
        - name: web
          image: nginx:1.27

Pods are bound by selector, not by name - a loose Pod with a matching label gets adopted. A ReplicaSet has no rollout logic: a changed template does not touch running Pods.

Deployment - ReplicaSets with versions

graph TB D[Deployment web] --> RS1[ReplicaSet v1 - replicas 0] D --> RS2[ReplicaSet v2 - replicas 3] RS2 --> P1[Pod] RS2 --> P2[Pod] RS2 --> P3[Pod]

A changed Pod template creates a new ReplicaSet and scales the old one down step by step. The old ReplicaSet stays at 0 - that is your rollback. You never write ReplicaSets by hand; you read them when a rollout misbehaves.

Daily commands

kubectl create deploy web --image nginx:1.27 --replicas 3
kubectl scale deploy web --replicas 5
kubectl set image deploy/web nginx=nginx:1.28
kubectl rollout status deploy/web
kubectl get deploy,rs,pods -l app=web

Rollout strategies, history, rollback and probes: Day 3.

References