Каковы некоторые рекомендации по развертыванию нескольких контейнеров со связанными переменными среды?

Question

Я пытаюсь развернуть распараллеленную задачу обработки данных, которая использует множество контейнеров с одним и тем же образом докера, каждый из которых будет запускаться с разными инкрементными переменными среды. Изображение настроено для чтения переменных env, чтобы определить, какой сегмент большего списка обрабатывать.

Справочная информация: Первоначально я использовал сценарий bash, который передавал инкремент env var для запуска команд docker, но теперь я хотел бы улучшить способ управления / мониторинга всех контейнеров. У меня был только опыт использования Kubernetes для сервисов приложений, но, похоже, это может быть и лучшим способом для организации моей работы с несколькими контейнерами.

Интересно, возможна ли такая передача динамических переменных среды в конфигах YAML Kubernetes, так как я бы предпочел декларативную конфигурацию вместо сценария оболочки. Я также не уверен в наилучшем подходе для этого в Кубернетесе, будь то несколько отдельных модулей, несколько контейнеров или использование каким-либо образом реплик.

Я открыт для предложений, я знаю, что другие инструменты, такие как Terraform, могут быть полезны и для такого рода программной инфраструктуры.

Answer 1

Как насчет использования Параллельная обработка с использованием рабочей очереди для передачи различных переменных среды в ваши рабочие модули k8s с помощью .spec.parallelism.Хотя наличие отдельного сервиса для рабочей очереди может быть немного слишком большим, в зависимости от того, что вы пытаетесь сделать.

Другая идея может заключаться в использовании мощности шаблонов helm для создания файла манифеста k8s.Я создаю образец диаграммы руля, чтобы дать представление о шаблонной параллельной обработке.Смотрите git repo - helm-parallel-jobs .После того, как вы клонировали репозиторий git, вы можете установить график рулевого управления для параллельной обработки следующим образом.Шаблон для работы такой же, как в документации k8s .Как видно из выходных данных ниже, предоставляются три разные переменные среды - яблоко, банан, вишня, которые создают 3 разных модуля с передаваемыми им переменными среды.

    [root@jr]# helm install --set envs='{apple,banana,cherry}'  --name jobs ./helm-parallel-jobs/example/parallel-jobs
    NAME:   jobs
    LAST DEPLOYED: Sun Aug 26 16:29:23 2018
    NAMESPACE: default
    STATUS: DEPLOYED

    RESOURCES:
    ==> v1/Job
    NAME                 DESIRED  SUCCESSFUL  AGE
    process-item-apple   1        0           0s
    process-item-banana  1        0           0s
    process-item-cherry  1        0           0s

    ==> v1/Pod(related)
    NAME                       READY  STATUS             RESTARTS  AGE
    process-item-apple-dr6st   0/1    ContainerCreating  0         0s
    process-item-banana-d2wwq  0/1    ContainerCreating  0         0s
    process-item-cherry-wvlxz  0/1    ContainerCreating  0         0s

Answer 2

Насколько я понимаю, вы хотели бы сделать что-то вроде https://kubernetes.io/docs/tasks/job/parallel-processing-expansion/, где задания создаются из шаблона, по одному для каждого элемента данных в списке. Но вы не хотите, чтобы это было написано в оболочке.

Я полагаю, что helm можно использовать для замены Job, и у него есть функция range, поэтому можно настроить диаграмму для создания заданий для каждой записи в разделе values.yaml. Таким образом, он может занимать пространство, подобное тому, что вы предложили для terraform. Ansible также может быть вариантом.

Однако направление этого вопроса, по-видимому, направлено на планирование партии. Мне интересно, будут ли ваши рабочие места развиваться и в конечном итоге возникнут зависимости между ними и т. Д. Если это так Хелм и Кубернетес: существует ли барьерный эквивалент для рабочих мест? и https://www.quora.com/Is-Kubernetes-suited-for-long-running-batch-jobs помощь здесь. В настоящее время в Kubernetes есть средства для запуска пакетных заданий и инструментарий, позволяющий запускать или строить систему пакетного планирования, но сама она не содержит встроенной системы пакетного планирования. Поэтому люди в настоящее время используют ряд различных подходов для удовлетворения своих потребностей.