Назад | Перейти на главную страницу

Поддерживает ли Kubernetes внутреннюю очередь задач?

Мы находимся в стадии разработки. Мы используем кластер Kubernetes, состоящий из главного и подчиненного экземпляров EC2. Мы отправляем задачи в кластер Kubernetes с помощью Kubernetes_Pod_Operator из Airflow. Мы стремимся масштабировать этот процесс. Итак, мы собираемся использовать Celeryexecutor из Airflow, который используется для одновременной отправки и планирования задач в Airflow.

Итак, вопрос в том, должны ли мы заботиться о количестве задач, отправленных в Kubernetes, или, независимо от количества задач, отправленных в Kubernetes, Kubernetes будет обслуживать все задачи без сбоев из-за какой-либо внутренней очереди?

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

Исходный код «kubernetes_pod_operator.py» показывает, что он просто создает контейнер в правильном пространстве имен, с правильным изображением и т. Д.

В конце концов, это модуль, поэтому он выполнит свою работу и завершит работу (статус: выполнено).

Принимая это во внимание, это будет зависеть от заданий, которые ему придется выполнять, и от типа вашего компьютера. Пример:

Допустим, вы запускаете простые конвейеры, которые потребляют около 0,1 ЦП и несколько МБ памяти. Если ваши узлы являются машинами с 4 процессорами (допустим, у вас достаточно памяти), вы можете запускать ~ 40 одновременных заданий на узел. Если вы запустите больше, вы получите сообщение об ошибке (о том, что ваши поды не могут быть запланированы).

Так,

  • (рекомендуется) Если вы действительно можете определить стандартное потребление ресурсов для каждой задачи (для каждого модуля), я бы рекомендовал вам установить запросы ресурсов и ограничения на поды (по умолчанию под может потреблять 100% ресурсов узлов) и всегда стараться запустить максимальное количество подов. Вам нужно будет отслеживать количество стручков.
  • (не рекомендуется). Если вы не можете определить потребление модуля, вы можете либо контролировать узлы и добавлять задачи, пока в них достаточно места, либо попробовать создать модули с экспоненциальным откатом, если вы получите ошибку на модуле. создание, потому что его нельзя запланировать.

Надеюсь, поможет. Опять же, это не то, что я привык видеть на кубернетах.