Terraform-provider-kubernetes: kubernetes_job

[mahmoudian1]

Hi team,

Currently, terraform kubernetes provider support 'kubernetes_pod' but it doesn't support kubernetes_job. It would be nice to have kubernetes_job as well.

thanks.

[radeksimko]

Hi @mahmoudian1
I'm curious what benefits are you hoping to get from managing K8S jobs via Terraform? As far as I understand jobs are one-off containers that are gone once they return an exit code, which is likely a workload better suited for a different tool (to Terraform) which isn't stateful?

[sl1pm4t]

@radeksimko - I've also got some potential use cases for the job resource with Terraform. Like running a schema upgrade before updating a workload.
I'd say the main argument for adding to Terraform is so people have a consistent interface / configuration format for Kubernetes.

[mahmoudian1]

@radeksimko I agree with @sl1pm4t, the job has it's own use case within terraform. Job will be used for running the batch job that runs and end. It would be nice to use terraform for provisioning pod and jobs in the same automation pipeline, instead of using different tool just to achieve runing jobs on Kubernetes.

[radeksimko]

I don't have strong objections against adding it as long as it doesn't disappear from the API after finishing.

In other words as long as K8S keeps track of the job (even if it's in "completed/finished" state) then it's 👌 . We certainly don't want Terraform to be (ab)used as a scheduler, but rather a proxy to a scheduler. See more explanation I provided for a counter-example in the Packet provider: https://github.com/terraform-providers/terraform-provider-packet/pull/27#issuecomment-332204610

I don't know for sure how it behaves as I didn't check the API yet, but if anyone's fancy raising a PR this is the first question I'd like to be answered 😉

[sl1pm4t]

I found an implementation of the kubernetes_job resource in one of the provider forks a few weeks back.
I've merged it into my fork, but haven't got around to testing it yet.
Once I've tested it, I'll submit a PR.

[paurullan]

The main interest in having jobs is that after that is straight forward having cron jobs:
https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

Having cron jobs in terraform is desirable because it will help to keep track of your full deploy architecture.

[mo-mughrabi]

+1

[hairmare]

@sl1pm4t Did you get around to testing the resource? I have some use cases where I need jobs (and later on cronjobs) and I'd rather not do any duplicate work.

[sl1pm4t]

@hairmare - Yes I've used it (and CronJobs) a number of times on our production infra.

[AndyMoore]

any chance of getting kubernetes_job into this provider? happy to do some testing (via the @sl1pm4t fork) if that'd help bring this forward

[alexsomesan]

@AndyMoore We definitely want to have kubernetes_job supported. At the moment, all the efforts go into making sure the provider adapts well to Terraform 0.12. So it will take until after 0.12 to have jobs supported.
We do however appreciate PRs, if you want to take a stab at it.

[AndyMoore]

i think @sl1pm4t has done the hard work already (https://github.com/sl1pm4t/terraform-provider-kubernetes/blob/custom/kubernetes/resource_kubernetes_job.go) and has been working to get his changes merged back into here - just wondering if I can help push this forward more than anything

[BrendanThompson]

Yeah I would be really keen to have this merged into the Provider. Having to use template_file is a bit sucky!

[directionless]

You asked about use cases... Some of the data I work with has an initial data load, and followup cronjobs for refreshes. The nature of that does does not lend the initial load to the subsequent updates. eg, my infra provisioning looks like:

1. create database
2. Install server / container / deployment / whatever
3. Run initial batch load
4. cronjob subsequent updates

The kubernetes job resource is an ideal fit for (3) here

[BrendanThompson]

This is basically my exact use case also!

1. mar. 2019 kl. 13:13 skrev seph <[email protected][e-mail]>:

You asked about use cases... Some of the data I work with has an initial data load, and followup cronjobs for refreshes. The nature of that does does not lend the initial load to the subsequent updates. eg, my infra provisioning looks like:

1. create database
2. Install server / container / deployment / whatever
3. Run initial batch load
4. cronjob subsequent updates

The kubernetes job resource is an ideal fit for (3) here

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/terraform-providers/terraform-provider-kubernetes/issues/86#issuecomment-477417260, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACebgJwu7xg1Tf21fbIyHn9_DdjidlF6ks5vbCVGgaJpZM4QW7FA.

[Fleuri]

Funny to stumble upon this thread with the exact use case as the two previous posters.

To add, if I clone an environment I have a separate storage bucket from which my Job retrieves a latest sql dump and initializes a clone database with it, provided the database is empty.

Of course I could just make the job a pod and change it's 'count' variable to 0 on subsequent runs but that is hardly ideal.

[prein]

Wouldn't the problems (and applications) described in this issue apply to kubernetes_pod with restart_policy set to "Never" as well?