Изучение 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.