Как Managed Kubernetes помогает бизнесу управлять инфраструктурой

Рассказываем об особенностях монолитной и микросервисной архитектуры и как Managed Kubernetes помогает оптимизировать расходы на поддержку инфраструктуры.

Как Managed Kubernetes помогает бизнесу управлять инфраструктурой

Оглавление

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

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

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

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

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

Особенности монолитной архитектуры

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

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

Как Managed Kubernetes помогает бизнесу управлять инфраструктурой

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

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

Как Managed Kubernetes помогает бизнесу управлять инфраструктурой

На графике отражено примерное отношение стоимости кода по мере развития проекта: чем больше кода придется дописать в монолите, тем дороже окажется решение. В то же время, чем больше кода будет в микросервисах — тем меньше за это придется заплатить.

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

Чтобы перейти от монолита к микросервисам чаще всего применяется два подхода. Подход «большого взрыва» и поэтапный рефакторинг.

В «большом взрыве» все усилия сосредотачиваются на рефакторинге монолита. Внедрение новых функций на этот период приостанавливается.

Поэтапный рефакторинг гарантирует, что новые функции будут реализованы в виде современных микросервисов, которые могут взаимодействовать с монолитом через API-интерфейсы. При этом непосредственно в монолит код не интегрируется.

По мере модернизации продукта, функциональность монолита постепенно делегируется микросервисам.

Когда компания выбирает свой путь рефакторинга, важно учесть следующие аспекты:

  • Какие бизнес-компоненты отделить от монолита и превратить их в распределенные микросервисы.
  • Как отделить базы данных от приложения, чтобы отделить сложность данных от логики приложения.
  • Как протестировать новые микросервисы и их зависимости.

Особенности микросервисной архитектуры

В основе микросервисной архитектуры лежит принцип, что каждый микросервис — реализует свою бизнес-возможность. Его можно протестировать, развернуть или обновить, не затрагивая работу соседей. Такое разграничение полномочий обеспечивает высокую отказоустойчивость (при должной настройке) и открывает возможность контейнеризации приложений.

Как Managed Kubernetes помогает бизнесу управлять инфраструктурой

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

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

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

Оркестрация и Kubernetes

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

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

За 8 лет Kubernetes прошел путь от любопытного решения и сайд-проекта разработчиков из Google до настоящего бренда. Не будем проводить расследование, почему так получилось, но K8s оказался одновременно удобен и для разработчиков, и для бизнеса*.

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

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

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

Kubernetes как Managed Service

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

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

Доставка контейнеров должна идти по плану.
Доставка контейнеров должна идти по плану.

Managed Kubernetes от Selectel может облегчить работу многим компаниям, вне зависимости от их размеров:

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

Во вторую очередь, мы настраиваем K8s как систему с автохилингом кластеров. Это помогает избежать конфликта версий и «выгорания» контейнеров. Система отправляет на их место готовый контейнер, так что бизнес не страдает от даунтаймов даже в отдельных узлах.

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

Провайдер также несет ответственность за доступность кластера и занимается поддержкой актуальных версий самого K8s и компонентов.

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

Подпишитесь на блог Selectel, чтобы не пропустить новые обзоры, новости и кейсы из мира IT и технологий.

Читайте также:

1818
4 комментария

интересно было бы узнать на чем основывается ценообразование услуги

почти везде кубер в облаке стоит раза в 3 дороже голого железа в аренду, что немного иронично звучит на фоне того, как это выгодно и полезно для стартапов

это, конечно, круто, что не нужно ничего поднимать и настраивать, но по личному опыту это занимает пару дней-неделю на активное изучение и знакомство с технологией, но, так или иначе, даже с managed кластером придется разобраться с экосистемой кубера и писать свои конфиги и заниматься «черной» работой

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

Во вторую очередь, мы настраиваем K8s как систему с автохилингом кластеров. Это помогает избежать конфликта версий и «выгорания» контейнеров. Система отправляет на их место готовый контейнер, так что бизнес не страдает от даунтаймов даже в отдельных узлах.

это про стандартные настройки деплойментов типа количества реплик, лимитов и политик рестарта?

1
Ответить

Стоимость использования Managed Kubernetes мало чем отличается от стоимости самостоятельного разворачивания аналогичного кластера в облачной инфраструктуре. Разница в том, что Managed Kubernetes освобождает вас от задач по развертыванию и обслуживанию кластеров. Кроме этого, клиенты получают дополнительные инструменты для работы. Например, Selectel предоставляет собственный terraform-провайдер.

Что лучше: облачная инфраструктура или аренда физических серверов? С одной стороны, можно сэкономить на стоимости и получить гарантированную производительность железа, взяв в аренду физический сервер, а с другой — масштабируемость, отказоустойчивость и возможность оплачивать ресурсы по мере роста нагрузки.

Чтобы понять, как формируется стоимость Managed Kubernetes в Selectel, можно воспользоваться нашим калькулятором: https://selectel.ru/services/prices/.

Теперь про настройки.

Стандартные сеттинги deployment'a, в которых указано, сколько минимум реплик должно быть доступно при тех или иных операциях. При этих настройках K8s будет пытаться максимально оперативно держать нужное количество реплик. Но есть, например, процессы аварийного завершения нод и миграции. В таком случае реплики поднимутся, но некоторое время сервис может быть недоступен.

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

Ответить