Привнесение хорошего опыта OSS в Kubernetes DevOps

Эта статья была первоначально опубликована в блоге CNCF.

В настоящее время открытый исходный код находится на перепутье. 97% стеков данных содержат код с открытым исходным кодом. Однако развертывание и управление приложениями с открытым исходным кодом является утомительным и трудоемким.

Возьмем, к примеру, такой продукт с открытым исходным кодом, как Apache Airflow. Популярная система управления рабочими процессами имеет более 26 тысяч звезд на Github и используется более чем 14 тысячами компаний. В настоящее время разработчики единодушно считают, что нужно самостоятельно развернуть свой собственный экземпляр Airflow на Kubernetes.

Звучит просто, верно?

Настройка и управление Airflow на Kubernetes может быть сложной задачей, особенно если у вас мало инженерных ресурсов или вы никогда не развертывали Airflow на Kubernetes. Сам Airflow — это сложное приложение с состоянием, состоящее из базы данных SQL и кэша Redis. Каждый из этих компонентов технически сложен, и компании, которые в конечном итоге используют Airflow, обычно выделяют отдельного инженера для эффективного масштабирования Airflow и обеспечения его постоянной работоспособности.

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

В этом посте мы обсудим:

  • Зачем использовать Kubernetes для развертывания стека данных?
  • Три ограничения, с которыми сталкиваются организации при развертывании приложений с открытым исходным кодом на Kubernetes
  • Решение трех проблем DevOps.

Зачем использовать Kubernetes для развертывания стека данных?


Развертывание стека данных на Kubernetes — это текущий консенсус для профессионалов DevOps. Фото: Остин Чан / Unsplash

За последние несколько лет я наблюдаю резкое увеличение числа компаний, предпочитающих развертывать свои стеки данных с помощью Kubernetes. На протяжении всей моей карьеры инженера, которая включает в себя работу в Amazon и Facebook, я занимался масштабированием приложений с открытым исходным кодом в полностью самоуправляемом режиме.

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

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

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

  1. Экономия затрат: На мой взгляд, самым большим преимуществом является экономия средств, которую получают организации, особенно когда они начинают развиваться как бизнес. Крупные организации, использующие масштабную инфраструктуру, могут реально сократить свои расходы на облако на сумму до миллиона долларов в год. Я также видел невероятную экономию средств, особенно в паре с уровнем управляемого обслуживания. Покупка решения с управляемым обслуживанием часто сопровождается 40-процентной наценкой на вычисления. При больших объемах пакетной обработки эти затраты быстро возрастают.
  2. Более простая модель безопасности: Все работает в защищенной сети, не беспокоясь о конфиденциальности и соответствии нормативным требованиям. Возможность обеспечить строгое соответствие нормативным требованиям и конфиденциальность вокруг аналитических пакетов продуктов особенно полезна, когда компании начинают говорить о GDPR и CCPA, которые сложно обеспечить в масштабах всей страны.
  3. Операционная простота при масштабировании на несколько решений: В большинстве случаев разработчикам, скорее всего, придется использовать несколько технологий для решения своей задачи. Для чего-то вроде стека данных можно рассмотреть Airbyte с другими решениями, такими как Superset, Airflow и Presto. Но это сложно и требует много времени для эффективной работы. Если они намерены запускать все эти приложения вместе, то модель Kubernetes с самостоятельным хостингом становится весьма эффективной, поскольку объединяет все приложения в единую среду. Разработчики могут создать единый опыт управления с веб-интерфейсом поверх него. Другим преимуществом является унификация процесса обновления приложений. Сложность, связанная с обновлением такого инструмента, как Kubeflow, требует большого количества зависимостей на уровне Kubernetes. Эти зависимости могут конфликтовать с развертыванием такого приложения, как Airflow, которому требуется что-то похожее на K9 или Istio под капотом. С единой платформой этот процесс упрощается, разработчики могут легко выполнить проверку зависимостей всех приложений и убедиться, что они могут быть обновлены в любой момент времени.

Три ограничения, с которыми сталкиваются организации при развертывании приложений с открытым исходным кодом на Kubernetes


Разработчики, развертывающие приложения с открытым исходным кодом на Kubernetes, обычно сталкиваются с этими тремя общими ограничениями. Фото Mike Szczepanski / Unsplash

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

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

  1. Приложения должны быть адаптированы к каждому конкретному облаку. Мне стало совершенно ясно, что решение проблемы настраиваемости облака так же сложно, как и проблема управления кодом. Каждое облако имеет свои собственные сервисы, API и соглашения, что заставляет разработчиков ориентироваться в нескольких наборах документации в зависимости от поставщика облака.
  2. Запуск приложений непосредственно на Kubernetes является глубоко настраиваемым. Это, как правило, препятствует получению функционального опыта «из коробки», чего не могут добиться большинство устаревших инструментов и облачных провайдеров. А решение такой сложной проблемы собственными силами — дело хлопотное, особенно если у вас и так мало инженерных ресурсов.
  3. Управление жизненным циклом приложений является сложной задачей. Как и решение проблемы настраиваемости облака, управление жизненным циклом приложений — чрезвычайно сложный процесс. На своем опыте я убедился, что некоторые приложения легко установить, но сложно ими управлять, что приводит к возникновению технического долга.

В настоящее время унаследованные ограничения не позволяют всем основным поставщикам облачных услуг (Amazon, Google, Microsoft) сделать это правильно, поскольку им необходимо защищать свой основной облачный бизнес. Основная технология, необходимая для решения этой проблемы, существует, но не является легкодоступной и не предлагается на открытом рынке в целостном виде.

Решение трех ограничений DevOps

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


Как Plural решает три распространенных ограничения DevOps. Изображение любезно предоставлено CNCF.

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

С Plural вы также можете:

  • устанавливать готовые пакеты приложений с открытым исходным кодом с помощью одной команды
  • Добавлять аутентификацию/SSO в свои приложения с открытым исходным кодом
  • Развертывать и управлять развертываниями Kubernetes с минимальным предварительным опытом
  • Использовать рабочий процесс GitOps с включенным в батарею прозрачным секретным шифрованием.

Если вам интересно узнать больше о Plural, все, что мы создали, является открытым исходным кодом, так что не стесняйтесь проверить это на нашем GitHub. Если на рынке Plural есть приложение с открытым исходным кодом, которое вам нужно, мы призываем вас внести свой вклад в экосистему Plural, следуя нашей документации, в которой описано, как это сделать. Самое главное, мы стремимся сделать инфраструктуру Kubernetes простой в развертывании для всех, способствуя развитию сообщества инженеров-самоучек, работающих с открытым исходным кодом.

Оцените статью
devanswers.ru
Добавить комментарий