Deployments, ReplicaSets, and Scaling Applications

Let's start with the smallest piece: a Pod. A Pod is the smallest deployable unit in Kubernetes. It runs one or more containers (like a tiny virtual machine for your app) and shares a network and storage among them. But on its own, a Pod is fragile. If the node (the physical or virtual server) it runs on crashes, that Pod is gone forever. You would have to manually create a new one. That's no good if you are running a website that must stay up.

Enter the ReplicaSet. A ReplicaSet is a Kubernetes controller—a piece of software that constantly watches the cluster and acts to keep the world in a desired state. Its only job is to ensure that a specified number of identical Pod replicas are running at all times. If a Pod dies (because of a crash, a node failure, or a manual deletion), the ReplicaSet immediately creates a replacement Pod. If someone accidentally creates too many identical Pods, the ReplicaSet kills the extras. This gives you basic self-healing. For example, if you set 'replicas: 3' in a ReplicaSet definition, the controller always makes sure exactly three Pods are running.

But a ReplicaSet on its own has a limitation: how do you update the application version? If you want to change the container image from version 1.0 to 2.0, you could delete the old ReplicaSet and create a new one. That would kill all Pods at once, causing downtime. Alternatively, you could manually create a new ReplicaSet with the new image, then slowly delete Pods from the old one. That is tedious and error-prone. This is where a Deployment comes in.

A Deployment is a higher-level controller that manages ReplicaSets. You never create a ReplicaSet directly (though you could). Instead, you create a Deployment, and the Deployment creates and manages one or more ReplicaSets for you. The Deployment gives you two superpowers: rolling updates and rollbacks.

When you update the container image in your Deployment YAML (say from 'myapp:1.0' to 'myapp:2.0'), the Deployment automatically creates a new ReplicaSet with the new image. Then it gradually scales down the old ReplicaSet while scaling up the new one. By default, it does this in a controlled way: it creates a new Pod, waits for it to become healthy, then destroys one old Pod, then creates another new one, and so on. This is called a rolling update. Your users never see a full outage—the old version handles traffic until the new version starts responding.

If something goes wrong with version 2.0 (maybe a bug causes errors), you can tell the Deployment to rollback. It immediately reverses the process: scales down the new ReplicaSet and scales up the old one, restoring the previous version. The Deployment keeps a history of revisions, so you can roll back to any previous state, not just the last one.

Scaling is the third piece. Scaling means changing the number of Pod replicas. You can scale two ways: manually (by editing the Deployment's 'replicas' field) or automatically (using a HorizontalPodAutoscaler, which we will cover later). When you scale up, the Deployment tells the current ReplicaSet to create more Pods. When you scale down, it tells the ReplicaSet to delete some Pods. The Deployment always maintains the desired number of replicas, even during updates.

Here is a concrete example. Imagine you run an online store. You have a Deployment called 'store-frontend' with 5 replicas running image 'store:v1'. You push a new feature and update the image to 'store:v2'. The Deployment creates a new ReplicaSet with 1 Pod of v2. When that Pod passes its health check, the Deployment reduces the old ReplicaSet to 4 Pods and increases the new one to 2 Pods. It continues this pattern until all 5 Pods are running v2. If v2 is broken, you run 'kubectl rollout undo deployment store-frontend', and the Deployment reverses the process.

Key terms to remember:

In the exam, you will mostly interact with Deployments. You will use 'kubectl create deployment', 'kubectl scale deployment', 'kubectl set image deployment', and 'kubectl rollout status/undo'. You will also need to understand how Deployments relate to ReplicaSets, because when you debug, you may need to look at ReplicaSets to understand why Pods are not starting. The key insight is: a Deployment is a declarative way to manage your application's lifecycle. You tell Kubernetes what you want (the desired state), and the controllers work to make it true.

Imagine you are a platform engineer at a company called 'QuickCart', an e-commerce platform that sells groceries online. You are responsible for deploying and scaling the 'order-service', which processes customer orders.

Your day might start like this: You open a terminal and run 'kubectl get deployments' to check the status of all running services. You see that 'order-service' has 3 replicas, all ready. But it's 8:55 AM, and you know that at 9 AM, a flash sale starts. Traffic is expected to triple. You need to scale up before the rush.

You run 'kubectl scale deployment order-service --replicas=10'. Behind the scenes, the Deployment finds the current ReplicaSet (which is managing the 3 Pods) and updates its 'replicas' field to 10. The ReplicaSet sees the desired count is now 10, so it creates 7 new Pods. Each new Pod goes through a readiness probe—a health check that tells the service when the Pod is actually ready to accept traffic. Once all 10 Pods are ready, they start receiving requests via a Service (a stable network endpoint).

After the flash sale ends at 10 AM, traffic drops. You scale back down: 'kubectl scale deployment order-service --replicas=3'. The ReplicaSet terminates 7 Pods gracefully, giving each a few seconds to finish any in-flight orders before shutting down. The service stays up the entire time.

Later that day, your development team releases version 2.0 of the order service with a new coupon feature. You update the image: 'kubectl set image deployment/order-service order-service=quickcart/order-service:v2.0 --record'. The '--record' flag saves the command in the rollout history for auditing. A rolling update begins. The Deployment creates a new ReplicaSet with 1 Pod of v2.0. After that Pod becomes ready, the old ReplicaSet is scaled down to 2 Pods, and the new one scaled up to 2. This continues until all 10 Pods (now the desired count) are running v2.0.

But something goes wrong: the new coupon feature has a bug that crashes the service under load. Users start seeing errors. You run 'kubectl rollout undo deployment order-service'. The Deployment immediately begins rolling back. It takes one minute to revert the update, and the service is restored to v1.0. You then investigate the bug, fix it, and redeploy later.

What tools and commands do you use day-to-day?

In larger organisations, you might not manually scale. Instead, you set up a HorizontalPodAutoscaler (HPA) that automatically scales based on CPU or memory usage. But the fundamental concept—Deployments manage ReplicaSets, and ReplicaSets maintain Pod counts—remains the same.