Изучение Kubernetes в качестве инженера MLOps

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

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

Что такое Кубернетес?

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

Почему появился Kubernetes?

  • По мере того, как индустрия программного обеспечения переходит от монолитной к архитектуре на основе микросервисов, каждая функция размещается как отдельная служба, работающая в отдельных контейнерах независимо.
  • Управление сотнями и тысячами сервисов с тысячами контейнеров привело к хаосу. Таким образом, родился инструмент Kubernetes для решения этой проблемы.

Почему Kubernetes для MLOps?

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

  • Высокая доступность обеспечивает нулевое время простоя.
  • Масштабируемость: обеспечивает высокую производительность
  • Аварийное восстановление: приводит к резервному копированию и восстановлению.

Архитектура Кубернета

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

Узлы

Узлы относятся к экземплярам, ​​физическим машинам или удаленным экземплярам. В кластере Kubernetes есть два типа узлов, широко известных как главные и рабочие узлы, на которых выполняются контейнерные приложения. Главные узлы направляют рабочие узлы для запуска контейнерных приложений внутри пода. Под — это абстракция над контейнерами в Kubernetes, которая имеет собственные вычислительные ресурсы, хранилище и сетевые ресурсы.

Главный узел

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

Главный узел отвечает за многие процессы, которые помогают правильно запускать и управлять кластером Kubernetes. Вот некоторые из ключевых компонентов:

API-сервер

  • Это контейнер, который помогает в развертывании приложений в кластере Kubernetes.
  • Он действует как шлюз кластера и получает первоначальный запрос на любые обновления в кластере.
  • Он действует как канал для облегчения связи между различными клиентами Kubernetes и кластером, как и пользовательский интерфейс Kubernetes.

Планировщик

  • Это помогает планировать поды в узле.
  • Сервер API → Планировщик → Он только решает, где в узлах должен быть размещен модуль.
  • Он также считается интеллектуальным сервисом, потому что, когда поступает запрос на назначение модулей, планировщик изучает использование узла с точки зрения ЦП и памяти и создает модули на узлах, которые имеют больше ресурсов.

Менеджер контроллера

  • Он обнаруживает или отслеживает, умирает ли модуль в узле, и помогает перепланировать модуль.
  • Он обнаруживает изменения состояния в кластере.
  • Поток планирования Pod

CM → Scheduler → В каких нодах должны быть назначены pod’ы? → Kubelet → перезапускает модуль.

ETCD

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

Как планировщик узнает, где доступны ресурсы?

Как отслеживается состояние работоспособности кластера?

Как CM узнает, что состояние кластера изменилось, как будто Kubelet перезапустил pod?

Рабочий узел

Он выполняет фактическую работу в кластере Kubernetes, то есть запускает контейнеры и приложения в них. На каждом рабочем узле должны быть установлены три процесса:

Контейнер

  • Это среда выполнения для контейнеров.

Kube-прокси

  • Он отвечает за связь между службами внутри кластера.
  • Он перенаправляет запросы от сервисов к модулям.
  • Это разумно при отправке запросов, то есть рассмотрите возможность отправки запроса от A к B, где A и B — это два модуля в Node_1, а также есть репликация одного и того же в Node_2, тогда kube-proxy отправляет запрос от A в Node_1 в B в Node_1 вместо Node_2. тем самым снижая нагрузку на сеть.

Кубелет

  • Он распределяет модули по узлам.
  • Он взаимодействует между контейнерами и узлами.
  • Он назначает ресурсы контейнерам, таким как ЦП и память.

Обычно кластер K8s содержит несколько мастер-узлов, где API-сервер сбалансирован по нагрузке, а ETCD является распределенным хранилищем по всем мастер-узлам. Далее следует базовая настройка кластера

– Два главных узла — требуется меньше ресурсов, чем для рабочих узлов

– Три рабочих узла — здесь больше ресурсов и реальных действий.

Если вы найдете эту статью полезной, подпишитесь на меня и свяжитесь со мной, чтобы получить больше информации о MLOps и ML.

Ютуб и LinkedIn