От микросервисного монолита к оркестратору бизнес-сервисов
Когда компании решают разделить монолит на микросервисы, в большинстве случаев они последовательно проходят четыре этапа: монолит, микросервисный монолит, микросервисы, оркестратор бизнес-сервисов.
Если вы определите, на каком из этапов находитесь сейчас, это поможет вам понять плюсы и минусы текущего этапа, оценить стоит ли идти на следующий этап и, если стоит, увидеть шаги необходимые для перехода.
В каждом разделе вы найдете ссылки для более глубокого погружения в нюансы конкретного перехода.
Этап №1. Монолит
1.1 Характеристики
Обычно монолитную архитектуру можно описать так:
1.2 Проблемы
1.3 Как перейти на следующий этап
В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. При этом нужно руководствоваться принципом единственности ответственности, который перефразируется так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.
Постепенно у вас образуется набор из микросервисов, где каждый отвечает лишь за свою бизнес-задачу:
При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.
Этап №2. Микросервисный монолит
2.1 Характеристики
Все части монолита стали независимыми микросервисами и эти микросервисы должны общаться между собой. Если раньше, находясь внутри одного процесса, сервисы вызывали методы друг друга напрямую, то теперь нужно интегироваться.
Из четырех способов интеграции в микросервисной архитектуре обычно не используют обмен файлами и стараются не использовать shared database, зато активно работают с RPC и очередью сообщений.
Получается, что все части монолита распались на микросервисы, а их обратно соединили паутиной синхронных и асинхронных интеграций:
По факту, получился тот же монолит, но с большим количеством новых проблем.
2.2 Проблемы
Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.
2.3 Как перейти на следующий этап
Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:
Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:
Этап №3. Микросервисы
3.1 Характеристики
Микросервисы ничего не знают о существовании друг друга: работают со своей базой данных, API и сообщениями в очереди. Каждый микросервис решает только одну бизнес-задачу и старается делать это максимально эффективно, за счет выбора технологий, стратегии масштабирования.
Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.
3.2 Проблемы
На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:
3.3 Как перейти на следующий этап
Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи могут решаться уже достаточно быстро и эффективно. Тем, кто решают двигаться дальше:
Этап №4. Оркестратор бизнес-сервисов
4.1 Характеристики
Оркестратор бизнес-сервисов обычно является визуальной платформой, где соединяются сервисы, выставляются триггеры и условия ветвления, контролируются все потоки данных: реализована трассировка запросов, логирование событий, автомасштабирование по условиям. Сам оркестратор ничего не знает о специфике бизнес-процессов, которые на нем крутятся.
На этом этапе можете решить задачу создания продукта в визуальном редакторе. Если нужных «квадратиков» не хватает, то программисты создают микросервис, учитывая правила описания сервиса для оркестратора, публикуют API и «кубик» появляется в визуальном редакторе, готовый соединяться с другими участниками бизнес-задачи.
4.2 Проблемы
4.3 Как перейти на следующий этап
На данный момент я не вижу сформировавшегося пятого этапа. Если вы видели жизнь после оркестратора бизнес-сервисов, буду рад увидеть описание вашего опыта в комментариях.
Заключение
Эти четыре этапа показывают, как мне кажется, естественный ход вещей:
Эволюция оркестратора микросервисов. Как переход на WebClient помог пережить пандемию
Типовая архитектура оркестратора
Классическая схема оркестратора для ритейла выглядит примерно так:
В общем, логика не бог весть какая, но она есть.
Варианты оптимизации
Прикрутить кэш
Распараллелить запросы
Как показывает практика, большинство времени подобного рода сервисы просто ждут ответа от их доменных коллег, так что если они могут «ждать» эти ответы не по очереди, а одновременно, то хорошая идея это организовать. Если мы берём стандартный сервер tomcat или undertow, то можно сделать так, чтобы каждый запрос, принимаемый сервером порождал N потоков, каждый из которых ходил бы за своим атрибутом, а поток-родитель потом это всё бы собирал и выплёвывал наверх.
Соединить запросы
Если до первых двух пунктов мы догадались в самой первой итерации сервиса, то до возможности соединять несколько запросов в один мы дошли не сразу.
Что имеется в виду: в сервис приходит массив основных продуктов и их атрибутов, по которым нужно собрать информацию. Помимо этого, к продуктам нужно подобрать рекомендации. Сервис рекомендаций, естественно, возвращает только список продуктовых id, которые также нужно обогатить своим набором атрибутов. Атрибуты эти, отличаются от атрибутов основного продукта и тоже приходят как параметр запроса нашего оркестратора.
Фактически, в оркестратор приходит список основных продуктов и 2 маски: одна для основных запрашиваемых продуктов, и вторая для продуктов, которые мы к ним рекомендуем:
Проблема в том, что список id основных продуктов мы знаем сразу, а за списком id продуктов-рекомендаций ещё нужно сходить. Возникает несколько вариантов того, как это сделать:
Вариант 1:
Идём с известными основными продуктами и их атрибутами по микросервисам собирать о них информацию;
Параллельно с этим, идём в сервис рекомендаций, который возвращает нам список id рекомендуемых продуктов;
После того, как сервис рекомендаций вернул список товаров, аналогично первому пункту, идём с уже другим набором атрибутов по сервисам и получаем всю необходимую информацию.
Тут 1 и 2 выполняются параллельно, 3 же придётся подождать первых двух. Как видно, число последовательных запросов: 2, что не так много, но, как показывает практика, проблема может заключаться в их количестве. Это то, что у нас было с самого начала, после этого мы сделали следующую оптимизацию:
Вариант 2:
Сначала идём в сервис рекомендаций и получаем id продуктов-рекомендаций;
После этого добавляем к основным продуктам рекомендованные товары, и к атрибутам основных товаров атрибуты товаров-рекомендаций, и уже со всем этим добром идём к доменным сервисам.
После того, как мы получили информацию по всем атрибутам общего списка товаров, нам нужно в памяти разделить этот список на основные и рекомендованные, и почистить лишние атрибуты т.к. клиенту необходимы разные наборы атрибутов у разного типа товаров, а мы от доменных сервисов получили всё.
Плюс ко всему, нужно понимать, что если раньше сервис рекомендаций, который, положа руку на сердце, является второстепенным для бизнеса, начнёт тормозить и отваливаться по таймауту, в первом варианте, мы сразу же возвращаем критичные для бизнеса данные наверх, во втором же, нам нужно сначала обрабатывать исключение, и поход за критичными данными произойдёт только после того, как мы увидим таймаут от сервиса рекомендаций. Т.е. это будет однозначно дольше.
Выводы:
Едем дальше
Итак, мы провели некие оптимизации, и да, сервис действительно стал держать больше нагрузки, но что делать, если этого всё ещё не достаточно?
Во-первых, сразу нужно сказать об ограничениях, которые у нас были.
Как показывает практика, это не оптимальный подход. Да, прирост производительности есть, но до для того, чтобы получить необходимые 60ms на 95-й персентиле нужно было этими инстансами прямо таки обмазаться, чего мы себе позволить не могли.
Время ответа при 5-ти и 8-ми инстансах оркестратора
Анализ проблемы
На самом деле проблему «как разогнать сервис до определённого rps?» можно переформулировать в вопрос «почему на нужном rps сервис не держит?». Для того, чтобы понять в чём проблема, даём нарастающую нагрузку, и, в момент когда сервису плохеет смотрим на состояние.
К сожалению, идея написать статью появилась после того, как мы решили проблему, по этому графики не сохранились, но, если в двух словах, мы увидели, что количество потоков постоянно росло и в какой-то момент garbage collector просто сходит с ума. Причём, ни увеличение возможного количества потоков, ни добавление памяти картину не меняло.
Чтобы разобраться почему так, давайте взглянем на то, что происходит с приложением при запросе:
рис 3. Путь запроса в undertow
Переход на неблокирующий подход
Чтобы понять в чём суть, мне бы хотелось привести аналогию с фастфудом
Вернёмся к нашему серверу
Вместо того, чтобы иметь кучу потоков, каждый из которых ничем полезным не занимается, ожидая ответа от сервиса, предлагается создать пул потоков, который будет состоять всего из 4-х (по количеству CPU) потоков, но которые постоянно будут заниматься полезной работой.
Потоки из этого нового пула будут принимать «заказы» на общение с сервисами моментально возвращать управление вместе с каким-то аналогом Future и избавляя от необходимости заказчика ждать.
Таким образом, наши потоки либо принимают заказы и отправляют запросы, либо в бесконечном цикле обходят порты, на которых ожидается ответ. Таким образом, они всегда при деле.
Ответ: можно, но нужно очень хорошо понимать что делаешь.
Как положить прод, если не любишь читать документацию.
Потоки WebClient (по умолчанию они зовутся reactor-http-epoll-число ), которые должны были постоянно работать оббегая каждый свой список портов, заблокированы.
Всё дело оказалось в методе CompletableFuture thenApply(work) который встретился у нас выше по стеку.
Этот метод, «докидывает» работы в текущий CompletableFuture на котором вызывается. И всё бы ничего, но у нас так получилось, что эта «работа» оказалась блокирующей.
Мораль же следующая:
Хэппи-энд
Тем не менее, после правок, всё завелось. После деплоя видим следующую картину:
Где-то на 17:26 произошёл деплой новой версии. Из графика видно что:
количество потоков сократилось больше чем в 4 раза (это сократилось количество потоков в CUSTOM_THREAD_POOL с 1000+ до 4-х);
потоки в статусе timed-waiting исчезли как класс;
Результаты по перфомансу превзошли все ожидания: 0 ошибок и 80 ms 75-й персентиль, при всего 4-х инстансах приложения.
Необходимая производительность в 60 ms на 95 персентиле достигается путём поднятия единственного дополнительного инстанса.
Выводы
Мы очень рады, что мы успели провести эту оптимизацию до пандемии. Именно переход на неблокирующий веб-клиент позволил нам фактически не заметить двукратное увеличение нагрузки во время локдауна, что для системы нашего размера не так уж тривиально.
Общие рекомендации по проектированию оркестраторов могут быть следующие:
Для начала следует задуматься о:
параллельном выполнении запросов;
Именно эти шаги могут уменьшить время ответа запроса.
Далее, использование неблокирующего клиента в микросервисах типа «оркестратор» позволяет повысить пропускную способность сервиса, экономя на тредах.
Именно повысить пропускную способность, т.е. те же результаты, но меньшими ресурсами. Однако, если у вас куча серверов, возможно, вам проще будет поднять побольше инстансов.
В конце концов, Вы же наверняка рассчитывали, что это решит ваши проблемы с нагрузкой, не так ли?)
Не советую использовать CompletableFuture и Mono/Flux в одном проекте. Анализ описанных в данной статье проблем при их появлении не тривиален. Как минимум потому, что их не так просто воспроизвести на тестовых стендах. А если используете, то используйте с умом.
В чём минусы подхода?
Kubernetes и другие оркестраторы
Привет! Меня зовут Леонид, я DevOps-инженер в компании KTS.
В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор.
Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах.
За небольшой срок в 4 года мы набрали много опыта. Начинали с вопроса, который, возможно, стоит сейчас перед вами: «Какой оркестратор выбрать?» Мы рассмотрели разные варианты, и в итоге остановились на Kubernetes. В статье расскажу, почему.
Что будет в статье:
Что такое оркестратор и какие задачи он решает
Наверняка многие слышали про микросервисную архитектуру.
Большинство микросервисов — это контейнеры, которые должны связно работать между собой. Кроме контейнеров, это могут быть обычные приложения: например, на Java или виртуальной машине.
Оркестратор позволяет управлять всем этим централизованно:
Что должно быть в хорошем удобном оркестраторе:
Возможность быстро начать работать, чтобы не тратить полгода на изучение и тестирование
Набор определенных возможностей из коробки:
управление секретами — передавать приложению пароли, токены, доступы к БД, а не хранить все в коде
service discovery — подключать новые реплики приложения к инфраструктуре
возможности кастомизации кластера — для добавления своих сущностей и организации API для наших целей
Наименьший vendor lock-in: когда разработчики завязывают покупателя на конкретную технологию, и переход от одного поставщика к другому сопровождается большими сложностями
Горизонтальное масштабирование: автоматическое масштабирование узлов кластера и приложения. Нагрузка может быть нелинейной, поэтому оркестратор должен уметь увеличить количество реплик приложения в процессе работы. Если в кластере не хватает ресурсов, нужно соответственное увеличение количества узлов кластера:
Вертикальное масштабирование: кластер управляет ресурсами, которые выделяются приложению. Выделять и ограничивать ресурсы необходимо, чтобы не столкнуться с такими ситуациями, когда одно из приложений съело всю память и CPU на наших серверах, а другим ничего не осталось. Оркестратор понимает, какие лимиты ресурсов есть у приложения на старте, и до каких оно может подниматься.
Разные стратегии обновления приложения. Приложения постоянно обновляются. Чтобы это проходило незаметно для пользователя и бизнеса, а сами обновления не ломались в процессе, оркестраторы имеют для этого разные стратегии:
Rolling — новая версия приложения выкатывается постепенно. Например, у нас есть 5 реплик приложения, которые постепенно заменяют исходное, пока, наконец, версия полностью не заменится на новую.
Recreate — достаточно простая стратегия, когда мы просто убиваем старую версию и раскатываем новую.
Blue/Green — мы выкатываем на стенды сразу 2 версии приложения: пока одна работает, вторая тестируется и со временем заменяет первую.
Canary (Dark) — достаточно похожа на Blue/Green, но с одной особенностью. Новая версия сначала выкатывается для ограниченного числа пользователей. В случае отсутствия проблем мы постепенно заменяем на новую версию все приложение.
Инфраструктура как код (IaC) с механизмами шаблонизации — удобная вещь, позволяющая хранить состояния приложения, описанные кодом, в каких-то манифестах. Удобно для инженеров и новичков. Когда в компанию приходит новичок, ему очень просто познакомиться с инфраструктурой и понять, где, что и как настроено. Все это удобно версионируется. Шаблонизация нужна, чтобы переиспользовать манифесты и не писать каждый раз одинаковые вещи. Например, мы подставляем разные значения в заготовленные шаблоны и меняем версии приложения:
Крупное сообщество — залог жизни технологии и разнообразия инструментов. Пока есть сообщество, мы понимаем, что технология будет жить.
Docker Swarm
Оркестратор, встроенный в Docker.
Архитектура и описание
Docker Swarm состоит из менеджеров и воркеров. Менеджеры определяют, на каких воркерах и как будут работать контейнеры, и хранят стек нашего кластера. Контейнер крутится на воркерах.
Минимальная рабочая сущность Docker — Service, который разбивается на task, в каждом из которых — Docker-контейнер:
Чтобы запустить какой-то Service, нам нужно:
запустить yaml-файл, который очень похож на Docker Compose. Отличие только в нескольких параметрах, характерных для Swarm. Например, replicas
выполнить команду, которая очень похожа на команду для Docker Compose
Плюсы
Нетребователен к ресурсам
Имеет Roling Back — возможность в случае проблем откатить приложение к предыдущей версии
Низкий уровень входа: прост в первоначальной настройке. Нужно запустить всего две команды:
1 — Для инициализации кластера:
2 — Для присоединения виртуальных машин к кластерам:
Минусы
Работает только с Docker-контейнерами.
Совершенно не поддерживает автоматическое масштабирование. Количество реплик приложения необходимо создавать руками в параметре replicas:
Поддерживает только одну стратегию обновления — Rolling Update.
Малая поддержка сообщества. Многие слышали фразу «Docker Swarm мертв». Технология непопулярна у специалистов, у нее малое количество готовых решений.
Язык манифестов мы пишем на yaml, но у Docker Swarm нет встроенной поддержки шаблонов.
Nomad
Оркестратор от компании HashiCorp.
Архитектура и описание
Достаточно похож на Docker Swarm:
Состоит из серверов, которые определяют, где и как живут объекты оркестрации, и клиентов, на которых эти объекты крутятся.
В отличие от сервисов в Docker Swarm, в Nomad мы создаем рабочие сущности job. Они, в свою очередь, состоят из task.
Чтобы создать job, мы пишем манифест и передаем его серверу, а он уже распределяет их по клиентам.
Шаблоны поддерживаются через consul-template.
Nomad полностью поддерживает всю экосистему HashiCorp:
Vault для хранения секретных паролей, токенов и прочего.
Consult для авто-discovery и dns.
Terraform для управления конфигурацией.
Еще одна особенность Nomad — он может управлять GPU-ресурсами вашего сервера, поэтому подходит для проектов типа machine learning.
Он может успешно существовать в симбиозе с Kubernetes. Вы даже можете запускать некоторые из его job прямо в Kubernetes.
У него есть Enterprise-версия: некоторые возможности платны. Например, масштабирование появилось совсем недавно и реализовано через плагины. Поддерживается оба вида горизонтального масштабирования, но вертикальное есть только в Enterprise:
Плюсы
Одно из главных отличий Nomad от других оркестраторов — он может оркестрировать не только Docker-контейнеры. И вообще не только контейнеры. Это могут быть и виртуальные машины, и бинарники Java, и даже Amazon Elastic Container Service.
Работает на всех популярных ОС.
Нетребователен к ресурсам — примерно как Docker Swarm.
Низкий уровень входа — прост в первоначальной настройке. Чтобы запустить, нужно:
Установить пакет Nomad.
Структурировать серверы: в основном нужно только указать адреса машин, на которых он будет работать.
Описывая job, в строке driver = “docker” мы запускаем Docker-контейнер и описываем какой-то config, связанный с Docker. Прелесть Nomad в том, что, поскольку он умеет запускать не только Docker-контейнеры, описание job практически не будет меняться. Например, вы запускаете какую-то job как systemd.service, или у вас Java-приложение. Вы описываете job и запускаете ее у себя на сервере. Если в какой-то момент вы решаете перейти на Docker, вам не нужно будет переписывать job глобально — только заменить driver и немного изменить структуру деплоя, но процесс описания манифеста останется.
Поддерживаются все популярные и нужные стратегии обновления, описанные в начале статьи.
Минусы
Малое количество возможностей из коробки:
Нет ни load balancing, ни автомасштабирования, ни возможности добавления кастомных контроллеров.
Малая поддержка сообщества. Чуть больше, чем у Docker Swarm, но все равно невелика. Хотя за рубежом Nomad довольно популярен.
Манифесты пишутся на малораспространенном среди инженеров языке HCL. Если вы хотите использовать Nomad, придется с ним познакомиться:
Kubernetes и Openshift
Kubernetes — открытый проект для оркестрирования контейнеризированных приложений.
OpenShift — семейство программных продуктов для контейнеризации, разработанное Red Hat.
Архитектура и описание
Эти оркестраторы мы сравниваем вместе, потому что «под капотом» Openshift находится Kubernetes.
Kubernetes ближе к понятиям фреймворка и технологии.
Openshift — скорее, готовая к использованию платформа.
Kubernetes родился в стенах Google и был передан в open source. Среди сегодняшних контрибьюторов разработки Kubernetes используют множество крупных компаний. Он работает на Linux и Windows.
Openshift работает исключительно на Red Hat Enterprise Linux. Имеет только Enterprise-версию с небольшим тестовым периодом. Помимо Kubernetes, там есть много других технологий: для доставки кода, мониторинга, сбора логов и т. д.
Способов установки Kubernetes очень много:
поставить руками, устанавливая бинарники Kubernetes на серверы, и самому решая вопросы с выпуском сертификатов и их обновлениями
передать это относительно автоматизированным инструментам, таким как kubespray и kubeadm
Способы установки Openshift тоже сильно различаются — в зависимости от того, где и как вы его разворачиваете.
У обоих есть утилиты для того, чтобы их можно было «потрогать». С помощью любой из них вы можете развернуть на своей машине полноценный кластер и посмотреть, что такое Kubernetes или Openshift:
Kubernetes: minikube, kind, k3s
Openshift: minishift
Архитектура обоих оркестраторов непростая.
В Kubernetes кластер состоит из узлов node и Control Plane, мастер-узла.
Control Plane включает в себя:
kube-api-server, это центральная точка входа для всех компонентов Kubernetes и людей, которые работают с кластером. Он предоставляет api для управления кластером
kube-controller-manager управляет контроллерами, например, node controller, который следит за node, или replica controller, который следит за количеством подов, развернутых в нашем кластере
kube-sheduler определяет, когда и на каком узле будет работать под
хранилище etcd, в котором хранятся состояния кластера в формате ключ-значение
cloud-contoller — его наличие опционально. Он следит за контроллерами определенного публичного или приватного облака
kubelet, который разворачивает и следит за контейнерами
kube-proxy, который занимается сетью: настраивает сеть и сетевые правила так, чтобы поды на разных узлах могли друг с другом общаться
Kubernetes предоставляет широкие возможности по масштабированию.
При вертикальном масштабировании мы можем определить request, количество ресурсов, которые будут даны приложению при старте, и лимиты, до которых оно может расширяться, затрачивая больше ресурсов.
По средней нагрузке Kubernetes может следить за репликами и узлами, добавляя или уменьшая их количество. Так же он работает в облаке, покупая или продавая узлы:
Минимальная рабочая сущность обоих оркестраторов — pod: контейнер, который может быть основан и на Docker, и на cri-o, и на containerd. Но это обязательно будет контейнер, в отличие от Nomad, который может оркестрировать виртуальные машины и много чего еще.
В поде необязательно будет только один контейнер. Их может быть несколько, и они будут делить между собой сетевое дисковое пространство.
Чтобы создать под, мы пишем простой yaml-файл и либо применяем его, либо запускаем из командной строки напрямую. Для управления Kubernetes используется довольно популярная утилита Kubetail.
С помощью операторов мы можем создавать свои сущности:
Для Postges мы описываем все необходимые параметры. Например, описываем размеры кластера, хранилища и указываем БД, которые создадутся у пользователей.
Из таблички видно, почему именно Kubernetes — стандарт в отрасли:
Плюсы
Просто запустить в публичных облаках.
Из коробки Kubernetes поддерживает только две стратегии обновлений: Rolling и Recreate. Но с помощью расширений в него легко можно добавить и Blue/Green, и Canary.
Поддерживает Rollback: следит за статусом пода и health-check — это команды, которые можно настроить, чтобы помочь Kubernetes лучше понимать, что происходит с приложением. В случае проблем он тоже откатится до предыдущей версии.
Kubernetes позволяет описывать свои манифесты на yaml и JSON. yaml предпочтительнее, им пользуется большинство.
С помощью пакетного менеджера Helm доступна достаточно продвинутая модернизация манифестов. Мы можем использовать циклы, редактирование строк и т. д.
У Kubernetes большое количество встроенных возможностей. Здесь есть все необходимое, что требуется от оркестратора, к тому же есть возможность постоянно расширять его возможности с помощью кастомного API, сетевых плагинов, инструментов для установки и управления кластеров и т. д.:
Kubernetes имеет развитое сообщество, очень заинтересованное в технологии. Можно решить практически любую проблему, или найти инженера, который будет работать с Kubernetes.
Одновременный плюс и минус Openshift — то, что платформа выбрана за вас. С одной стороны, можно сразу взять ее и пользоваться, а с другой — не факт, что она лучше всего подойдет именно вам. Возможно, придется ставить что-то рядом и пользоваться всем по частям. Поэтому тут присутствует vendor lock-in: переехать с Openshift на какой-то другой оркестратор будет достаточно проблематично.
Т.к. это Enterprise, у Openshift есть коммерческая поддержка. У Kubernetes ее нет, зато есть большое сообщество open source, хорошая подробная документация и множество статей и книг. К тому же огромный выбор технологий для пользователя.
Openshift предлагает встроенную поддержку шаблонов.
Минус
Оба достаточно сложны для самостоятельной установки.
Как начать использовать Kubernetes
Для начала есть несколько вариантов:
Очевидно, нужно просто начать его использовать.
Попробовать Managed-версии у разных облачных провайдеров.
Обратиться к компаниям, специализирующимся на эксплуатации k8s.
Пройти специализированные курсы по эксплуатации.
Заключение: как это было у нас
Очевидно, что уровень входа в Kubernetes или Openshift — выше, чем в какие-то другие решения. Но в конечном счете это выигрышный вариант. Когда мы выбирали оркестратор, в конце концов остановились на двух вариантах: Kubernetes или Nomad.
Недостатки Docker Swarm были очевидны, и было ясно, что в долгосрочной перспективе нам он точно не подойдет. Мы деплоим большое количество приложений, не связанных друг с другом в каких-то местах. Нам нужно dev-, stage- и prod-окружение, а оперировать этим с помощью Docker Swarm сложно.
Но у нас была уже существующая архитектура, в которой не использовался какой-то из оркестраторов. Мы пользовались SaltStack для деплоя приложений на наши сервера, т.е. устанавливали их в виде пакетов.
Мы думали, как перейти на другую технологию проще всего. В этом плане был очень привлекателен Nomad, потому что он может запускать на машине те или иные задачи. Мы думали: «Сейчас переведем деплой на Nomad, а потом, может быть, начнем использовать Docker-контейнеры и будем жить еще как-то».
Но подумав еще немного, мы пришли к выводу, что у Nomad много подвижных частей и не такое большое сообщество. Главные причины, по которым мы выбрали Куб, были:
better is included: в Kubernetes уже все есть и по большей части ничего не нужно додумывать. Естественно, есть большое количество вещей, которое нужно доделать в каждом кластере: для работы с tls-сертификатами, для более прозрачного удобного деплоя, может быть, service machine — все это не встроено, но существует большое количество уже разработанных решений.
Здесь нужно отметить организацию CNCF, которая продвигает контейнерные решения. У них есть инкубатор, где они развивают таковые. Одним из таких решений был сам Kubernetes: это первый проект, который выпустили CNCF. После этого были решения для управления CF-кластерами, Ingress Controller и еще много всего. И здесь очень важно, что есть огромная поддержка комьюнити и некоммерческая организация, которая управляет развитием контейнерных технологий. Есть много компаний, которые контрибьютят — как CNCF, так и Kubernetes. Поэтому мы решили, что это лучший выбор.
Переход был непростой. Многое нам пришлось написать с нуля, перевести все манифесты в Docker. Где-то за полгода мы перевезли все проекты на новую технологию. С тех пор мы живем в Kubernetes. Конечно, у нас есть отдельные серверы, связанные с какими-то БД, которые деплоятся отдельно, но сами приложения почти полностью живут в Kubernetes.
PS Среди способов «Как начать» мы упомянули про специализированные курсы. Здесь мы назовем только один.
«Деплой приложений в Kubernetes» — курс нашей школы Metaclass, который начнется 13 декабря и будет идти 7 недель. Курс достаточно интенсивный, потому что каждую неделю мы будем рассматривать довольной серьезный пласт информации: например, контейнеризацию, деплой приложений или CI/CD.
Приходите к нам учиться и расскажите в комментариях, с какими оркестраторами работаете вы? Есть ли плюсы и минусы, о которых мы забыли сказать?
