How to run containers sequentially as a Kubernetes job?

After a few attempts, I did this and that solved the basic problem (similar to what the OP has posted). This configuration ensures that job-1 completes before job-2 begins. If job-1 fails, job-2 container is not started. I still need to work on the retries and failure handling, but the basics works. Hopefully, this will help others:

apiVersion: v1kind: Podmetadata:  name: sequential-jobspec:  initContainers:  - name: job-1    image: busybox    # runs for 15 seconds; echoes job name and timestamp    command: ['sh', '-c', 'for i in 1 2 3; do echo "job-1 `date`" && sleep 5s; done;']  - name: job-2    image: busybox    # runs for 15 seconds; echoes job name and timestamp    command: ['sh', '-c', 'for i in 1 2 3; do echo "job-2 `date`" && sleep 5s; done;']  # I don't really need the 'containers', but syntax requires   # it so, I'm using it as a place where I can report the   # completion status  containers:  - name: job-done    image: busybox    command: ['sh', '-c', 'echo "job-1 and job-2 completed"']  restartPolicy: Never

Update

The same configuration as above also works inside a Job spec:

apiVersion: batch/v1kind: Jobmetadata:  name: sequential-jobsspec:  template:    metadata:      name: sequential-job    spec:      initContainers:      - name: job-1        image: busybox        command: ['sh', '-c', 'for i in 1 2 3; do echo "job-1 `date`" && sleep 5s; done;']      - name: job-2        image: busybox        command: ['sh', '-c', 'for i in 1 2 3; do echo "job-2 `date`" && sleep 5s; done;']      containers:      - name: job-done        image: busybox        command: ['sh', '-c', 'echo "job-1 and job-2 completed"']      restartPolicy: Never

Argo workflow will fit for your usecase. Argo will support sequential, parallel, DAG job processing.

# This template demonstrates a steps template and how to control sequential vs. parallel steps.# In this example, the hello1 completes before the hello2a, and hello2b steps, which run in parallel.apiVersion: argoproj.io/v1alpha1kind: Workflowmetadata:  generateName: steps-spec:  entrypoint: hello-hello-hello  templates:  - name: hello-hello-hello    steps:    - - name: hello1        template: whalesay        arguments:          parameters: [{name: message, value: "hello1"}]    - - name: hello2a        template: whalesay        arguments:          parameters: [{name: message, value: "hello2a"}]      - name: hello2b        template: whalesay        arguments:          parameters: [{name: message, value: "hello2b"}]  - name: whalesay    inputs:      parameters:      - name: message    container:      image: docker/whalesay      command: [cowsay]      args: ["{{inputs.parameters.message}}"]

Broadly, there is no notion of sequence and capturing dependencies across containers/pods in a Kubernetes setup.

In your case, if you have 2 containers in a job spec (or a pod spec even), there is no sequencing for those 2 containers. Similarly, if you fire 2 jobs one after another there is no notion of sequencing for those jobs either.

Ideally, if anything requires sequencing you should capture it within a single unit (container).

Slightly tangential to your question, another common pattern that I've seen when a Job is dependent on another service existing (say a deployment fronted by a k8s service):

The container in the job makes an request to the k8s service and fails if the service does not respond as expected. That way the Job keeps restarting and eventually when the service is up, the job executes and completes successfully.