# Керування AI/ML навантаженнями в Kubernetes: втулок Headlamp для Kubeflow

LLMS index: [llms.txt](/llms.txt)

---

Kubernetes непомітно став стандартною платформою для AI та машинного навчання. Незалежно від того, чи ви запускаєте сервери нотаток для дослідників-даних, плануєте розподілені тренувальні завдання, налаштовуєте гіперпараметри чи керуєте багатоступеневими ML-пайплайнами, ці навантаження дедалі частіше потрапляють в кластер Kubernetes. [Kubeflow](https://www.kubeflow.org/) — одна з найпопулярніших платформ для складання такого стеку, і вона робить це природнім для Kubernetes способом: кожна можливість експонуєтсья як Custom Resource Definition (CRD).

Такий дизайн є подарунком для операторів кластерів, оскільки це означає, що за ML-навантаженнями можна спостерігати та керувати ними тими ж примітивами, що й усіма іншими в кластері. Але на практиці спеціалізовані ML-панелі, що постачаються з цими платформами, приховують Kubernetes-рівень під собою. Коли notebook застрягає або тренувальний запуск завершується невдало, оператор часто змушений повернутися до `kubectl`, щоб дізнатися, що насправді сталося на рівні Podʼа.

Тут представлено **втулок Headlamp для Kubeflow**, який усуває цю прогалину, показуючи власні ресурси Kubeflow безпосередньо в універсальному інтерфейсі Kubernetes. Це наочний приклад підходу, якого може дотримуватися будь-яка платформа, що активно використовує CRD: взаємодіяти з операторами там, де вони вже працюють, і надавати їм достовірну інформацію на рівні кластера.

Сам Headlamp — це розширюваний веб-інтерфейс Kubernetes, що підтримується [Kubernetes SIG UI](https://github.com/kubernetes-sigs/headlamp) та ліцензований за ліцензією Apache 2.0. Він працює як десктоп-застосунок або в кластері, а його система втулків дозволяє будь-кому додавати першокласні представлення для власних ресурсів.

## Чому операторам потрібне інше представлення {#why-operators-need-a-different-view}

Спеціалізовані ML-панелі допомагають дослідникам даних подавати експерименти, пайплайни та notebookʼи. Оператори кластерів та інженери надійності сайтів (SRE) ввідлагоджують Kubernetes-ресурси в них, і вони задають інші запитання:

- Чому notebook застряг? Чи це `ImagePullBackOff`, `OOMKilled` чи Pod, що очікує PersistentVolumeClaim?
- Які ресурси Run нещодавно завершилися невдало в різних просторах імен?
- Який набір параметрів Katib Experiment визнає оптимальним?
- Чи посилаються ресурси TrainJob на очікувані ресурси TrainingRuntime?
- Які пакетні навантаження виконуються та який стан показує Kubernetes?

Втулок Headlamp Kubeflow допомагає відповісти на ці запитання, зчитуючи дані безпосередньо з Kubernetes API-сервера. Він показує стан Podʼів, причини збоїв в Kubernetes та ресурси в різних просторах імен без необхідності посередницького ML-сервісу чи бази даних.

## Що охоплює цей втулок {#what-the-plugin-covers}

Kubeflow є модульним, і команди часто встановлюють лише ті компоненти, які їм потрібні. Втулок виявляє API-групи Kubeflow у кластері та показує лише відповідні розділи.

Втулок підтримує такі родини компонентів та API-ресурси:



 





<table><caption style="display: none;">Kubeflow компоненти та API-ресурси, підтримувані втулком Headlamp</caption>
	<thead>
			<tr>
					<th style="text-align: left">Компонент</th>
					<th style="text-align: left">Призначення</th>
					<th style="text-align: left">API-ресурси</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left"><strong>Notebooks</strong></td>
					<td style="text-align: left">Надає середовища розробки, такі як Jupyter, VS Code та RStudio</td>
					<td style="text-align: left">Notebook, Profile, PodDefault</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>Pipelines</strong></td>
					<td style="text-align: left">Визначає та відстежує пайплайни, версії, експерименти, запуски та розклади</td>
					<td style="text-align: left">Pipeline, PipelineVersion, Run, RecurringRun, Experiment</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>Katib</strong></td>
					<td style="text-align: left">Автоматизує налаштування гіперпараметрів та пошук нейронних архітектур</td>
					<td style="text-align: left">Experiment, Trial, Suggestion</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>Training</strong></td>
					<td style="text-align: left">Виконує розподілені тренувальні навантаження, такі як PyTorch та TensorFlow jobs</td>
					<td style="text-align: left">TrainJob, TrainingRuntime, ClusterTrainingRuntime</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>Spark</strong></td>
					<td style="text-align: left">Виконує масштабну обробку даних за допомогою Apache Spark</td>
					<td style="text-align: left">SparkApplication, ScheduledSparkApplication</td>
			</tr>
	</tbody>
</table>


## Що ви можете побачити {#what-you-can-see}

### Інспектуйте Podʼи notebook {#inspect-notebook-pods}

Детальний вигляд Notebook показує стан Podʼів та їхні поля `reason` та `message`. Він також показує CPU, памʼять та GPU-запити та ліміти; монтування томів та їхні типи, такі як PersistentVolumeClaim, ConfigMap, Secret чи `emptyDir`; змінні середовища, що посилаються на Secret чи ConfigMap обʼєкти; sidecar-контейнери; та толерантності вузлів. Цей вигляд консолідує інформацію, яка в іншому випадку вимагала б кількох команд `kubectl describe`.

### Інспектуйте налаштування гіперпараметрів {#inspect-hyperparameter-tuning}

Представлення Katib показують алгоритм налаштування, простір пошуку, кожен Trial з його поточним статусом та поточний найкращий Trial з його метричними значеннями та призначеннями параметрів. Вони також показують конфігурацію раннього зупинення та кількість ресурсів Trial, що зупинилися рано, щоб ви могли слідкувати за пошуком, не виходячи з UI кластера.

### Інспектуйте стан пайплайну без бази даних бекенду {#inspect-pipeline-state-without-backend-database}

Представлення Pipelines зчитують Kubernetes-ресурси API безпосередньо та не запитують Kubeflow Pipelines API-сервіс чи базу даних бекенду. Ви можете інспектувати збережений стан пайплайну навіть коли цей сервіс недоступний. Детальний вигляд Pipeline надає порівняння останньої та попередньої версій PipelineVersion у вигляді паралельного порівняння у форматі YAML. Представлення Run показують стан та тривалість, представлення RecurringRun показують зрозумілі розклади, а представлення artifacts агрегує значення `pipelineRoot` з останніх ресурсів Run.

### Мапа ML-ресурсів {#map-ml-resources}

Втулок реєструє [Headlamp map source](https://headlamp.dev/docs/latest/development/plugins/functionality/extending-the-map/), що рендерить Notebook, Profile, PodDefault, Experiment, Pipeline, SparkApplication, та TrainJob ресурси як вузли графа. Він малює ребра між підтримуваними ресурсами на основі `.metadata.ownerReferences`. Headlamp також показує вбудовані зведення для цих типів ресурсів, коли ви наводите на них курсор.

## Спробуйте {#try-it}

[README втулка Kubeflow](https://github.com/headlamp-k8s/plugins/blob/main/kubeflow/README.md) пояснює встановлення та налаштування локального кластера, включаючи легкий шлях CRD-тільки для оцінки. Оскільки втулок виявляє встановлені API-групи, ви можете використовувати його з існуючою модульною установкою Kubeflow чи створити кластер оцінки з лише CRD та зразковими ресурсами.

## Застосуйте шаблон до інших платформ {#apply-the-pattern-to-other-platforms}

Kubeflow ілюструє ширший шаблон. Платформи часто моделюють домен-специфічні робочі процеси за допомогою власних ресурсів. Їх інфопанелі зосереджені на цих робочих процесах, тоді як Kubernetes-оператори також потребують стану базових API-ресурсів та Podʼів. Втулок, що працює на основі CRD, у загальному Kubernetes UI може експонувати цей стан без змушення операторів перемикатися між незвʼязаними інструментами.

Втулок використовує ліцензію Apache 2.0 та розробляється під егідою Kubernetes SIG UI. Щоб повідомити про проблему чи зробити покращення, скористайтеся [issue tracker](https://github.com/headlamp-k8s/plugins/issues) чи [pull requests](https://github.com/headlamp-k8s/plugins/pulls) репозиторію втулків Headlamp.