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.