#kubernetes #google-cloud-platform #airflow #google-cloud-composer
# #kubernetes #google-облачная платформа #поток воздуха #google-cloud-composer
Вопрос:
Погружаясь в мир Cloud Composer, Airflow, Google Kubernetes Engine и Kubernetes, я пока не нашел хорошего ответа на вопрос, что именно делает Cloud Composer лучше Helm и GKE.
Вот некоторые вещи, которые я обнаружил, которые могут быть уникальными для Composer, но в основном кажется, что с ними может справиться GKE.
На их домашней странице:
- Сквозная интеграция с облачными продуктами Google, включая BigQuery, Dataflow, Dataproc, хранилище данных, облачное хранилище, Pub / Sub и платформу искусственного интеллекта, дает пользователям свободу полностью управлять своим конвейером.
На странице функций:
- Прокси-сервер с поддержкой идентификации защищает интерфейс
- Cloud Composer связывает корзину облачного хранилища со средой. В связанной корзине хранятся базы данных, журналы, пользовательские плагины и данные для среды.
К недостаткам Composer, которые я видел, относятся:
- На создание нового экземпляра уходит много часов
- Он не поддерживает Kubernetes Executor
- Изменять базовую конфигурацию GKE рискованно, поскольку она может быть изменена с помощью обновления composer
- При частом автоматическом масштабировании часто возникают ошибки, которые документируются как известные
- Обновление сред все еще находится в стадии бета-тестирования
Чтобы внести ясность, я не говорю, что облачный композитор плох. Мне просто трудно понять, почему людям это нравится. Когда я спрашивал людей, почему это лучше, чем Helm GKE, у них не было никаких убедительных ответов, несмотря на то, что они могут рассказать много историй о непредсказуемости композитора и множестве проблем.
Ответ №1:
Вы сравниваете одни и те же вещи?
С одной стороны, GKE, у вас есть оркестратор контейнеров. Объявите, что вы хотите, он будет развертывать и поддерживать стабильность кластера в соответствии с заявленной конфигурацией. Эта конфигурация может быть упакована с helm, чтобы записать ее в более простом режиме. Поскольку вы развертываете контейнер, вы можете использовать в своих службах тот язык, который вам нужен.
С другой стороны, у вас есть менеджер рабочих процессов с планировщиком, политиками повторных попыток, параллельной задачей, переадресацией контекста. вы пишете DAG на python (только!) и у вас есть операторы для взаимодействия с внешними продуктами / сервисами. Он в основном предназначен для обработки данных и часто используется специалистами по обработке данных и командой разработчиков данных.
Примечание: Cloud Composer развернут поверх GKE (планировщик и рабочий), redis, app engine и Cloud SQL.
Вы сравниваете 2 разных мира: операционный мир (GKE / Helm) и мир приложений / данных (Composer / Airflow). Посмотрите это новое видео
Обновление 1:
Виноват, я не понял!!! В любом случае, лично я не хочу управлять всем сам: кластером, обновлением K8S, исправлением виртуальных машин, репликами, моментальным снимком, резервным копированием / восстановлением…
Если кто-то может сделать это за меня, я предпочитаю, и управляемые сервисы идеально подходят для меня!!
Вы задаете себе этот вопрос об облачном SQL и базе данных, управляемых вами в экземпляре Compute Engine? Если нет (потому что облачный SQL решает много скучных проблем), мое мнение о Composer такое же.
Но это мнение, я не тестировал оба и не сравнивал производительность, стоимость и удобство.
Комментарии:
1. Спасибо за ответ. Я имел в виду сравнить то, что вы получаете от развертывания airflow с Helm GKE по сравнению с использованием Cloud composer.
2. Виноват… Я обновляю свой ответ, по моему мнению, без фактов