Вы когда-нибудь пытались уследить за сотней одновременно крутящихся тарелок? С контейнерами в IT история похожая. Когда сервисов десять, их ещё можно запустить руками. А когда их сотни, а то и тысячи, ручное управление превращается в ад. Один контейнер упал, второй «съел» всю память, третий не может найти путь к четвёртому. И тут на сцену выходит оркестратор — главный дирижёр вашей инфраструктуры. Это софт, который берёт на себя развертывание, масштабирование, мониторинг и восстановление всей этой контейнерной братии. Хотите добавить десять новых копий сервиса в пик нагрузки? Пожалуйста, оркестратор сделает это за минуту без участия человека.
Но что, если ваша система разрастается до десятков физических серверов, разбросанных по разным облакам и дата-центрам? Управлять каждым кластером в отдельности — то ещё удовольствие. Тут на помощь приходит решение следующего уровня. Именно для таких сценариев и создан контейнерный оркестратор управления кластерами, способный дирижировать не отдельными контейнерами, а целыми роями машин. Это как если бы вместо управления каждым музыкантом вы отдавали приказы сразу всем секциям оркестра. Звучит мощно. Но давайте по порядку: из чего вообще состоит любой оркестратор и что он умеет.
Что умеет оркестратор: главные обязанности дирижёра
Сам термин «оркестрация» звучит красиво, но за ним стоит конкретный набор скучных, но критически важных рутинных задач. Их обычно шесть.
Первое — это умное размещение. Оркестратор видит все ваши серверы, знает, сколько на каждом свободной памяти и процессорного времени, и решает: какой контейнер куда запустить, чтобы никто не перегружался. Второе — масштабирование. Если на ваш онлайн-магазин в час-пик навалились тысячи покупателей, оркестратор автоматически добавит ещё десяток копий вашего приложения. Нагрузка упала — лишние копии свернутся. Третье — самовосстановление. Если контейнер упал (а в распределённых системах это происходит постоянно), оркестратор тут же запустит новый на его месте, часто даже без вашего ведома. Четвёртое — безболезненные обновления. Оркестратор умеет заменять старые версии контейнеров новыми так, чтобы ни один пользователь не заметил даже секундной задержки. Пятое — сетевое взаимодействие. Он настраивает сеть и балансировщики нагрузки, чтобы все части вашей системы находили друг друга и общались безопасно. И шестое — управление секретами. Пароли, ключи, токены оркестратор хранит в зашифрованном виде и аккуратно подкладывает только нужным контейнерам.
Три кита: Kuber, Swarm и их тихий конкурент
Глобально рынок оркестрации монополизировали несколько игроков. Есть общепризнанный король, есть его простой и быстрый кузен, а есть тёмная лошадка со своим подходом.
Король — это, конечно, Kubernetes или просто K8s. Он занимает около 82% рынка. Мощный, гибкий, с огромным комьюнити. На нём строят свои сервисы Google, Spotify, Airbnb и тысячи других. Но за мощь приходится платить сложностью. Чтобы освоить K8s, даже опытному системному администратору могут потребоваться месяцы. Его простой и шустрый кузен — Docker Swarm. Он встроен прямо в Docker, элементарен в настройке (до часа!) и идеален для небольших проектов, где не нужно городить огород из десятков компонентов. Правда, Swarm заметно уступает K8s в масштабах: если вам нужно управлять тысячами узлов и сложной маршрутизацией трафика, он быстро упрётся в потолок. А третья сила — HashiCorp Nomad. Это не просто оркестратор контейнеров, а универсальный планировщик, который умеет работать не только с Docker, но и с обычными приложениями, виртуальными машинами и даже пакетными заданиями. Он прост как Swarm, но гибок как K8s, поэтому его часто выбирают компании со смешанной инфраструктурой. Выбор между ними — вечный компромисс между функциональностью, простотой и спецификой ваших задач.
Когда оркестратор не нужен (и где его лучше не трогать)
Погоня за оркестрацией — тоже модная болезнь. Иногда разработчики запихивают в кластер проекты, которые отлично проживут на одном-единственном сервере. Признаки передозировки: у вас всего пара-тройка микросервисов, нагрузка предсказуема как расписание поездов, а в штате нет человека, который знает, что делать, если «подушка безопасности» K8s вдруг перестала качать. Оркестраторы сложны. Их настройка, обслуживание и мониторинг требуют квалификации и времени. Для маленького стартапа или внутреннего инструмента развернуть пару контейнеров через простой docker-compose на одном сервере будет в сотню раз быстрее и дешевле, чем поднимать полноценный кластер K8s. Кроме того, воркеры и мастера — это всегда накладные расходы. В маленьком кластере сам оркестратор может съедать заметный процент доступных ресурсов.
Будущее за многокластерностью
И всё же мы вернулись к началу. Если ваш бизнес растёт, рано или поздно мощности одного кластера станет мало. Причина может быть любой: требования закона о хранении данных в конкретной стране, желание не зависеть от одного облачного провайдера или необходимость держать вычисления ближе к пользователям по всему миру. Тогда на смену обычному оркестратору приходит многокластерный оркестратор. Это надстройка над обычными оркестраторами, которая управляет ими как единым целым. Вы просто говорите: «Мне нужно 50 копий сервиса в Европе и 30 в Азии», — а система сама раскидает нагрузку по кластерам, прокинув между ними безопасные сети. Karmada от Google, а также инструменты на основе Kubernetes Cluster Federation — вот кирпичики, из которых строятся подобные системы. Это уже высший пилотаж DevOps, но именно такая архитектура лежит в основе современных глобальных платформ вроде Netflix или Uber. И, возможно, уже завтра — в основе вашего бизнеса.
Иллюстрация к статье: