Кубернетес и MPI

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

Один начальный вопрос: кто-нибудь имел успех в выполнении заданий MPI на кластере кубов? Я видел, что Христианский Kniep's работает над тем, чтобы задания MPI выполнялись в контейнерах докеров, но он шел по пути докеры-рой (с открытием сверстников с использованием консула работает в каждом контейнере), и я хочу придерживаться кубернетов (которые уже знают информацию всех сверстников) и вводить эту информацию в контейнер снаружи. У меня есть полный контроль над всеми частями приложения, например. Я могу выбрать, какую реализацию MPI использовать.

У меня есть пара идей о том, как действовать:

  • жировые контейнеры, содержащие slurm и код приложения → населяют slurm.conf с соответствующей информацией о сверстниках в контейнере startup → использовать srun в качестве точки входа контейнера для запуска заданий

  • более тонкие контейнеры с OpenMPI (без slurm) → заполняют rankfile в контейнере с информацией извне (предоставляется kubernetes) → использовать mpirun в качестве точки входа в контейнер

  • даже более тонкий подход, где я в основном "подделываю" время выполнения MPI установка нескольких переменных среды (например, OpenMPI ORTE) → запустите двоичный файл mpicc'd напрямую (где он узнает о своих сверстниках через env vars)

  • некоторая другая опция

  • отказаться от отчаяния

Я знаю, что пытаюсь смешивать "установленные" рабочие процессы, такие как MPI с "новой жаркой" кубернетов и контейнеров, является несоответствием импеданса, но я просто ищу указатели /gotchas, прежде чем идти слишком далеко вниз дорожка. Если ничего не существует, я рад взломать некоторые вещи и отбросить их назад.

Ответ 1

Предполагая, что вы не хотите использовать hw-специфическую библиотеку MPI (например, все, что использует прямой доступ к структуре связи), я бы пошел с опцией 2.

  • Сначала создайте оболочку для mpirun, которая заполняет необходимые данные с использованием API kubernetes, в частности с использованием конечных точек, если использовать услуга (может быть, хорошая идея), может также очистить pod подвергается портов.

  • Добавьте некоторую форму программы контрольной точки, которая может использоваться для синхронизация "рандеву" перед запуском фактического кода запуска (I не знаю, насколько хорошо MPI работает с эфемерными узлами). Это для убедитесь, что при запуске mpirun у него есть стабильный набор стручков для использования

  • И, наконец, на самом деле создадим контейнер с необходимым кодом, а я угадать SSH-сервис для mpirun для использования для запуска процессов в другие стручки.


Еще один интересный вариант - использовать Stateful Sets, возможно, даже работать с SLURM внутри, которые реализуют "виртуальный" кластер машин MPI, работающих на кубернетах.

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

Другим преимуществом является то, что он, вероятно, был бы наименее инвазивным для реального приложения.

Ответ 2

Я пробовал MPI Jobs на Kubernetes в течение нескольких дней и решил его с помощью dnsPolicy:None и dnsConfig (CustomDNS=true), который будет необходим.)

Я нажал свои манифесты (как график Хелма) здесь.

https://github.com/everpeace/kube-openmpi

Я надеюсь, что это поможет.