TECH **ReplicaSets & Deployments: Zero-Fluff, Hands-On Guide**

ReplicaSets & Deployments: Zero-Fluff, Hands-On Guide

(Rolling Updates, Rollbacks, and Production-Grade Kubernetes)

1. What This Is & Why It Matters

You’re a DevOps engineer at a SaaS company. Your team just pushed a buggy release to production, and now your app is crashing under load. Users are complaining, your boss is Slack-pinging you, and the on-call engineer is frantically checking logs.

Here’s the problem:
- Your app runs in Kubernetes.
- You manually scaled Pods up/down, but now you have no way to safely roll back to the last stable version.
- If you delete Pods, Kubernetes doesn’t automatically replace them (unless you’re using a ReplicaSet).
- If you update the app, Kubernetes doesn’t gradually replace Pods (unless you’re using a Deployment with a rolling update strategy).

This guide fixes that.
- ReplicaSets ensure a fixed number of Pods are always running (self-healing).
- Deployments manage ReplicaSets and enable rolling updates (zero-downtime deploys) and rollbacks (instant recovery from bad releases).
- Without these, you’re either: - Manually managing Pods (error-prone, unscalable).
- Risking downtime during updates (bad for users, worse for your reputation).

Real-world scenario:
You’re deploying a new version of your API. The old version (v1) is running in production. You need to: 1. Deploy v2 without downtime.
2. Roll back to v1 instantly if v2 crashes.
3. Scale up/down without manual intervention.

This guide shows you how.

2. Core Concepts & Components

? ReplicaSet (rs)

• Definition: A Kubernetes controller that ensures a specified number of Pod replicas are running at all times.
• Production insight:
• If a Pod crashes, the ReplicaSet replaces it automatically.
• If you manually delete a Pod, the ReplicaSet recreates it.
• ⚠️ But: ReplicaSets do not manage rollouts or rollbacks. For that, you need a Deployment.

? Deployment (deploy)

• Definition: A higher-level abstraction that manages ReplicaSets and enables rolling updates and rollbacks.
• Production insight:
• Deployments create and manage ReplicaSets (you rarely interact with ReplicaSets directly).
• They allow zero-downtime updates (e.g., v1 → v2 without users noticing).
• They support instant rollbacks (if v2 fails, revert to v1 in seconds).

? Rolling Update

• Definition: A deployment strategy where Pods are replaced gradually (not all at once).
• Production insight:
• Prevents downtime (some Pods stay online while others update).
• Configurable via maxSurge (how many extra Pods can be created) and maxUnavailable (how many can be down during update).

? Rollback

• Definition: Reverting to a previous version of a Deployment if the new one fails.
• Production insight:
• Kubernetes keeps a history of ReplicaSets (by default, last 10 revisions).
• Rollbacks are instant (no need to rebuild images or redeploy).

? kubectl rollout

• Definition: A CLI command to manage Deployment updates and rollbacks.
• Production insight:
• kubectl rollout status → Check if a rollout is still in progress.
• kubectl rollout undo → Instantly revert to the previous version.
• kubectl rollout history → See all past revisions.

? strategy (in Deployment YAML)

• Definition: Defines how a Deployment updates Pods (RollingUpdate or Recreate).
• Production insight:
• RollingUpdate (default) → Gradual replacement (zero downtime).
• Recreate → Kill all old Pods first, then start new ones (downtime).
• ⚠️ Never use Recreate in production unless you want downtime.

? revisionHistoryLimit

• Definition: How many old ReplicaSets Kubernetes keeps for rollbacks.
• Production insight:
• Default: 10 (Kubernetes stores the last 10 revisions).
• Set to 0 to disable rollbacks (⚠️ dangerous).
• Set to 5 to save cluster resources (if you rarely roll back).

? minReadySeconds

• Definition: How long a Pod must be "ready" before Kubernetes considers it available.
• Production insight:
• Prevents Kubernetes from marking a Pod as "ready" too soon (e.g., if your app takes 10 seconds to start).
• Default: 0 (Pod is considered ready as soon as its containers pass readiness probes).

3. Step-by-Step Hands-On: Deploy, Update, and Roll Back

Prerequisites

✅ A running Kubernetes cluster (Minikube, Kind, EKS, GKE, AKS, etc.).
✅ kubectl installed and configured.
✅ A simple Docker image (we’ll use nginx:1.23 and nginx:1.24).

Step 1: Deploy a Simple App (v1)

We’ll deploy nginx:1.23 with 3 replicas.

1.1 Create a Deployment YAML (nginx-deploy.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23
        ports:
        - containerPort: 80

1.2 Apply the Deployment

kubectl apply -f nginx-deploy.yaml

1.3 Verify the Deployment

kubectl get deployments
kubectl get pods
kubectl get rs  # Check the ReplicaSet

Expected output:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3/3     3            3           10s

NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-5f7d8c6b5c-abc12   1/1     Running   0          10s
nginx-deploy-5f7d8c6b5c-def34   1/1     Running   0          10s
nginx-deploy-5f7d8c6b5c-ghi56   1/1     Running   0          10s

NAME                      DESIRED   CURRENT   READY   AGE
nginx-deploy-5f7d8c6b5c   3         3         3       10s

Step 2: Update the App (v1 → v2) with Rolling Update

We’ll update the image to nginx:1.24 without downtime.

2.1 Edit the Deployment (2 ways)

Option 1: Edit the YAML and re-apply

# Change `image: nginx:1.23` → `image: nginx:1.24`
kubectl apply -f nginx-deploy.yaml

Option 2: Use kubectl set image (faster)

kubectl set image deployment/nginx-deploy nginx=nginx:1.24

2.2 Watch the Rolling Update

kubectl rollout status deployment/nginx-deploy

Expected output:

Waiting for deployment "nginx-deploy" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deploy" successfully rolled out

2.3 Verify the Update

kubectl get pods -o wide  # Check Pod IPs (old Pods are replaced)
kubectl describe deployment nginx-deploy | grep Image  # Confirm new image

Expected output:

Image:        nginx:1.24

Step 3: Roll Back to v1 (If v2 Fails)

Suppose nginx:1.24 has a bug. Let’s roll back to nginx:1.23.

3.1 Check Rollout History

kubectl rollout history deployment/nginx-deploy

Expected output:

deployment.apps/nginx-deploy
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

3.2 Roll Back to Revision 1

kubectl rollout undo deployment/nginx-deploy --to-revision=1

3.3 Verify Rollback

kubectl rollout status deployment/nginx-deploy
kubectl describe deployment nginx-deploy | grep Image

Expected output:

Image:        nginx:1.23

Step 4: Customize Rolling Update Strategy

By default, Kubernetes: - Creates 1 new Pod at a time (maxSurge: 25%).
- Allows 1 Pod to be unavailable (maxUnavailable: 25%).

Let’s customize this for faster updates (but higher risk).

4.1 Edit the Deployment YAML

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1      # Create 1 extra Pod during update
      maxUnavailable: 0  # Never allow Pods to be unavailable

4.2 Apply the Changes

kubectl apply -f nginx-deploy.yaml

4.3 Verify the Strategy

kubectl describe deployment nginx-deploy | grep -A 3 Strategy

Expected output:

StrategyType:           RollingUpdate
RollingUpdateStrategy:  1 max unavailable, 1 max surge

4. ? Production-Ready Best Practices

? Security

• Use readOnlyRootFilesystem: true in Pod specs to prevent writes to the container filesystem.
• Set securityContext (e.g., runAsNonRoot: true).
• Use imagePullSecrets for private Docker registries.
• Limit revisionHistoryLimit (e.g., 5) to avoid cluster bloat.

? Cost Optimization

• Set replicas based on load (use Horizontal Pod Autoscaler for dynamic scaling).
• Use minReadySeconds to avoid premature scaling (e.g., 30 for slow-starting apps).
• Clean up old ReplicaSets (kubectl delete rs <old-rs-name>).

?️ Reliability & Maintainability

• Always use RollingUpdate (never Recreate in production).
• Set progressDeadlineSeconds (e.g., 600) to fail fast if a rollout stalls.
• Use kubectl rollout pause to debug a failing update.
• Label Deployments clearly (e.g., app: frontend, env: prod).

? Observability

• Monitor kubectl rollout status in CI/CD pipelines.
• Set up alerts for CrashLoopBackOff (indicates a bad rollout).
• Log Deployment events (kubectl get events --sort-by=.metadata.creationTimestamp).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "What happens if you delete a Pod managed by a ReplicaSet?"
2. ✅ The ReplicaSet recreates it.

3. ❌ Nothing (⚠️ trap answer).

4. "How do you roll back a Deployment to the previous version?"

5. ✅ kubectl rollout undo deployment/<name>

6. ❌ kubectl delete deployment/<name> (⚠️ destroys the Deployment).

7. "What’s the difference between maxSurge and maxUnavailable?"

8. maxSurge: How many extra Pods can be created during an update.

9. maxUnavailable: How many Pods can be down during an update.

10. "What’s the default Deployment strategy?"

11. ✅ RollingUpdate

12. ❌ Recreate (⚠️ trap answer).

13. "How do you check the rollout history of a Deployment?"

14. ✅ kubectl rollout history deployment/<name>
15. ❌ kubectl get deployments (⚠️ doesn’t show revisions).

Key ⚠️ Trap Distinctions

7. ? Hands-On Challenge (With Solution)

Challenge

You have a Deployment (webapp) running nginx:1.23 with 5 replicas. You need to: 1. Update it to nginx:1.24 without downtime.
2. Pause the rollout after 2 Pods are updated (for debugging).
3. Resume the rollout after verifying the new Pods are healthy.

Solution

# 1. Update the image (rolling update starts)
kubectl set image deployment/webapp nginx=nginx:1.24

# 2. Pause the rollout after 2 Pods are updated
kubectl rollout pause deployment/webapp

# 3. Verify 2 new Pods are running
kubectl get pods  # Should show 2 new Pods (nginx:1.24) and 3 old Pods (nginx:1.23)

# 4. Resume the rollout
kubectl rollout resume deployment/webapp

# 5. Verify all Pods are updated
kubectl rollout status deployment/webapp

Why it works:
- kubectl set image triggers a rolling update.
- kubectl rollout pause stops the update mid-way (useful for debugging).
- kubectl rollout resume continues the update.

8. ? Rapid-Reference Crib Sheet

⚠️ Exam Traps:
- kubectl delete pod <name> does not trigger a rollback (ReplicaSet recreates the Pod).
- kubectl edit deployment does not pause a rollout (use kubectl rollout pause).
- maxSurge: 0 is invalid (must be at least 1 or a percentage).

9. ? Where to Go Next

1. Kubernetes Official Docs – Deployments
2. Kubernetes Rolling Updates Deep Dive
3. Kubernetes Best Practices – Deployments
4. CKA Exam Guide – Deployments (for hands-on practice)

Final Thought

ReplicaSets and Deployments are the backbone of reliable Kubernetes apps. Master them, and you’ll: - Eliminate downtime during updates.
- Recover instantly from bad releases.
- Scale effortlessly without manual intervention.

Now go deploy something. ?