K
Q

How to pass arguments to a Job resource in Kubernetes

4/3/2018

I have a file for a Job resource, which looks something like below.I need to run multiple instances with this definition with separate arguments for each.

apiVersion: batch/v1
kind: Job
metadata:
  generateName: abc-
spec:
  template:
    spec:
      containers:
      - name: abc
        image: index.docker.io/some/image:latest
        imagePullPolicy: Always
      imagePullSecrets:
      - name: some_secret
      restartPolicy: Never
  backoffLimit: 4

I can successfully run this job resource with kubectl create -f my-job.yml But, I'm not sure how I pass my arguments corresponding to command:['arg1','arg2']

I think updating the file with my dynamic args for each request is just messy.

I tried kubectl patch -f my-job.yml --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/", "value": {"command": ["arg1","arg2"] } }]', which works well for a Deployment kind but for Job it doesn't work

I tried sudo kubectl run explicitly-provide-name-which-i-dont-want-to --image=index.docker.io/some/image:latest --restart=Never -- arg1 arg2, but for this I won't be able to pass the imagePullSecrets.

-- sykik
kubernetes

Similar Questions

kubelet: W0403 conversion.go:110 Could not get instant cpu stats: different number of cpus
Jenkins Kubernetes plugin failing to provision jnlp-slave pods
How to connect nginx frontend to aspnetcore backend on k8s?
Kubernetes service unreachable from master node on EC2

2 Answers

4/3/2018

I would also consider sourcing the command arguments from environment variables. These variables are then provided by helm as javapapo has mentioned.

-- Bal Chua
Source: StackOverflow
4/3/2018

kind of a generic answer here, just trying to guide you. In general what you express is the need to 'parameterize' your kubernetes deployment descriptors. There are different ways some are simple, some others are a bit hacky and finally there is github.com/kubernetes/helm.

Personally I would strongly suggest you go through installing Helm on your cluster and then 'migrate' your job or any vanilla kubernetes deployment descriptor into a helm Chart. This will eventually give you the 'parameterization' power that you need to spin jobs in different ways and with different configs.

But, if this sounds like too much for you, I can recommend something that I was doing before I discover Helm. Using things like 'bash' / 'envsubst' I was eventually - templating manually the parts of the yaml file, with place holders (e.g env variables) and then I was feedind the yaml to tools like 'envsubst' where they were replacing the placeholders with the values from the environment. Ugly? Yes. Maintenable? maybe for a couple of simple examples. Example of envsubst here.

apiVersion: batch/v1
kind: Job
metadata:
spec:
  template:
    spec:
      containers:
      - name: abc
        image: index.docker.io/some/image:latest
        imagePullPolicy: Always
      imagePullSecrets:
      - name: $SOME_ENV_VALUE
      restartPolicy: Never
  backoffLimit: 4

Hope that helps..but seriously if you have time, consider checking 'Helm'.

-- javapapo
Source: StackOverflow