Welcome to the NZRT Wiki Podcast. Today we’re looking at Deployments & ReplicaSets.

Let’s start with the big picture. In Kubernetes, a Deployment is the object you use to manage your applications. But it doesn’t directly manage pods — it does so through something called a ReplicaSet. Think of it as a chain of command. Your Deployment sits at the top, and underneath it creates a ReplicaSet. That ReplicaSet is what actually ensures the right number of pod replicas are running at any given time.

When you update a Deployment, Kubernetes creates a new ReplicaSet to represent the new version of your application. The structure looks something like this: at the top you have your Deployment. Below that, you have your current ReplicaSet, which holds all your running pods. And separately, you also have your previous ReplicaSet — still there, not actively running pods, but kept around so that if something goes wrong, you can roll back to it.

This is an important point. You should never manage ReplicaSets directly. Always go through the Deployment. Kubernetes keeps those old ReplicaSets around for rollback history, and how many are kept is controlled by a setting called revision history limit. If you start manually changing ReplicaSets, you risk breaking that rollback chain.

Now let’s talk about how Deployments handle updates. There are two strategies available to you.

The first is called Rolling Update, and it’s the default. With a rolling update, Kubernetes gradually replaces your old pods with new ones. It doesn’t take everything down at once — it brings new pods up while slowly removing the old ones, so your application stays available throughout the process. Two parameters fine-tune this behaviour. The first is max unavailable, which sets the maximum number of pods that can be offline during the update — by default, twenty-five percent of your total pod count. The second is max surge, which controls how many extra pods can be created above your desired count during the update — also twenty-five percent by default. Together these give you a smooth, controlled rollout.

The second strategy is called Recreate. This one is much more direct. Kubernetes terminates all your existing pods first, and only then starts creating the new ones. That means there will be a period of downtime. You’d use this if your application can’t safely run two versions simultaneously — for example, if it has strict database migration requirements that would break under a mixed-version environment.

Now let’s cover scaling. You have two options: manual and automatic.

For manual scaling, you issue a command that tells Kubernetes to set the replica count for your deployment to a specific number. As a concrete example, you could scale your wordpress deployment in the nzrt-prod namespace to three replicas with a single terminal command.

For automatic scaling, you use something called a Horizontal Pod Autoscaler, or HPA. This watches a metric — typically CPU usage — and adds or removes pods automatically to keep that metric within a target range. You can set this up from the command line by specifying the deployment you want to target, a minimum and maximum replica count, and the CPU utilisation percentage that should trigger scaling. For the wordpress deployment, for example, you might say: keep at least two replicas, scale up to a maximum of five, and aim to stay at or below seventy percent CPU.

You can also define the HPA as a configuration manifest — a structured file that describes the same settings. That file would name the autoscaler, point it at your wordpress deployment, set the replica boundaries, and define the CPU metric target. Storing your HPA as a file is useful because you can check it into version control and apply it consistently across environments.

To check what your autoscaler is currently doing, you can run a command that lists all HPAs in a given namespace. That gives you a live view of current versus desired replica counts and what the resource utilisation looks like right now.

One final thing worth noting — Deployments aren’t the right tool for every workload. If you’re running stateful applications like databases, you’ll want to look at StatefulSets instead. StatefulSets give each pod a stable identity and persistent storage, which is something that ReplicaSet-backed Deployments simply don’t provide.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.