Kubernetes Deployments and ReplicaSets Explained: Scaling, Rolling Updates and Rollback

Kubernetes Deployments and ReplicaSets Explained#

Learn how Kubernetes keeps applications available, replaces failed Pods, scales replicas, performs rolling updates and safely rolls back a broken release.

What problem do Deployments and ReplicaSets solve?#

A standalone Pod is temporary. It can disappear because a container crashes, a node fails, an administrator deletes it or Kubernetes reschedules the workload. Running an important application as one manually created Pod therefore gives you no reliable recovery, scaling or update process.

Kubernetes solves this with controllers. A controller continuously compares the desired state in your YAML with the current state in the cluster and takes action when they differ.

Deployment#

Defines the desired application version and manages rolling updates, rollback history and ReplicaSets.

ReplicaSet#

Ensures the requested number of matching Pods exist at any time.

Pod#

Runs one or more containers. Pods are replaceable and should not be treated like permanent servers.

ReplicaSet explained with a simple example#

Suppose your desired state is three nginx Pods. The ReplicaSet watches Pods with the label app: nginx . If only two exist, it creates one. If four exist, it removes one. This is reconciliation.

apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx-rs spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.27 ports: - containerPort: 80

Apply and inspect it:

kubectl apply -f replicaset.yaml kubectl get replicasets kubectl get pods -l app=nginx kubectl describe replicaset nginx-rs

Why use a Deployment instead of creating a ReplicaSet directly?#

A ReplicaSet maintains Pod count, but it does not provide the full application release workflow. A Deployment creates and manages ReplicaSets for you. During an update, it normally creates a new ReplicaSet for the new Pod template and gradually scales the old ReplicaSet down.

• Capability — Deployment — ReplicaSet
• Maintain Pod replicas — Yes, through a ReplicaSet — Yes
• Rolling updates — Yes — No built-in rollout workflow
• Rollback — Yes — No
• Revision history — Yes — No
• Recommended for stateless applications — Yes — Usually managed indirectly

Production-style Deployment YAML#

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 revisionHistoryLimit: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.27.5 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10

Important fields#

• replicas: The desired number of Pods.
• selector.matchLabels: Identifies the Pods controlled by the Deployment.
• template.metadata.labels: Labels placed on newly created Pods. These must match the selector.
• template.spec: Defines containers, ports, probes, resources, volumes and other Pod settings.
• revisionHistoryLimit: Controls how many previous ReplicaSets remain available for rollback.
• maxSurge: How many extra Pods may temporarily exist during an update.
• maxUnavailable: How many desired Pods may be unavailable during an update.

Apply and inspect the Deployment#

kubectl apply -f deployment.yaml kubectl get deployments kubectl get replicasets kubectl get pods -l app=nginx kubectl describe deployment nginx-deployment

A healthy result for three replicas normally shows READY 3/3 , UP-TO-DATE 3 and AVAILABLE 3 .

Scaling a Deployment#

Imperative scaling#

kubectl scale deployment nginx-deployment --replicas=5 kubectl get deployment nginx-deployment kubectl get pods -l app=nginx

Declarative scaling#

Change replicas: 3 to replicas: 5 in Git or the YAML file, then apply it again:

kubectl apply -f deployment.yaml

How a rolling update works#

When the Pod template changes—for example, when the image changes—the Deployment creates a new ReplicaSet. It gradually adds new Pods and removes old Pods according to maxSurge and maxUnavailable .

1. The existing ReplicaSet continues serving version 1.
2. A new ReplicaSet creates version 2 Pods.
3. Readiness probes determine when each new Pod can receive traffic.
4. The old ReplicaSet is scaled down as the new Pods become ready.
5. The old ReplicaSet remains in rollout history with zero Pods, allowing rollback.

kubectl set image deployment/nginx-deployment nginx=nginx:1.28.0 kubectl rollout status deployment/nginx-deployment kubectl get replicasets kubectl get pods -w

RollingUpdate versus Recreate#

• Strategy — How it behaves — Typical use
• RollingUpdate — Gradually replaces old Pods with new Pods. — Web applications and APIs requiring availability.
• Recreate — Stops all old Pods before creating new Pods. — Applications where old and new versions cannot run together.

strategy: type: Recreate

Rollback a failed release#

kubectl rollout history deployment/nginx-deployment kubectl rollout history deployment/nginx-deployment --revision=2 kubectl rollout undo deployment/nginx-deployment kubectl rollout undo deployment/nginx-deployment --to-revision=2 kubectl rollout status deployment/nginx-deployment

A rollback changes the Deployment back to an earlier Pod template. It does not restore external databases or data changed by the application, so database migrations need their own rollback strategy.

Pause and resume a rollout#

kubectl rollout pause deployment/nginx-deployment kubectl set resources deployment/nginx-deployment -c nginx --limits=cpu=600m,memory=300Mi kubectl rollout resume deployment/nginx-deployment

Pausing is useful when you want to make several Pod-template changes and start one combined rollout afterward.

Real troubleshooting workflow#

Check Deployment status#

kubectl get deployment nginx-deployment kubectl describe deployment nginx-deployment

Check ReplicaSets#

kubectl get rs kubectl describe rs

Check Pods and events#

kubectl get pods -l app=nginx -o wide kubectl describe pod kubectl get events --sort-by=.metadata.creationTimestamp

Check logs#

kubectl logs kubectl logs --previous

Check rollout progress#

kubectl rollout status deployment/nginx-deployment --timeout=120s

Common rollout failures#

• Symptom — Likely cause — What to check
• ImagePullBackOff — Wrong image, tag or registry credentials — kubectl describe pod and imagePullSecrets
• CrashLoopBackOff — Application exits after starting — Current and previous container logs
• Pods running but not Ready — Readiness probe failing — Probe path, port, timeout and application startup
• ProgressDeadlineExceeded — New replicas failed to become available — Events, probes, scheduling and image status
• Pending Pods — Insufficient CPU, memory or scheduling constraints — Pod events, requests, taints and node capacity
• Service has no endpoints — Service selector does not match Pod labels — kubectl get endpoints and labels

Common mistakes#

• Creating or editing Pods directly instead of updating the Deployment.
• Using mutable image tags such as latest in production.
• Using the same label carelessly across unrelated workloads.
• Deploying without readiness probes and sending traffic too early.
• Setting no resource requests, making scheduling and capacity planning unreliable.
• Changing a Deployment manually while GitOps immediately restores the Git version.
• Assuming rollback also reverses a database migration.
• Using maxUnavailable values that reduce capacity too aggressively.

Best practices#

• Use Deployments for stateless applications; do not normally manage ReplicaSets yourself.
• Use immutable version tags or image digests.
• Configure readiness, liveness and startup probes appropriately.
• Define CPU and memory requests and limits.
• Use PodDisruptionBudgets and topology spread rules for important multi-replica services.
• Monitor rollout status in CI/CD and fail the pipeline when the rollout does not complete.
• Keep manifests in source control and review changes through pull or merge requests.
• Test rollback procedures before an actual incident.

Quick practice lab#

1. Create the Deployment with three nginx Pods.
2. Delete one Pod and watch the ReplicaSet recreate it.
3. Scale the Deployment to five replicas.
4. Update nginx to a newer fixed version.
5. Watch both ReplicaSets during the rolling update.
6. Roll back to the previous revision.
7. Break the image name intentionally and use events and rollout status to diagnose it.

kubectl get deploy,rs,pods -l app=nginx kubectl delete pod kubectl scale deploy nginx-deployment --replicas=5 kubectl set image deploy/nginx-deployment nginx=nginx:1.28.0 kubectl rollout status deploy/nginx-deployment kubectl rollout undo deploy/nginx-deployment

Frequently asked questions#

Does a Deployment directly create Pods?#

Conceptually, the Deployment controls the application, but it creates and manages a ReplicaSet, and the ReplicaSet creates the Pods.

Should I edit a ReplicaSet created by a Deployment?#

No. Update the Deployment. Direct ReplicaSet changes may be overwritten by the Deployment controller and make the desired state confusing.

Does scaling create a new rollout revision?#

Changing only the replica count does not change the Pod template. A new rollout occurs when fields inside spec.template change.

Can a Deployment manage stateful applications?#

It can run them, but StatefulSets are generally more suitable when Pods need stable identities, ordered rollout or persistent per-Pod storage.

Why are old ReplicaSets still visible?#

Deployments retain previous ReplicaSets for revision history and rollback. They normally remain scaled to zero.

Conclusion#

A ReplicaSet keeps the requested number of Pods running. A Deployment sits above ReplicaSets and adds safe releases, rolling updates, revision history and rollback. In everyday Kubernetes work, you usually create a Deployment and let Kubernetes manage its ReplicaSets automatically.

Related Melochip guides#

• Kubernetes Learning Path
• Kubernetes Pods Explained
• kubectl Commands Explained
• Kubernetes Architecture Explained
• Docker Registry Explained

Official references#

• Kubernetes Deployments documentation
• Kubernetes ReplicaSet documentation
• Run a stateless application using a Deployment