Kubernetes непомітно став стандартною платформою для AI та машинного навчання. Незалежно від того, чи ви запускаєте сервери нотаток для дослідників-даних, плануєте розподілені тренувальні завдання, налаштовуєте гіперпараметри чи керуєте багатоступеневими ML-пайплайнами, ці навантаження дедалі частіше потрапляють в кластер Kubernetes. Kubeflow — одна з найпопулярніших платформ для складання такого стеку, і вона робить це природнім для Kubernetes способом: кожна можливість експонуєтсья як Custom Resource Definition (CRD).
Такий дизайн є подарунком для операторів кластерів, оскільки це означає, що за ML-навантаженнями можна спостерігати та керувати ними тими ж примітивами, що й усіма іншими в кластері. Але на практиці спеціалізовані ML-панелі, що постачаються з цими платформами, приховують Kubernetes-рівень під собою. Коли notebook застрягає або тренувальний запуск завершується невдало, оператор часто змушений повернутися до kubectl, щоб дізнатися, що насправді сталося на рівні Podʼа.
Тут представлено втулок Headlamp для Kubeflow, який усуває цю прогалину, показуючи власні ресурси Kubeflow безпосередньо в універсальному інтерфейсі Kubernetes. Це наочний приклад підходу, якого може дотримуватися будь-яка платформа, що активно використовує CRD: взаємодіяти з операторами там, де вони вже працюють, і надавати їм достовірну інформацію на рівні кластера.
Сам Headlamp — це розширюваний веб-інтерфейс Kubernetes, що підтримується Kubernetes SIG UI та ліцензований за ліцензією Apache 2.0. Він працює як десктоп-застосунок або в кластері, а його система втулків дозволяє будь-кому додавати першокласні представлення для власних ресурсів.
Спеціалізовані ML-панелі допомагають дослідникам даних подавати експерименти, пайплайни та notebookʼи. Оператори кластерів та інженери надійності сайтів (SRE) ввідлагоджують Kubernetes-ресурси в них, і вони задають інші запитання:
ImagePullBackOff, OOMKilled чи Pod, що очікує PersistentVolumeClaim?Втулок Headlamp Kubeflow допомагає відповісти на ці запитання, зчитуючи дані безпосередньо з Kubernetes API-сервера. Він показує стан Podʼів, причини збоїв в Kubernetes та ресурси в різних просторах імен без необхідності посередницького ML-сервісу чи бази даних.
Kubeflow є модульним, і команди часто встановлюють лише ті компоненти, які їм потрібні. Втулок виявляє API-групи Kubeflow у кластері та показує лише відповідні розділи.
Втулок підтримує такі родини компонентів та API-ресурси:
| Компонент | Призначення | API-ресурси |
|---|---|---|
| Notebooks | Надає середовища розробки, такі як Jupyter, VS Code та RStudio | Notebook, Profile, PodDefault |
| Pipelines | Визначає та відстежує пайплайни, версії, експерименти, запуски та розклади | Pipeline, PipelineVersion, Run, RecurringRun, Experiment |
| Katib | Автоматизує налаштування гіперпараметрів та пошук нейронних архітектур | Experiment, Trial, Suggestion |
| Training | Виконує розподілені тренувальні навантаження, такі як PyTorch та TensorFlow jobs | TrainJob, TrainingRuntime, ClusterTrainingRuntime |
| Spark | Виконує масштабну обробку даних за допомогою Apache Spark | SparkApplication, ScheduledSparkApplication |
Детальний вигляд Notebook показує стан Podʼів та їхні поля reason та message. Він також показує CPU, памʼять та GPU-запити та ліміти; монтування томів та їхні типи, такі як PersistentVolumeClaim, ConfigMap, Secret чи emptyDir; змінні середовища, що посилаються на Secret чи ConfigMap обʼєкти; sidecar-контейнери; та толерантності вузлів. Цей вигляд консолідує інформацію, яка в іншому випадку вимагала б кількох команд kubectl describe.
Представлення Katib показують алгоритм налаштування, простір пошуку, кожен Trial з його поточним статусом та поточний найкращий Trial з його метричними значеннями та призначеннями параметрів. Вони також показують конфігурацію раннього зупинення та кількість ресурсів Trial, що зупинилися рано, щоб ви могли слідкувати за пошуком, не виходячи з UI кластера.
Представлення Pipelines зчитують Kubernetes-ресурси API безпосередньо та не запитують Kubeflow Pipelines API-сервіс чи базу даних бекенду. Ви можете інспектувати збережений стан пайплайну навіть коли цей сервіс недоступний. Детальний вигляд Pipeline надає порівняння останньої та попередньої версій PipelineVersion у вигляді паралельного порівняння у форматі YAML. Представлення Run показують стан та тривалість, представлення RecurringRun показують зрозумілі розклади, а представлення artifacts агрегує значення pipelineRoot з останніх ресурсів Run.
Втулок реєструє Headlamp map source, що рендерить Notebook, Profile, PodDefault, Experiment, Pipeline, SparkApplication, та TrainJob ресурси як вузли графа. Він малює ребра між підтримуваними ресурсами на основі .metadata.ownerReferences. Headlamp також показує вбудовані зведення для цих типів ресурсів, коли ви наводите на них курсор.
README втулка Kubeflow пояснює встановлення та налаштування локального кластера, включаючи легкий шлях CRD-тільки для оцінки. Оскільки втулок виявляє встановлені API-групи, ви можете використовувати його з існуючою модульною установкою Kubeflow чи створити кластер оцінки з лише CRD та зразковими ресурсами.
Kubeflow ілюструє ширший шаблон. Платформи часто моделюють домен-специфічні робочі процеси за допомогою власних ресурсів. Їх інфопанелі зосереджені на цих робочих процесах, тоді як Kubernetes-оператори також потребують стану базових API-ресурсів та Podʼів. Втулок, що працює на основі CRD, у загальному Kubernetes UI може експонувати цей стан без змушення операторів перемикатися між незвʼязаними інструментами.
Втулок використовує ліцензію Apache 2.0 та розробляється під егідою Kubernetes SIG UI. Щоб повідомити про проблему чи зробити покращення, скористайтеся issue tracker чи pull requests репозиторію втулків Headlamp.