Сегодня рассмотрим особенности Kubernetes (и платформ оркестровки контейнеров в целом), которые сделали контейнеры столь популярными среди команд по работе с данными. Огромное количество инструментов, интегрированных с K8s, и его присутствие в каждой облачной платформе делают его комплексным инструментом для воспроизводимых и масштабируемых рабочих нагрузок данных.
Контейнеры стали стандартом де-факто для переноса проектов данных в производство. Больше нет кошмаров с управлением зависимостями. Потому что проекты, разработанные на локальной машине, могут быть «отправлены» на кластер для постановки и производства (как правило) без каких-либо сюрпризов. Конвейеры данных и модели ML наконец-то воспроизводимы и могут работать везде одинаково.
Однако с постоянно растущим числом рабочих нагрузок, связанных с данными в контейнерах. Все большее значение приобретают платформы оркестровки.
Оркестровка контейнеров
Если вы хотите запустить воспроизводимые конвейеры данных и ML-модели, которые могут работать где угодно, вы, вероятно, знаете, что для этого отлично подойдет образ Docker. Все любят образы контейнеров, от инженеров-программистов до DevOps и SRE.
В прошлом проблема заключалась в том, чтобы запустить контейнеры в масштабе. С Kubernetes, особенно при развертывании в эластичных облачных сервисах, управление выполнением контейнеров в масштабе стало значительно менее болезненным.
Общение между командами
Как бы многим из нас ни нравилось создавать сквозные продукты данных. В реальности многие предприятия разделяют обязанности между теми, кто создает продукт данных. И теми, кто им управляет. После создания конвейеров данных ученые и инженеры, занимающиеся данными, часто должны передать их DevOps и SRE для развертывания и мониторинга. Образы контейнеров значительно облегчают этот процесс передачи.
В то же время контейнеры облегчают совместное использование кода и сотрудничество между инженерами по данным, специалистами по данным и аналитиками, которые могут работать в одной и той же воспроизводимой среде.
Декларативное определение
В наши дни рабочие нагрузки инженеров по обработке данных динамичны по своей природе. Представьте, что вы развернули свой конвейер данных на кластере Kubernetes. И теперь он не работает из-за ошибки отсутствия памяти. В таком случае, устранение проблемы может заключаться в увеличении объема памяти в декларативном файле развертывания и применении изменений на кластере.
Документация
Приятным «побочным эффектом» рабочего процесса и конфигурации в виде кода является то, что все документируется. Не только бизнес-логика, но и детали выполнения, такие как место выполнения и потребляемые ресурсы. Когда другим инженерам нужно поработать над вашим кодом, им не нужно гадать и обращаться по каждому вопросу, чтобы ввести их в курс дела с вашими рабочими нагрузками данных.
Версионирование
Еще одно преимущество декларативного рабочего процесса и определения среды заключается в том, что все можно контролировать по версиям. Если что-то пойдет не так, вы сможете вернуться к предыдущей версии. Вы можете отслеживать изменения, вносимые в среду с течением времени, и предоставлять журнал аудита для обеспечения соответствия требованиям. GitOps и MLOps сделали этот подход популярным. Но контейнеры и платформы оркестровки эффективно сделали его возможным. Еще одна особенность Kubernetes.
Поддержание состояния сервисов
Одним из наиболее заметных преимуществ Kubernetes является то, что он всегда будет пытаться поддерживать желаемое состояние. Следовательно перезапускать или воссоздавать ресурсы после их гибели. Конечно, самовосстанавливающиеся «силы» Kubernetes не смогут решить все ваши проблемы (например, сломанную бизнес-логику). Но, по крайней мере, вам не придется вмешиваться, когда ошибка возникает из-за временной сетевой проблемы, которая может быть решена перезапуском или перераспределением в новую капсулу.
Бесшовное масштабирование платформы выполнения по мере роста данных
Запуск конвейеров данных на одном сервере, вероятно, не подходит для вас в наши дни. При растущих объемах данных становится трудно управлять их обработкой. Независимо от того, упаковываем ли мы код в образы контейнеров или запускаем его в одном локальном процессе.
Если вам необходимо масштабировать рабочие нагрузки на несколько узлов, Kubernetes (особенно в сочетании с диаграммами Helm) значительно упрощает установку Dask или Spark на вычислительный кластер и, таким образом, распределение обработки данных между несколькими узлами. Большинство облачных провайдеров предлагают услуги автомасштабирования или даже предоставляют полностью бессерверную плоскость данных (AWS EKS на Fargate и GCP GKE Autopilot). Эти облачные поставщики берут на себя заботу о масштабировании рабочих узлов, когда это необходимо. Тем самым полностью устраняя необходимость в угадывании требуемых мощностей.
Несмотря на все преимущества, Kubernetes не даст вам мгновенной видимости того, что происходит в рабочих нагрузках данных. Но облегчит установку распределенного вычислительного механизма и его плавное масштабирование на несколько узлов.
Паритет среды разработки и производственной среды
Общая проблема при создании продуктов данных заключается в том, что среда разработки часто сильно отличается от того, как все должно работать в производстве. Контейнерные рабочие нагрузки значительно упрощают этот переход. У вас могут быть разные кластеры или пространства имен для средовых и производственных сред. Переключение между ними должно быть плавным.
Быстрее итерировать
Итерации имеют решающее значение для создания рабочих нагрузок данных. Большинство продуктов данных сначала получаются плохими. Вам может понадобиться несколько циклов очистки и преобразования данных. Такие как тестирования различных классификаторов и гиперпараметров или обогащения моделей новыми данными. Развертывания Kubernetes позволяют проводить A/B-тестирования. Также запускать несколько экземпляров одного и того же задания на обучение ML, но с разными гиперпараметрами.
Есть огромное преимущество и реальное доказательство того, что использование Kubernetes позволяет ускорить итерации. Это сочетание Kubernetes с инструментами, которые абстрагируют детали низкого уровня. Например:
- Для построения и масштабирования потоков данных можно использовать Prefect с Dask на Kubernetes.
Установка практически любого программного обеспечения с помощью диаграмм Helm и дополнительных функций
Kubernetes стал настолько популярным, что множество инструментов было создано или переработано для работы на кластерах K8s. Обычно вы можете установить их с помощью репозиториев диаграмм Helm. В приведенном выше списке мы посмотрели их только на поверхности. Вы видите, что можете использовать эту платформу оркестровки контейнеров для создания любых рабочих нагрузок с данными. Например для выполнения заданий ETL, обучения и обслуживания ML-моделей и даже создания и размещения визуализаций.
Что общего?
Общим для всех вышеперечисленных пунктов является тот факт, что контейнеры (и платформы оркестровки контейнеров) позволяют нам:
- Создавать воспроизводимый код, который может работать одинаково в любом месте и в любом масштабе.
- Уменьшить трение при передаче данных между различными командами.
- Применять современные методы разработки программного обеспечения для работы с данными, включая GitOps, DevOps и MLOps.
Если вы хотите следовать этой парадигме для визуализации данных, компания GoodData недавно запустила свою облачную нативную платформу GoodData.CN. Именно ее вы и можете установить на свой кластер Kubernetes. Вы можете начать с запуска контейнера Docker с одним образом для локальной разработки приборных панелей, метрик и KPI (в DRY-формате!):
docker run --name gooddata -p 3000:3000 -p 5432:5432 \\\\
-e LICENSE_AND_PRIVACY_POLICY_ACCEPTED=YES gooddata/gooddata-cn-ce:latest
После того, как вы разработали свои приборные панели, метрики и инсайты локально. Наконец вы можете экспортировать свои декларативные определения и развернуть их в производственном кластере Kubernetes. Команда GoodData предоставила подробную документацию, показывающую, как можно установить их программное обеспечение для различных сценариев:
- А также множество полезных советов по управлению организациями, рабочими пространствами и источниками данных.
Насколько по вашему мнению Kubernetes важен в современном DevOPS?
Начать курс бесплатно:yodo.im/start
И еще много важного о DevOPS читай тут
Оригинал статьи тут
