Right, so your Deployment is up and running. You’ve run kubectl get deployments and it proudly reports 3/3 pods are available. Fantastic. You high-five the intern and call it a day. But what if I told you that “Available” is a filthy, rotten liar? Well, maybe not a liar, but it’s certainly not telling you the whole story. It’s the highlight reel, not the grueling practice session where things actually go wrong.
Right, so you’ve got your Pods running. They’re beautiful, they’re perfect, and they’re currently a single point of failure. You and I both know that’s not going to fly. This is where we graduate from just keeping things alive to actually managing how many of them are alive. We’re going to talk about scaling, and we’ll do it in two ways: the way you tell it what to do (manual), and the way it figures things out for itself (with the Horizontal Pod Autoscaler, or HPA). This is where your deployment starts to feel like a real, robust system instead of a fancy demo.
Right, so you’ve done it. You’ve issued a kubectl apply -f deployment.yaml with the serene confidence of a master engineer, only to watch your application immediately catch fire and start screaming in a language you don’t understand. The new container image you just deployed is a complete dud. Maybe it’s a bug. Maybe you forgot to build the binary. Maybe it’s Maybelline. It doesn’t matter. What matters is that you need to get back to the last known good state, and you need to do it now. This is where kubectl rollout undo earns its place in the hall of fame of indispensable commands.
Right, so you’ve told your Deployment to roll out a new version of your app. It’s happily chugging along, Pod by Pod, and then… oh. You just remembered the new container image you told it to use has a nasty bug in its health check endpoint. The rollout is actively deploying broken software. Your stomach sinks. Do you panic? No. You do the smart thing: you hit the pause button.
Alright, let’s talk about the Recreate strategy. You’re going to use this when you absolutely, positively cannot have two versions of your application running at the same time. Think of it as the “scorched earth” or “turn it off and on again” method of deployment. It’s brutally simple: we completely terminate all the old Pods first. Only after they’re all dead and gone do we spin up the new ones.
Right, so you’ve got your app deployed, it’s running smoothly, and now you need to push a new version. You’re not going to just kubectl delete --all and pray, are you? Of course not. You’re going to do a rolling update, the civilized way to upgrade your software without causing a full-blown production incident (or at least, a smaller, more manageable one). The magic—and the control—of a rolling update is managed by two knobs in your Deployment spec: maxSurge and maxUnavailable. These two parameters are the yin and yang of your update strategy, controlling the trade-off between speed and availability. They’re the reason your users don’t get a 502 Bad Gateway error while you’re deploying.
Right, so you’ve got your app running in a Pod. It’s a beautiful thing. But Pods are mortal; they get sick, they die, they get scheduled onto different nodes. You can’t just kubectl create pod and call it a day. You need a ReplicaSet to keep a desired number of clones running. But even that’s not enough. What happens when you need to update your app from my-app:v1.0 to my-app:v1.1? With a ReplicaSet, your strategy is basically to turn everything off and then turn everything back on again. That’s not an update, that’s an outage. Enter the Deployment. This is where we stop being cowboys and start being engineers.
Right, so you’ve got a Pod. It’s running your app. It’s beautiful. And then, it dies. A node explodes, a config error causes a crash loop, you get a frantic call at 3 AM—you know, the usual. Your single Pod was a single point of failure, and it failed. Spectacularly. This is why we don’t just run Pods. We run ReplicaSets. Think of a ReplicaSet as your application’s overly anxious, but brilliant, stage manager. Its entire job is to constantly look at the stage, count the actors (Pods), and if the number doesn’t match the script, it frantically hires new ones or fires extras. It maintains a stable set of Pod replicas. That’s the whole show. It ensures that a specified number of identical Pods are running at any given time. It’s the bedrock of reliability in Kubernetes, and it’s almost criminally simple to use.