Как последовательно запускать контейнеры как задание Kubernetes?

Ответ 1

После нескольких попыток я сделал это и решил основную проблему (похожую на то, что опубликовал ОП). Эта конфигурация обеспечивает завершение job-1 до начала job-2. Если сбой job-1 job-2 контейнер job-2 не запускается. Мне все еще нужно работать над повторениями и обработкой отказа, но основы работают. Надеюсь, это поможет другим:

apiVersion: v1
kind: Pod
metadata:
  name: sequential-job
spec:
  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

Обновить

Та же конфигурация, что и выше, также работает внутри спецификации Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: sequential-jobs
spec:
  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

Ответ 2

В широком смысле нет понятия последовательности и захвата зависимостей между контейнерами/контейнерами в настройке Kubernetes.

В вашем случае, если у вас есть 2 контейнера в спецификации задания (или даже спецификации пакета), для этих 2 контейнеров нет последовательности. Точно так же, если вы запускаете 2 задания один за другим, нет никакого понятия о последовательности для этих заданий.

В идеале, если что-то требует последовательности, вы должны захватить его в одном устройстве (контейнере).

Чуть тангенциальный к вашему вопросу, еще один общий шаблон, который я видел, когда работа зависит от другой существующей службы (скажем, развертывание с помощью службы k8s):

Контейнер в задании делает запрос к службе k8s и терпит неудачу, если служба не отвечает так, как ожидалось. Таким образом, Job продолжает перезагрузку и, в конце концов, когда служба завершается, задание выполняется и завершается успешно.

Ответ 3

Вы смотрели бригаду - https://brigade.sh. Скрипт простых и сложных рабочих процессов с использованием JavaScript. Соединяйте контейнеры, запуская их параллельно или последовательно. Пожарные сценарии, основанные на времени, события GitHub, Docker push или любой другой триггер. Бригада - это инструмент для создания трубопроводов для Кубернетов.

Ответ 4

Рабочий процесс Argo подойдет для вашего случая использования. Argo будет поддерживать последовательную, параллельную обработку заданий DAG.

# 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/v1alpha1
kind: Workflow
metadata:
  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}}"]

Ответ 5

Просто наткнулся на это. Как указывалось выше, насколько я знаю, в Kubernetes отсутствует понятие рабочих зависимостей, но я работал с коммерческой организацией (Univa), у которой есть надстройка, которая предоставляет эти (и другие) возможности.

Предложение называется Navops Command и позволяет аннотировать задания Kubernetes с помощью простой записи зависимостей. Здесь есть блог с кратким объяснением и примером здесь. По сути, Navops устанавливается как набор контейнеров в Kubernetes, предоставляет собственный интерфейс пользователя и интерфейс командной строки и дополняет планировщик Kubernetes дополнительными возможностями. Вы можете скачать его на http://navops.io.

Технология основана на планировщике Grid Engine, используемом в HPC, где распространены сложные рабочие процессы, задания массивов и тому подобное.