Системы оркестрации контейнеров: что такое и лучше для вашего проекта

Контейнеризация — популярный способ виртуализации приложений, который упрощает процесс развертывания готового продукта на стороне пользователя-клиента.

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

Поскольку контейнеры более компактны, ресурсоэффективны и портативны, чем виртуальные машины, они стали основными вычислительными единицами современных облачных приложений.

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

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

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

Можно кратко перечислить преимущества контейнеризации над любыми другими подходами организации кода:

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

Давайте также кратко перечислим список распространенных решений для контейнеризации:

• Docker
• Solaris Containers
• Nomad
• chroot
• iCore Virtual Accounts
• OpenVZ
• Virtuozzo Containers
• FreeBSD Jail

Все они имеют свои особенности — какие-то более универсальные, а какие-то созданы под конкретные задачи или ОС. Разумеется, самой популярной в этом списке является Docker.

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

Оркестрация поверх контейнеризации

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

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

Даже предприятиям «средней руки» необходимо управлять сотнями (если не тысячами) контейнеров, что без оркестрации просто невозможно. Исследования IBM сообщают, что более 72% разработчиков, использующих контейнеризацию, также используют и системы оркестровки. Особенно это касается DevOps-команд.

Описать разницу между контейнеризацией и оркестрацией довольно просто — если инструмент контейнеризации выполняет непосредственно само развертывание, то инструмент оркестрации лишь планирует это развертывание.

Кстати, объектом управления в оркестраторе может выступать не только контейнер, но и любой другой процесс или приложение.

При этом, оркестрация возможна в любой среде, будь то частный компьютер с «pet project-ом» или приватный (или публичный) облачный сервер частной компании. Хотя в некоторых случаях могут быть зависимости от операционной системы в том случае, если инструмент оркестрации более специфичен.

Что конкретно делают оркестраторы

Как и в случае с контейнеризацией, инструменты оркестрация основаны на декларативной модели конфигурации. Разработчик пишет специальный файл (YAML или JSON), после чего «скармливает» его системе оркестровки.

Далее инструмент оркестрации выполняет самостоятельное развертывание контейнеров, пытаясь привести приложение и его окружение к описанному состоянию. Как — решает он сам.

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

Итак, какие задачи ложатся на плечи системы оркестрации?

1. Поиск образов и запуск контейнеров

Система оркестрации находит все необходимые образы и создает из них контейнеры согласно конфигурационному описанию.

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

2. Обеспечение контейнеров ресурсами

Помимо менеджмента рабочих процессов (контейнеров) оркестратор также распределять дисковое пространство в рамках одного или нескольких приложений.

3. Конфигурация сети

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

4. Управление жизненным циклом контейнеров

Балансирует нагрузку и распределяет ресурсы между контейнерами. Управляет жизненным циклом контейнеров на основе ранее определенных спецификаций. Все это добавляет обширные возможности для разработки CI/CD-пайплайна

5. Перезапуск или остановка контейнеров

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

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

Несколько популярных инструментов оркестрации

Kubernetes

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

^{Схема архитектуры Kubernetes и его составных компонентов (взято с официального сайта)}

Фреймворк Kubernetes поделен на своего рода функциональные компоненты:

• Node (Узел). Служит хостом для среды, в которой выполняются контейнеры. Узлы могут быть как виртуальными, так и физическими — зависит от архитектуры конкретного приложения. Они же, будучи инкапсулированными сущностями, позволяют контейнерам коммуницировать друг с другом.
• Cluster (Кластер). Это узлы, объединенные в группу. Кластер имеет общие на все узлы ресурсы.
• Controllers (Контроллеры). Некие службы (агенты), выполняющие планирование и распределение ресурсов между кластерами, узлами и контейнерами.
• Labels (Метки). Своего рода теги, которые Kubernetes использует для идентификации контейнеров.

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

Вот пример того, как может выглядеть код внутри ConfigMag:

kind: ConfigMap 
apiVersion: v1 

metadata:
  name: example-configmap 

data:
  database: mongodb
  database_uri: mongodb://localhost:27017

keys: | 
    image.public.key=771 
    rsa.public.key=42

Разбор синтаксиса оставим за пределами этой статьи. Подробную информации об этом можно найти в официальной документации Kubernetes.

На основе Kubernetes реализовано множество как облачных PaaS-платформ, так и отдельных инструментов:

• Mirantis Kubernetes Engine
• Google Kubernetes Engine (GKE)
• Amazon Elastic Kubernetes Service (EKS)
• Red Hat OpenShift

Swarm

Swarm — это дополнительная функция управления демонами, идущая в комплекте с Docker. По сути, это полноценный оркестратор, идущий «из коробки», но в упрощенном исполнении.

Аналогично Kubernetes, Swarm использует декларативный подход к конфигурации. Доступны все стандартные для оркестратора функции: автоматизация, балансировка нагрузки, переносимость, масштабируемость, 

При использовании Swarm универсальные ноды делятся на два типа:

• Воркер (Worker). Непосредственно управляют контейнерами
• Менеджер (Manager). Управляют приложением, распределяя задачи по воркерам

При этом важно помнить, что Swarm работает только с контейнерами Docker — никакие другие он не поддерживает, в отличие от Kubernetes. Однако Swarm гораздо проще — инструмент доступен из того же терминала, что и сам Docker, а его быстродействие имеет преимущество над Kubernetes.

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

Apache Mesos

Mesos — инструмент оркестрации от Apache. Имеет открытый исходный код и обеспечивает неплохую коммуникацию между разными платформами, что очень важно в микро-сервисной архитектуре.

• Mesos отлично масштабируется — позволяет развернуть до 10 000 узлов одновременно
• Есть специальное API для Java, C++ и других языков
• Графический интерфейс помогает мониторить состояние контейнеров в наглядном виде

Сама компания Apache утверждает, что Mesos использовался в разработке ее собственных продуктов, таких как Aurora и Marathon & Singularity.

Red Hat OpenShift

OpenShift, созданная компанией Red Hat, расширяет функциональные возможности Kubernetes. Однако этот инструмент позиционируется как решение преимущественно для корпоративных клиентов.

По сути, это гибридная облачная PaaS-платформа на основе контейнеров Linux, но под управлением Kubernetes.

В OpenShift, в отличие от обычной Kubernetes, есть множество полезных шаблонов: базы данных, фреймворки, библиотеки, сервисы. По сути это оптимизированная платформа, которая стандартизирует множество производственных процессов и предоставляет их «из коробки».

^{Схема архитектуры Red Hat OpenShift (взято с официального сайта)}

В остальном функции аналогичные — умное управление рабочими нагрузками через контейнерную виртуализацию хостов.

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

У Red Hat есть отдельная страница со всем необходимым (в том числе и полноценной документацией) для быстрого старта в OpenShift.

Hashicorp Nomad

Nomad — это намного более компактная по сравнению с Kubernetes платформа оркестрации, которая, тем не менее, покрывает почти все потребности разработчиков. Она разделяет аналогичную философию Kubernetes, но поддерживает также и неконтейнерные рабочие нагрузки.

Например, использовать Kubernetes в небольших проектах (с небольшим количеством людей) может быть довольно дорого — как по времени, так и по деньгам.

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

Он прост и лаконичен, и с него легко перейти на любой другой более сложный инструмент.

Кому и когда использовать оркестраторы

Использование оркестрации в небольшом (возможно домашнем) проекте — дело хорошего вкуса. Однако лишний инструмент и лишняя сложность не всегда оправданы.

Управление более сложным инструментом, который в свою очередь сам управляет сложностью, может быть оправдано только в том случае, если «ручной» контроль контейнеров станет тяжелее, чем автоматический. А на первых порах (когда проект еще мал) так бывает не всегда, отчего издержки на использования оркестратора могут выше:

• нужна дополнительная экспертность по оркестрации (либо время, чтобы ее получить)
• нужны дополнительные специалисты, что влечет за собой финансовые расходы (если у вас нет экспертности — очевидно, она покупается)
• требуется больше серверных ресурсов

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

Однако если ваш проект достаточно большой (возможно, вы крупная компания), то контейнеров может быть очень много — точно больше 10, а то и 100. И приложение может быть не одно, а несколько.

При таком объеме не обойтись без оркестратора. Однозначно нужно использовать. Какой именно — вопрос поставленных задач и отчасти «вкусовщины». Понимание глубоких особенностей работы каждого из них, продиктованное в первую очередь опытом использования, поможет выбрать подходящий.

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

Заключение

Итак. Контейнеризация, являясь по сути способом виртуализации на уровне ОС, открывает возможности для высокой переносимости приложений. Тем не менее, контейнеризация автоматизирует развертывание только до определенного предела.

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

Самый популярный оркестратор — Kubernetes. Почти все разработчики используют именного его. Можно даже утверждать, что Kubernetes — своего рода стандарт (или эталон) системы оркестрации.

Однако, у того же Docker есть Swarm, доступный сразу «из коробки». Тем не менее полный список систем оркестрации довольно длинный — в нем не менее 20 позиций.

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

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