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.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Jobs and CronJobs.

If you’ve worked with Kubernetes before, you’re probably familiar with Deployments — resources that keep pods running continuously. But what about tasks that just need to run once and finish? That’s where Jobs and CronJobs come in, and they’re incredibly useful for batch work like database migrations, backups, and scheduled reporting.

Let’s start with Jobs. A Job in Kubernetes runs one or more pods and keeps going until a specified number of them complete successfully. Think of it like telling Kubernetes: run this task, and don’t stop until it’s done. If a pod fails partway through, Kubernetes will try again.

The first code example shows a Job definition written in YAML. It defines a Job called “db-migration” running in the nzrt-prod namespace. Inside, it sets up a container called “migrate” using an application image, and it runs a PHP Artisan migrate command — so this is a database migration job. Two important settings here: the restart policy is set to “on failure”, meaning if the container crashes, Kubernetes will restart it rather than just giving up. And the backoff limit is set to three, which means Kubernetes will retry the job up to three times before marking it as failed.

The second code example shows three commands you’d use to work with that job from the command line. The first lists all jobs in the nzrt-prod namespace so you can see their status. The second pulls the logs from the db-migration job so you can check what actually happened during the run. And the third deletes the job once you’re done with it — important to keep things tidy, since completed jobs don’t clean themselves up automatically.

Now let’s move on to CronJobs. A CronJob is simply a Job that runs on a schedule. It wraps a Job definition inside a schedule expression, the same kind you’d use in a Linux crontab. If you’ve ever set up a scheduled task on a Linux server, this will feel very familiar.

The third code example shows a CronJob called “nzrt-backup” — again in the nzrt-prod namespace. The schedule field uses a cron expression that means “run at two in the morning, every day”. Inside, it defines a job template that runs a container using a backup tool image, executing a shell script called backup.sh. The restart policy is again set to “on failure”. There are also two history settings worth noting: successful jobs history is kept for three runs, and failed jobs history is kept for just one. This controls how many completed and failed job records Kubernetes retains, so you can look back and see what happened without cluttering the cluster with old records.

The fourth code example shows how you interact with CronJobs from the command line. The first command lists all CronJobs in the namespace. The second gives you a detailed description of the nzrt-backup CronJob — useful for checking the schedule, last run time, and any issues. The third command is particularly handy: it lets you manually trigger a CronJob right now without waiting for the schedule. You create a job “from” the CronJob definition, give it a name like “manual-backup”, and it runs immediately. This is great for testing or for running an out-of-schedule backup when you need one.

So to pull it all together — Jobs are your go-to when you need Kubernetes to run a task to completion, like a migration or a one-off data process. CronJobs wrap that same concept in a schedule so the work happens automatically and repeatedly. Both support retry logic through the restart policy and backoff limit, and CronJobs give you that manual trigger option when you need to run something on demand.

If you want to dig deeper, the related topics in the wiki cover Deployments and ReplicaSets for long-running services, and Monitoring Overview for keeping an eye on how your Jobs are performing.

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