Как операторам разбирать ML-нагрузки Kubeflow в интерфейсе Kubernetes

ML-платформа в Kubernetes быстро обрастает сущностями, которые плохо видны из привычного набора экранов. Data scientist запускает notebook, эксперимент Katib или pipeline run; оператору же требуется понять, что происходит с Pod, томами, лимитами ресурсов и контроллерами. При сбое приходится переходить от специализированного интерфейса к kubectl, искать связанные объекты по namespace и собирать состояние из нескольких команд.

Kubeflow строится на Kubernetes-нативных API: его компоненты описываются пользовательскими ресурсами — CRD. Поэтому значительная часть необходимой диагностики уже доступна через API-сервер кластера. Плагин Kubeflow для Headlamp использует этот факт и добавляет представления ML-ресурсов в универсальный Kubernetes UI.

Почему одного ML-дашборда недостаточно оператору

Интерфейсы ML-платформ удобны для отправки экспериментов, работы с notebook и просмотра результатов. Эксплуатационные вопросы лежат уровнем ниже:

почему сервер notebook не стартовал: из-за ImagePullBackOff, OOMKilled или ожидания PersistentVolumeClaim;
какие запуски Run недавно завершились ошибкой в нескольких namespace;
на какой TrainingRuntime ссылается TrainJob;
какие значения метрик и параметры привели Katib к лучшему trial;
в каком состоянии находятся batch-задачи и связанные с ними Pod.

Эти сведения относятся к реальному состоянию Kubernetes. Плагин Headlamp запрашивает их напрямую у API-сервера и показывает условия Pod, причины ошибок и объекты из разных namespace. Для расследования это сокращает число переключений между отдельными дашбордами и терминалом.

Модель расширения через CRD

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

Плагин для Kubeflow проверяет, какие API-группы есть в кластере, и отображает только доступные разделы. Это важно для модульных инсталляций: набор компонентов Kubeflow может различаться между окружениями. В интерфейсе могут появиться следующие группы ресурсов:

Компонент	Примеры ресурсов
Notebooks	`Notebook`, `Profile`, `PodDefault`
Pipelines	`Pipeline`, `PipelineVersion`, `Run`, `RecurringRun`, `Experiment`
Katib	`Experiment`, `Trial`, `Suggestion`
Training	`TrainJob`, `TrainingRuntime`, `ClusterTrainingRuntime`
Spark	`SparkApplication`, `ScheduledSparkApplication`

Такой подход хорошо масштабируется на другие платформы, которые строят доменную модель поверх CRD. Пользовательский интерфейс сохраняет язык предметной области, а оператор получает связь с базовыми ресурсами кластера.

Диагностика notebook на уровне Pod

Карточка Notebook объединяет данные, для которых обычно требуется несколько вызовов kubectl describe. В ней можно проверить условия Pod и поля reason и message, запросы и лимиты CPU, памяти и GPU, а также состав контейнеров.

Отдельно полезно видеть монтирования томов: PersistentVolumeClaim, ConfigMap, Secret и emptyDir сразу дают контекст для ошибок запуска. Туда же относятся переменные окружения со ссылками на Secret и ConfigMap, sidecar-контейнеры и tolerations. При нехватке ресурсов или несовпадении требований с узлами эти детали позволяют быстрее сузить область поиска.

Для homelab-кластера это особенно практично: ресурсы часто ограничены, GPU может быть один, а storage собран из нескольких слоёв. Просмотр спецификации и статуса рядом с данными о Pod упрощает проверку конфигурации до того, как проблема превратится в долгий разбор логов.

Что видно при настройке обучения

Katib создаёт эксперименты и набор trial для поиска гиперпараметров. В представлениях плагина доступны алгоритм настройки, пространство поиска, текущие статусы trial и лучший найденный trial с метриками и назначенными параметрами. Также отображаются настройки ранней остановки и количество trial, завершённых досрочно.

Это делает процесс оптимизации наблюдаемым для команды эксплуатации. Можно сопоставить число и состояние попыток с доступными ресурсами кластера, не теряя контекст самого эксперимента.

Распределённое обучение представлено ресурсами TrainJob, TrainingRuntime и ClusterTrainingRuntime. Их наличие в одном интерфейсе с Kubernetes-объектами помогает проверить, что задача использует ожидаемую конфигурацию рантайма и что контроллеры создали требуемые дочерние ресурсы.

Pipeline без зависимости от сервисов платформы

Для ресурсов Pipelines интерфейс читает Kubernetes API напрямую. Поэтому сохранённое состояние pipeline можно просмотреть, даже если API-сервис Kubeflow Pipelines или его база данных временно недоступны. В деталях Pipeline доступно параллельное сравнение YAML-спецификаций последней и предыдущей PipelineVersion.

Страницы Run показывают статус и длительность запусков, а RecurringRun — расписания в читаемом виде. Представление артефактов собирает значения pipelineRoot из недавних запусков. Эти данные полезны при проверке изменений в определении pipeline и при анализе повторяющихся сбоев.

Карта связей и практический порядок работы

Плагин может строить карту ML-ресурсов. Узлами на ней выступают Notebook, Profile, PodDefault, Experiment, Pipeline, SparkApplication и TrainJob; связи формируются по .metadata.ownerReferences. Такая визуализация помогает быстро увидеть владельца объекта и соседние ресурсы в цепочке выполнения.

При диагностике имеет смысл двигаться от симптома к состоянию кластера:

Открыть ML-ресурс со сбоем и проверить его статус.
Перейти к связанным Pod и посмотреть условия, события и причину завершения.
Проверить лимиты, тома, секреты, переменные окружения и требования к узлам.
Сверить связи через ownerReferences, чтобы исключить ошибку в контроллере или рантайме.
Для pipeline и Katib сопоставить текущее состояние с версией спецификации, параметрами и предыдущими запусками.

Единое представление CRD и базовых объектов Kubernetes не отменяет kubectl и сбор логов. Оно даёт оператору стартовую точку с полным контекстом: от сущности Kubeflow до причины, которую сообщает конкретный Pod.