KubeRay в производстве: практические рекомендации «с полей»

Часть 2 нашей серии статей о KubeRay «с полей». Часть 1: Запуск Ray в масштабе на Kubernetes с помощью KubeRay рассказывает о том, что такое KubeRay, о его пользовательских ресурсах (custom resources) и о том, как развернуть ваш первый RayJob.

Первая часть завершилась на позитивной ноте: RayJob успешно перешел в состояние SUCCEEDED. Эта публикация продолжает тему и рассматривает изменения, которые происходят, когда одна задача превращается в сотни задач, распределенных по командам и кластерам. KubeRay отлично справляется с таким ростом: в публичном выступлении на Ray Summit 2024 было продемонстрировано масштабирование Ray Train до 10 000 узлов Kubernetes.

Если вы запускали Ray на Kubernetes в течение некоторого времени, этот момент вам наверняка знаком. Где-то после преодоления порога в несколько узлов и подключения второй команды сбой задачи на GPU перестает быть проблемой, решаемой быстрым вызовом kubectl logs. Кластер, в котором содержался ответ, возможно, уже удален, а графические процессоры, зарезервированные для повторного запуска, продолжают тарифицироваться, пока кто-то выясняет, в чем была проблема: в коде, данных или «железе».

Будучи инженером по внедрению, я провожу много времени с двумя типами команд: крупными предприятиями, встраивающими Ray в кластеры, созданные для других целей, и компаниями с изначально облачной архитектурой (digital natives), которые выводят Ray за привычные границы. Они обычно сталкиваются с одними и теми же сценариями, и именно они научили меня тому, какие практики работают на практике. Им и посвящена эта статья.

LinkОт быстрого старта к продакшену

Пример из первой части обучает модель Fashion MNIST на процессорах. Продакшен-задача RayJob использует тот же ресурс, но с четырьмя изменениями: запрашиваются GPU, задачи ставят в очередь в соответствии с квотами команд через Kueue, нагрузка удерживается вне главного узла (head node), а рабочие узлы (workers) масштабируются с нуля.

В таком масштабе функции из первой части начинают приносить больше пользы: узлы с GPU, совместно используемые между задачами, рабочие узлы, масштабируемые обратно до нуля, и квоты, обеспечивающие справедливое распределение между командами. Для одной команды на одном кластере этой спецификации зачастую оказывается вполне достаточно.

Однако обратите внимание на строку shutdownAfterJobFinishes: true. Она полезна для оптимизации затрат, и с нее же начинается первый производственный сценарий.

LinkПять производственных сценариев, к которым нужно подготовиться

Как только Ray становится общей инфраструктурой с большим количеством команд, кластеров и GPU, которые нельзя тратить впустую, в полевых условиях начинает проявляться одна и та же закономерность: настройки по умолчанию, хорошо работающие в малом масштабе, требуют пересмотра в условиях продакшена с его параллелизмом и конкуренцией за ресурсы. Это не проблемы самого KubeRay. Каждая из них лежит на стыке Ray, Kubernetes и организации, управляющей ими обеими.

• Данные для отладки привязаны к жизненному циклу кластера. Задание RayJob, которое очищает за собой ресурсы, также удаляет свою панель мониторинга (dashboard) Ray. Самый сложный случай — это драйвер, который завершает работу в первые же минуты: рабочие узлы с GPU поднимаются, не получают задач, и кластер уничтожается до того, как кто-либо успевает собрать логи драйвера. Из-за этого после инцидента практически не остается материалов для расследования.

Данные для отладки привязаны к жизненному циклу кластера. Задание RayJob, которое очищает за собой ресурсы, также удаляет свою панель мониторинга (dashboard) Ray. Самый сложный случай — это драйвер, который завершает работу в первые же минуты: рабочие узлы с GPU поднимаются, не получают задач, и кластер уничтожается до того, как кто-либо успевает собрать логи драйвера. Из-за этого после инцидента практически не остается материалов для расследования.

• Аппаратные сбои маскируются под ошибки приложения. Сбой PCIe или NVLink, либо зависшее монтирование NFS могут прервать процесс обучения, в то время как под все еще сообщает о статусе Ready. Ray продолжает планировать работу на этом узле, поэтому сбой проявляется как ошибка в приложении. Некоторые команды разработали модифицированный оператор и пользовательский ресурс для обнаружения сбоев оборудования.

Аппаратные сбои маскируются под ошибки приложения. Сбой PCIe или NVLink, либо зависшее монтирование NFS могут прервать процесс обучения, в то время как под все еще сообщает о статусе Ready. Ray продолжает планировать работу на этом узле, поэтому сбой проявляется как ошибка в приложении. Некоторые команды разработали модифицированный оператор и пользовательский ресурс для обнаружения сбоев оборудования.

• Настройки по умолчанию нуждаются в тюнинге при масштабировании. Когда 20 кластеров борются за один пул GPU, простаивающий воркер с GPU может быть удален в момент формирования группы размещения (placement group), и обучение не начнется. Параметр maxReplicas, заданный без какого-либо запаса (headroom), может привести к зависанию автоскейлера, когда Ray Train повторяет задачу, завершившуюся с ошибкой Out-Of-Memory. Каждая попытка повтора также может оставлять после себя группу размещения. Команды «в полях» сообщают о неделях платформенной инженерии, прежде чем надежность системы стабилизируется.

Настройки по умолчанию нуждаются в тюнинге при масштабировании. Когда 20 кластеров борются за один пул GPU, простаивающий воркер с GPU может быть удален в момент формирования группы размещения (placement group), и обучение не начнется. Параметр maxReplicas, заданный без какого-либо запаса (headroom), может привести к зависанию автоскейлера, когда Ray Train повторяет задачу, завершившуюся с ошибкой Out-Of-Memory. Каждая попытка повтора также может оставлять после себя группу размещения. Команды «в полях» сообщают о неделях платформенной инженерии, прежде чем надежность системы стабилизируется.

• Сбои главного узла (head node) затрагивают весь кластер. Вывод узлов из эксплуатации (drain) для обновления образов узлов и патчей безопасности может отключить узлы Ray, а нехватка памяти (memory pressure) может привести к выселению пода главного узла, как описывает инженерная команда Klaviyo по итогам года эксплуатации Ray Serve на KubeRay. Без отказоустойчивости GCS (GCS fault tolerance) падает весь кластер. При ее наличии воркеры продолжают работать только в том случае, если главный узел восстанавливается примерно в течение десяти минут — это тайм-аут переподключения воркеров в KubeRay по умолчанию.

Сбои главного узла (head node) затрагивают весь кластер. Вывод узлов из эксплуатации (drain) для обновления образов узлов и патчей безопасности может отключить узлы Ray, а нехватка памяти (memory pressure) может привести к выселению пода главного узла, как описывает инженерная команда Klaviyo по итогам года эксплуатации Ray Serve на KubeRay. Без отказоустойчивости GCS (GCS fault tolerance) падает весь кластер. При ее наличии воркеры продолжают работать только в том случае, если главный узел восстанавливается примерно в течение десяти минут — это тайм-аут переподключения воркеров в KubeRay по умолчанию.

• Ray делит кластер с существующими платформ-сервисами. Сервисные сетки (service meshes), общие пространства имен (namespaces), квоты и требования аудита появились там раньше. Одна корпоративная команда, обслуживающая тысячи моделей на Ray Serve, обнаружила, что ее сайдкары Envoy создают слушатель (listener) для каждого порта Ray, что создавало нагрузку на плоскость управления сервисной сетки и влияло на соседние сервисы.

Ray делит кластер с существующими платформ-сервисами. Сервисные сетки (service meshes), общие пространства имен (namespaces), квоты и требования аудита появились там раньше. Одна корпоративная команда, обслуживающая тысячи моделей на Ray Serve, обнаружила, что ее сайдкары Envoy создают слушатель (listener) для каждого порта Ray, что создавало нагрузку на плоскость управления сервисной сетки и влияло на соседние сервисы.

LinkШесть лучших практик для продакшена KubeRay

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

Link1. Сохраняйте логи и события до того, как кластер исчезнет

Будьте готовы к тому, что панель мониторинга Ray недолговечного кластера исчезнет. Включите History Server из Части 1, чтобы события и логи Ray сохранялись в объектное хранилище, и протестируйте это на коротких запусках: аварийное завершение драйвера в первые минуты — это ситуация, которую команды упускают чаще всего. Если ваша команда ведет отладку в существующем стеке логирования, также отправляйте туда логи с помощью сайдкара, например Fluent Bit. Для задачи, которую вы активно отлаживаете, увеличьте значение ttlSecondsAfterFinished, чтобы кластер существовал дольше после завершения задачи, позволяя провести анализ.

Немного контекста о том, почему это важно. Просмотр логов и дашбордов для завершенного RayJob — одна из старейших просьб в сообществе KubeRay; пользователи поднимали этот вопрос еще в 2023 году. Это сложно, потому что эфемерные кластеры — сама суть RayJob, поэтому данные должны покинуть кластер до того, как покинет он сам. История работы (History Server) — это ответ сообщества, созданный при участии разработчиков из нескольких крупных команд платформ. Она была представлена в статусе alpha в KubeRay v1.6 и переведена в статус beta в v1.7. Она записывает события и логи Ray в объектное хранилище и позволяет просматривать их после удаления кластера.

Link2. Рассматривайте состояние GPU как сигнал планирования

Запускайте DCGM-экспортер от NVIDIA и настраивайте алерты на ошибки GPU Xid, а не только на загрузку. Используйте проверки состояния узлов (node health checks), чтобы пометить (taint) или изолировать (cordon) сбоящий узел, чтобы новые поды Ray перестали туда попадать. Затем используйте планирование с учетом меток из Части 1, чтобы новые рабочие нагрузки Ray оставались на исправных узлах. Сопровождающие KubeRay также обсуждают пересылку событий подов Kubernetes, включая сбои, связанные с устройствами, в ресурсы RayCluster для устранения неполадок (issue #5304).

Link3. Настраивайте под состязательность, а не под тихий кластер

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

• Групповое планирование (gang scheduling): используйте один из планировщиков из Части 1 (Volcano, YuniKorn, scheduler-plugins или NVIDIA KAI Scheduler), чтобы воркеры задачи запускались все вместе или не запускались вовсе. Это не дает ранним воркерам простаивать в ожидании формирования группы размещения.

Групповое планирование (gang scheduling): используйте один из планировщиков из Части 1 (Volcano, YuniKorn, scheduler-plugins или NVIDIA KAI Scheduler), чтобы воркеры задачи запускались все вместе или не запускались вовсе. Это не дает ранним воркерам простаивать в ожидании формирования группы размещения.

• Тайм-аут простоя: если вы не используете групповое планирование, увеличьте тайм-аут простоя, чтобы ранние воркеры GPU выживали, пока формируется остальная часть группы размещения.

Тай-аут простоя: если вы не используете групповое планирование, увеличьте тайм-аут простоя, чтобы ранние воркеры GPU выживали, пока формируется остальная часть группы размещения.

• Запас maxReplicas: оставьте место для запасного воркера, которого запрашивает Ray Train после завершения процесса из-за нехватки памяти (OOM-kill). Рассчитайте его размер на нужное количество воркеров плюс как минимум два.

Запас maxReplicas: оставьте место для запасного воркера, которого запрашивает Ray Train после завершения процесса из-за нехватки памяти (OOM-kill). Рассчитайте его размер на нужное количество воркеров плюс как минимум два.

• Ограниченные повторные попытки: ограничьте количество перезапусков при нехватке памяти с помощью RAY_task_oom_retries, чтобы повторяющиеся попытки не выполнялись часами.

Ограниченные повторные попытки: ограничьте количество перезапусков при нехватке памяти с помощью RAY_task_oom_retries, чтобы повторяющиеся попытки не выполнялись часами.

• Смешанные пулы CPU и GPU: следите за тем, добавляет ли автоскейлер узлы CPU, когда бутылочным горлышком являются GPU, и уменьшаются ли простаивающие узлы CPU во время этапов, ограниченных GPU.

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

Также следите за группами размещения, оставшимися после повторных попыток. Они удерживают ресурсы, которые автоскейлер не может вернуть.

Link4. Проектируйте систему с расчетом на потерю главного узла (head node)

• Установите num-cpus: "0" на головном узле, чтобы задачи и акторы CPU не планировались там.

Установите num-cpus: "0" на головном узле, чтобы задачи и акторы CPU не планировались там.

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

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

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

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

• Для Ray Serve установите max_replicas_per_node, чтобы сбой отдельного узла затрагивал только часть развертывания.

Для Ray Serve установите max_replicas_per_node, чтобы сбой отдельного узла затрагивал только часть развертывания.

Link5. Впишите Ray в уже имеющийся узел кластера

• Выделите Ray собственный пространств имен (namespace) с элементами управления RBAC и NetworkPolicy из Части 1, чтобы рабочие нагрузки Ray были изолированы от соседних сервисов.

Выделите Ray собственный пространств имен (namespace) с элементами управления RBAC и NetworkPolicy из Части 1, чтобы рабочие нагрузки Ray были изолированы от соседних сервисов.

• Если вы используете сервис-меш (service mesh), держите его на периферии. Исключите внутренние порты Ray из сайдкара и вместо этого шифруйте трафик между подами с помощью собственного TLS от Ray или поддержки mTLS от KubeRay (альфа-версия в v1.7). Прослушиватель сайдкара для каждого порта Ray может перегрузить меш.

Если вы используете сервис-меш (service mesh), держите его на периферии. Исключите внутренние порты Ray из сайдкара и вместо этого шифруйте трафик между подами с помощью собственного TLS от Ray или поддержки mTLS от KubeRay (альфа-версия в v1.7). Прослушиватель сайдкара для каждого порта Ray может перегрузить меш.

• Пометьте каждый RayJob и RayService метками команды и центра затрат, чтобы квоты Kueue из Части 1 также обеспечивали распределение затрат и их возврат (chargeback).

Пометьте каждый RayJob и RayService метками команды и центра затрат, чтобы квоты Kueue из Части 1 также обеспечивали распределение затрат и их возврат (chargeback).

Link6. Настраивайте алерты на важные сбои и автоматизируйте первую реакцию

Настройте алерты на статус Failed для RayJob, перезапуски головного пода и ошибки GPU Xid. Начните с того, что рассматривалось в Части 1: нативные для Kubernetes поля статуса и события (Events) KubeRay уже сообщают о состоянии RayJob и RayCluster, а kubectl ray предоставляет дежурным инженерам быстрый обзор. Там, где реакция всегда одинакова, например, изоляция (cordon) узла со сбоящим GPU, автоматизируйте ее, чтобы дежурный инженер начинал с готового ответа, а не с дашборда.

LinkКогда «клей» начинает обходиться слишком дорого

В Части 1 KubeRay заменил связующий код («клей») между Ray и Kubernetes. В масштабе парка машин появляется новый слой связующего кода. Каждая из описанных выше практик выполнима. Каждая из них также является связующим элементом: тем, что кто-то в вашей команде создает, поддерживает и сопровождает. Для одной команды на одном кластере это управляемо. Ситуация меняется со второй командой и вторым кластером, когда на обработку упавшей задачи, трехчасового ожидания в очереди или ответа на вопрос аудитора уходит реальное время.

Быстрая самопроверка. Делаете ли вы следующее:

• Поддерживаете конвейер исключительно для сбора логов до того, как эфемерные RayJob завершатся?

Поддерживаете конвейер исключительно для сбора логов до того, как эфемерные RayJob завершатся?

• Тратите часы на выяснение того, в чем причина сбоя: GPU, Kubernetes или Ray?

Тратите часы на выяснение того, в чем причина сбоя: GPU, Kubernetes или Ray?

• Вручную настраиваете параметры автоскейлера по умолчанию, чтобы производственные задачи не простаивали?

Вручную настраиваете параметры автоскейлера по умолчанию, чтобы производственные задачи не простаивали?

• Запускаете избыточные кластеры или настраиваете кастомную проверку работоспособности для поддержания работоспособности Ray Serve?

Запускаете избыточные кластеры или настраиваете кастомную проверку работоспособности для поддержания работоспособности Ray Serve?

• Вручную распределяете рабочие нагрузки по командам для аудита или chargeback?

Вручную распределяете рабочие нагрузки по командам для аудита или chargeback?

• Управляете Ray в нескольких кластерах, облаках или регионах сверх того, что покрывает MultiKueue?

Управляете Ray в нескольких кластерах, облаках или регионах сверх того, что покрывает MultiKueue?

Если два или более пунктов описывают вашу неделю, вам, вероятно, стоит присмотреться к платформенному уровню.

LinkЧто будет дальше: KubeRay Connect

Мы создали Anyscale KubeRay Connect (сейчас доступен в рамках закрытого предварительного просмотра), чтобы командам больше не приходилось самостоятельно создавать этот уровень. Он работает поверх уже развернутого у вас KubeRay. Ваш оператор продолжает выполнять согласование CR, вы по-прежнему отправляете запросы через kubectl apply, а ваши очереди Kueue и GitOps остаются без изменений. Ничего не переписывается.

Независимо от того, только ли вы начинаете работу с KubeRay или уже используете его в продакшене, сохраните свой текущий стек Kubernetes и KubeRay и расширьте возможности вашей платформы за счет полноценной наблюдаемости (observability), мультиоблачной оркестрации, безопасности, управления и корпоративной поддержки, чтобы ваши разработчики сохраняли высокую продуктивность и выпускали релизы быстрее.

KubeRay Connect устанавливается с помощью чарта Helm в виде тонкого слоя рядом с вашими рабочими нагрузками. Небольшой компонент Anyscale Connector вносит изменения в спецификации KubeRay на этапе допуска (admission) и внедряет легковесные сайдкары телеметрии. Коллектор передает метрики и события Kubernetes на платформу Anyscale.

Вот как Connect соотносится с пятью сценариями:

Сценарий

Что делает KubeRay Connect

Данные для отладки привязаны к жизненному циклу кластера

Сохраненные панели мониторинга задач и акторов, агрегированные логи, а также события заданий, служб и автоскейлера, которые управляются за вас и доступны для просмотра в консоли Anyscale без использования kubectl

Аппаратные сбои проявляются как ошибки приложения

Сопоставляет метрики GPU, события Kubernetes и сигналы Ray в едином месте, благодаря чему аппаратный сбой отображается рядом с затронутой задачей

Настройки по умолчанию требуют тюнинга при масштабировании

Отображает события автоскейлера и использование GPU для каждого задания, позволяя вовремя заметить неправильно настроенные тайм-ауты простоя и лимиты реплик.

Оркестрация добавляет отправку заданий для одного кластера, планирование и отслеживание статуса наряду с вашими очередями Kueue. Автоматическая настройка параметров Ray запланирована в дорожной карте.

Сбои главного узла (head node) затрагивают весь кластер

Отображает события, предшествующие сбою и сопутствующие ему; ваша архитектура отказоустойчивости остается прежней

Ray делит кластер с существующими службами платформы

Устанавливается рядом с вашим текущим стеком: соединения только исходящие, отсутствие входящего трафика (ingress) на плоскости управления, а ваши очереди Kueue и GitOps остаются без изменений.

Проброс учетных данных (identity passthrough) для RBAC и атрибуции запланирован в дорожной карте.

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

Модель безопасности создана с расчетом на аудит. каждое соединение инициируется изнутри вашего кластера, поэтому плоскости управления не требуется входящий трафик. Для аутентификации вместо ключей API используются проецируемые токен OIDC для ServiceAccount. Допуск по умолчанию настроен по принципу fail-closed, поэтому рабочая нагрузка никогда не будет допущена без телеметрии.

LinkНачать работу

KubeRay — это надежная основа, и шесть описанных выше практик существенно помогут вам в работе. Но когда вы предпочитаете тратить время своей команды на модели, а не на написание связующего кода, готовый и поддерживаемый уровень платформы возвращает это время вам.

• Используете KubeRay в продакшене?Подайте заявку на участие в закрытом предварительном просмотре KubeRay Connect.

Используете KubeRay в продакшене?Подайте заявку на участие в закрытом предварительном просмотре KubeRay Connect.

• Будете на конференции KubeCon + CloudNativeCon North America 2026 (9–12 ноября, Солт-Лейк-Сити)? Зарегистрируйтесь и заходите поздороваться. Мы с удовольствием послушаем о ваших кластерах и о том, над чем работает ваша команда.

Будете на конференции KubeCon + CloudNativeCon North America 2026 (9–12 ноября, Солт-Лейк-Сити)? Зарегистрируйтесь и заходите поздороваться. Мы с удовольствием послушаем о ваших кластерах и о том, над чем работает ваша команда.

• Впервые работаете с KubeRay? Начните с Части 1: Запуск Ray в масштабе на Kubernetes с помощью KubeRay.

Впервые работаете с KubeRay? Начните с Части 1: Запуск Ray в масштабе на Kubernetes с помощью KubeRay.

• Присоединяйтесь к нашему сообществу. Поделитесь тем, чему вы научились, в #kuberay чате Ray в Slack или на двунедельной встрече сообщества KubeRay.

Присоединяйтесь к нашему сообществу. Поделитесь тем, чему вы научились, в чате Ray в Slack или на двунедельной встрече сообщества KubeRay.