Managing Kubernetes Job with Helm

Kubernetes Job is a workload resource which is created to run a specific type of workload that will exit after a task is completed. A Job keeps track of completion of tasks based on exit code. For example, you want to have a database backup and expect it to complete after the backup is done and stored in some archive. Also, if the backup script fails, we might want some alerting mechanism and also might prefer a few retries if the first few attempts fail. That’s where Kubernetes Job helps.

For Quick Jumpers, a sample of Helm Chart for running K8s job is in this repo.

Sample K8s Job

Above is a sample Job definition which after applying will output the public IP address. After the completion, the job will be marked as “Completed” from “Running” state.

The example is a simple Job but in the real world a pod run by a job might need additional details like, environment variables, resource allocation, security policy, secret to pull image etc. Also, rather than applying the job with kubectl, using helm will make it much simpler in terms of making the definition modular which can be re-used for multiple environments.

The Chart is on this repo in github. Here, I have created a template file job.yaml with following definition:

The Chart installation is simple with

helm install $NAME $PATH -n $NAMESPACE

Give the installation a name and namespace where the chart should be installed.

It will create a new pod with name adding 5 digit random alpha numeric character like helm-job-fwfat-r4rd2 . If we want to run the job again, we can just run upgrade command:

helm install $NAME $PATH -n $NAMESPACE

This will initiate the job again with a specified image. In the example I am using a docker image which runs CURL to give a URL passed through command argument.

Additionally, configmap vars and secrets can be added from the template which will be injected to the pod run by job.

Why Not CronJob

As you can see, the Job is intended to run for once or at intended time which needs to be triggered manually. If we need the Job to run at an interval, we need to have a CI/CD pipeline or some schedule set. There is another native solution for this on Kubernetes called as CronJob. CronJob runs a job periodically on a given schedule, written in Cron format like, */1 * * * * .

Let’s say if you want to keep backup of database every day or generate SSL certificate every month or cleanup archive on weekly basis. Once CronJob is installed, we don’t need to bother about running.

But there are benefits of Job over CronJob:

• Parallelism and Completions: Let’s say we want to do some task five times but one by one after completion of each Job. This will run the Job 5 times spinning up 5 pods one after another.