что такое оркестровка контейнеров

Что такое системы оркестрации контейнеров

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

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

Системы оркестрации контейнеров: что это и кому подходит

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

То есть программы-оркестраторы управляют жизненными циклами контейнеров микросервисных приложений. Но не только. Так как в разработке приложений все взаимосвязано, то системы оркестрации помогают еще автоматизировать различные производственные процессы, поэтому команды DevOps интегрируют их в CI/CD. Посмотрим, какие задачи берут на себя оркестраторы.

Задачи оркестраторов контейнеров

Это установка приложения и его зависимостей на сервер, включая подготовку этого сервера — установку библиотек, служб и так далее.

Это часть подготовки сервера, а именно его настройка с помощью специальных программ-планировщиков. Их применяют не только для микросервисных приложений, но и для монолитных. Инструменты управления конфигурацией обычно используют «факты», чтобы убедиться в достоверности данных о сервере: например, «убедитесь, что /etc/my.cnf содержит то-то…» или «NGinX должен работать со следующими файлами конфигурации». Оркестраторы содержат в себе такие планировщики, их не надо ставить отдельно.

Для развертывания приложения в продакшен-кластере требуется выделить вычислительные ресурсы сервера для различных процессов: это объемы памяти (RAM) и центрального процессора (CPU). Устанавливаются запрашиваемые и предельные параметры, правила при достижении контейнерами ресурсных лимитов, различные ограничения. Это важно для поддержания приложения в рабочем состоянии и сведения затрат к минимуму.

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

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

Чтобы приложение было доступно из интернета, нужно настроить правильное распределение трафика из внешней сети по контейнерам и нужным сервисам.

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

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

Несколько примеров систем оркестрации контейнеров

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

Kubernetes

Эта портативная платформа с открытым исходным кодом считается отраслевым стандартом. Поддерживает и декларативную конфигурацию объектов, и автоматизацию. Можно автоматизировать масштабирование, развертывание с помощью шаблонов и управление рабочей нагрузкой и сервисами контейнеров. Поддерживает ОС: Windows, macOS, Linux.

OpenShift Container Platform

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

Docker Swarm

Это «родная», базовая система кластеризации и оркестровки контейнеров Docker. Использует декларативную модель. Взаимодействие с кластером происходит через команды Docker, а управление действиями — через менеджер Swarm. Поддержка ОС: Windows, macOS, Linux.

Nomad

Легкий в поддержке, гибкий, расширяемый оркестратор для развертывания и управления контейнерными и классическими приложениями в физической или облачной среде. Поддерживает ОС: Linux, Windows, macOS, а также Docker, Java, виртуальные машины. В основном Nomad управляет деплоями и перезапускает контейнеры при обнаружении ошибок. Этого часто оказывается достаточно для небольших независимых проектов.

Rancher

Платформа для управления контейнерами в облачной или физической производственной среде с открытым исходным кодом. Включает в себя использование всех популярных на сегодняшний день фреймворков оркестровки и планирования контейнеров, в том числе Swarm, Kubernetes, Mesos. Помимо них поддерживает и собственную платформу оркестровки и планирования контейнеров — Cattle. Поддерживает ОС: Linux.

Кому пригодятся оркестраторы, а кому нет

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

Источник

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

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

Разворачиваем AKS

Заходим на портал Azure, нажимаем «Создать ресурс» и находим сервис под названием Kubernetes Service.

Выбираем имя и префикс DNS на свой вкус. Имя влияет на то, как вы будете обращаться к вашему кластеру, а вот префикс влияет на его FQDN адрес.

Самая недорогая виртуальная машина на данный момент стоит чуть более 30 долларов в месяц.

Вторым шагом предлагается создать service principal. Service principal это своеобразный сервисный аккаунт под которым могут выполнятся какие-то определенные задачи. Плюсы в том, что права такого аккаунта можно ограничить. Кроме того, можно создать любое количество подобных аккаунтов (в то время как количество обычных аккаунтов ограничено подпиской). Найти созданные аккаунты service principal можно в Active Directory среди App Registrations

RBAC (role-based access control) – это возможность ограничить или предоставить доступ к определенным ресурсам (или группам ресурсов). То есть вы сможете разграничить какие пользователи вашей подписки имеют права доступа, а какие не имеют.

На данный момент процесс занимает примерно минут 20, но все может зависеть от конфигурации.

Для работы нам понадобится командная строка Azure – CLI (Command Line Interface). Ее можно установить как под Windows, так и под macOS или Linux. Лично я предпочитаю использовать Azure Cloud Shell. Это командная строка, которая запускается из загруженной в браузер страницы портала Azure. Для работы она требует созданного blob хранилища. Его стоимость составит несколько центов в месяц и потому я предпочитаю не парится по поводу установки CLI на свою машину.

Kubernetes поддерживает различные технологии контейнеров, но давайте рассмотрим самую популярную – Docker. docker.hub позволяет хранить один приватный образ докера бесплатно. Если нужно больше, то можно разместить их за деньги. Но за деньги приватный образ докера можно разместить и в Azure Container Registry. Сейчас цены стартуют от 5-ти долларов в месяц (за базовый SKU).

Я создал сервис ACR под именем myservice. Если вы тоже решите воспользоваться ACR, то создав сервис вам необходимо будет получить его ключи.

Затем станет возможным залогиниться выполнив команду:

Ввести взятые с портала имя пользователя (myservice) и пароль (PJSeyO9=lCMRDI7dGkz68wjhFGRGxSY3)

Теперь зайдя в директорию с проектом, можно будет построить образ, одновременно пометив его нужным тегом. А после этого отправить его в облачный сервис:

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

При работе с развернутым AKS необходимо получить его креды. Иначе команды kubectl не будут выполняться. Для получения доступа к AKS выполняется следующая команда:

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

Для создания файла секрета необходимо выполнить команду такого вида:

Если ваш образ находится в репозитории докера, то значением будет https://index.docker.io/v1/

То есть чтобы создать секрет для контейнера в моем случае я выполнил:

Посмотреть содержимое созданного файла секрета теперь можно с помощью команды:

Если вы используете AKS, то можно не создавать файл секрета, а предоставить доступ сервису AKS к сервису ACR иным способом — выполнив особый скрипт. Взять его можно со следующей странички:

Можно просто модифицировать значения переменных AKS* и ACR*, затем скопировать скрипт и вставить его в Azure CLI или Cloud Shell.

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

Для того чтобы создать файл с настройками из командной строки нам сначала необходимо рассмотреть команды vi.

создаст файл, если он отсутствует или откроет существующий

Для того чтобы сохранить введенные изменения нажмите ESC и после этого ZZ

Для того чтобы просто выйти без сохранения ESC и после :q!

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

Итак, через Azure Cloud Shell создаете файл с произвольным названием (допустим, appsettings.json) и необходимым для вас содержимым. Допустим таким:

И после выполняете команду:

Эта команда создаст секрет с настройками под именем secret-appsettings
Узнать на какой путь заменить /home/youraccount вы можете с помощью команды pwd

Создание deployment

Deployments предназначены для stateless сервисов. Они описывают то, как Pods и ReplicaSets будут созданы и как они будут обновляться. Pod – это группа контейнеров (или же один контейнер), которые работают в одном окружении. Предназначением ReplicaSet является управление тем, что указанное количество pod будет запущено и будет постоянно работать.
Исходя из созданного ранее я создаю файл deploy.yaml который создаст 3 пода. Файл содержит следующий код (напоминаю, что пробелы в yaml очень важны):

Рассмотрим код. В начале описывается количество реплик и стратегия обновления. Затем деплойменту задается имя (myapp) и указывается ссылка на образ контейнера. Прописываются порты. 80 – это стандартный порт для http. Далее идут ASP.NET Core-овские настройки environment-а. Затем монтируются креды приватного образа докера и секретные настройки приложения, которые мы не так давно создавали.

Этот кусок отвечает за процесс обновления. maxSurge – количество подов создаваемых сверх существующих при обновлении (в штуках или процентах). maxUnavailable – максимальное количество подов, которые могут становится недоступными во время процесса обновления.
deployment можно создать с помощью команды:

Знакомьтесь — Ingress

Для того чтобы предоставить доступ к сервисам кластера и организовать балансировку нагрузки используется сервис под названием ingress. Довольно популярным решением является ingress созданный на основании nginx. Проще всего его установить используя пакетный менеджер Kubernetes, который называется helm. Плюсом Azure Cloud Shell является то, что helm уже в нее установлен. Что остается сделать для установки nginx-ingress. Ввести:

Подождать немного и выполнить:

Создание SSL сертификатов с помощью LetsEncrypt

Так как SSL сертификат привязывается к какому-то доменному имени, то зададим нашему ресурсу DNS имя.

Выполним следующую команду и возьмем внешний (external) IP

Подставим IP и придуманное нами имя для субдомена в следующий скрипт

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

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

Если бы у нас кластер был с RBAC, то скрипт был бы другим.

Если файл сертификата имеется в наличии, то можно его добавить как-то так:

Но так как у нас сертификата подписанного CA нет, то придется немного потанцевать с бубном. Мы создадим CA с помощью бесплатного сервиса под названием LetsEncrypt. LetsEncrypt это Certificate Authority, который выдает сертификаты совершенно бесплатно. Такая вот альтруистическая организация, целью которой является безопасный интернет.

Итак, создаем файл cluster-issuer.yaml Он описывает организацию выдавшую сертификат.

Вам необходимо только заменить e-mail на ваш адрес и можно выполнять:

Затем создаем файл сертификата certificate.yaml указав имя созданного ClusterIssuer и домен для которого предназначен сертификат — myservice-ingress.westeurope.cloudapp.azure.com

Создание сервиса и Ingress

В Kubernetes можно создавать сервисы четырех различных типов.
Сервисом по умолчанию является ClusterIP. Доступ к этому сервису возможен только из кластера по внутреннему IP.

NodePort автоматически создает сервис ClusterIP. Доступ к NodePort возможен извне по следующему маршруту :

Балансировщик нагрузки LoadBalancer предоставляет доступ к сервису извне, автоматически создавая сервисы NodePort и ClusterIP.

ExternalName связывает сервис со внешним именем.

Нам хватит базового сервиса:

Значением selector мы указываем имя нашего деплоймента.
Остается создать сервис

И в качестве заключительного этапа создаем ingress с которым я вас уже знакомил чуть выше в этой статье. В yaml мы укажем имя cluster-issuer и сертификата. Их мы создавали ранее.

Через какое-то время после создания ingress с помощью все той же команды kubectl apply, наш микросервис должен стать доступным по адресу https:// myservice-ingress.westeurope.cloudapp.azure.com. Кликнув на замочек в адресной строке браузера рядом с https можно убедиться, что сертификат валидный и выдан CA.

Напоминаем, что это полная версия статьи из журнала Хакер. Ее автор — Алексей Соммер.

Источник

Как жили до Kubernetes: сравниваем самый популярный оркестратор с другими решениями

Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

Критерии для сравнения

В статье я сравню Kubernetes с наиболее известными и часто используемыми системами оркестрации: Docker Swarm, Nomad, Apache Mesos и Fleet.

Для сравнения использую следующие критерии:

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

I. Docker Swarm vs Kubernetes

Docker Swarm — встроенное в сам Docker решение для управления контейнерами на физических или виртуальных машинах. Когда несколько хостов Docker используют режим Swarm, некоторые из них могут быть настроены как управляющие ноды, или менеджеры (Manager), а остальные — как рабочие ноды (Worker). Задача менеджеров — управлять кластером и делегировать задачи рабочим узлам.

1. Типы рабочих нагрузок

Если Docker Swarm предназначен для работы исключительно с Docker-контейнерами, то Kubernetes поддерживает несколько типов контейнеров: Docker, containerd, CRI-O и любое решение, придерживающееся стандарта CRI (Container Runtime Interface).

2. Легкость управления

По сравнению с Kubernetes Docker Swarm намного проще в установке вручную. Swarm работает поверх Docker, использует интерфейс его командной строки и легко интегрируется с Docker Compose. Kubernetes также может работать поверх Docker, но взаимодействовать с инфраструктурой в этом случае нужно будет при помощи двух разных утилит: Docker CLI и kubectl CLI.

Устройство Kubernetes на порядок сложнее. Он включает в себя множество компонентов: kube-api-server, kube-scheduler, kube-controller-manager, kube-proxy, kubelet — и поддерживает несколько типов установщиков для разных типов инфраструктур и задач: Kubeadm, Kops, Kubespray и так далее. Все это требует дополнительного обучения.

То есть порог вхождения в Kubernetes выше по сравнению с Docker Swarm. Но все, что связано непосредственно с администрированием контейнеров: deployments, доведение кластера до нужного состояния, добавление новых нод, — в K8s можно выполнить проще и быстрее. Также многие, поработав с обоими оркестраторами, отмечают, что Kubernetes более стабилен.

3. Требования к платформе для развертывания

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

4. Производительность

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

5. Ограничения на количество узлов и контейнеров в кластере

Kubernetes v1.20 поддерживает конфигурации, отвечающие следующим критериям:

В документации Docker Swarm даны рекомендации только по числу узлов-менеджеров — 7 штук. Максимальное число контейнеров будет определяться, скорее, ограничениями ОС, но пользователи Swarm советуют придерживаться похожих рекомендаций: 100 контейнеров на ноду.

6. Конфигурация как код

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

7. Шаблоны

В Docker Swarm нет шаблонизатора, аналогичного Helm в Kubernetes. Некий шаблонизатор приложений анонсировался в Docker Desktop Enterprise 3.0, но в настоящее время это решение не поддерживается.

8. Сети

С точки зрения сетевой модели Kubernetes смотрится предпочтительнее. Он работает с виртуальными сетями и поддерживает намного большее количество разных сетевых решений по сравнению со Swarm. Каждый под получает свой IP-адрес, что означает отсутствие необходимости сопоставления портов контейнера портам хоста. Kubernetes может работать с любым CNI-совместимым сетевым решением.

В Docker Swarm вы можете указать оверлейную сеть для своих служб. Менеджер будет автоматически назначать адреса контейнерам в оверлейной сети при инициализации или обновлении приложения. Однако некоторые пользователи жаловались на производительность нативной сети, советуя применять сетевые плагины вроде Calico.

9. Возможность обнаружения сервисов

Реализована в обоих оркестраторах с использованием встроенного DNS-сервера.

10. Автомасштабирование

В Docker Swarm автомасштабирование недоступно. Для каждой службы вы можете вручную указать количество задач, которые хотите запустить. Когда это число увеличивается или уменьшается, управляющий узел (Manager) автоматически адаптируется, добавляя или удаляя задачи для поддержания желаемого состояния.

В Kubernetes поддерживается автомасштабирование на основе наблюдаемого использования ЦП, памяти и ряда других пользовательских метрик. При этом масштабирование доступно на нескольких уровнях:

11. Выполнение обновлений и отката

И Kubernetes, и Docker Swarm поддерживают последовательные обновления (Rolling Update): во время развертывания вы можете постепенно применять обновления служб к узлам. В случае сбоя можно вернуться к предыдущей версии сервиса. Однако Kubernetes предоставляет возможность более гибкой настройки.

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

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

12. Отказоустойчивость

В обоих оркестраторах поддерживается высокая доступность приложений.

В Docker Swarm управляющий узел (Manager) постоянно отслеживает состояние кластера и согласовывает любые различия между фактическим состоянием и настроенным вами желаемым состоянием.

В Kubernetes службы балансировки нагрузки обнаруживают поды со сбоями и удаляют их. Используются проверки работоспособности (Health Check).

13. Мониторинг

Использование в Docker Swarm решений для логирования и мониторинга (ELK, Prometheus) возможно, как и в Kubernetes, но требует больше кастомных настроек или использования дополнительных наборов инструментов, таких как Swarmprom.

14. Безопасность

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

Однако Kubernetes все равно находится на шаг впереди, предлагая гибкую настройку сетевых политик (Network Policies), использование пространств имен (Namespaces) и прочие преимущества.

II. Nomad vs Kubernetes

Nomad — это оркестратор от компании HashiCorp для управления контейнерами и неконтейнерными приложениями. Основу его архитектуры составляют клиенты (Client), на которых можно запускать задачи, и серверы (Server), управляющие клиентами и задачами. Серверы выбирают лидера для обеспечения высокой доступности.

Рабочую нагрузку в Nomad определяет работа (Job), описывающая желаемое состояние кластера и состоящая из одной или нескольких групп задач. Задача (Task) — самая маленькая единица работы, которая выполняется драйверами (Docker, QEMU, Java и так далее). Обязанность Nomad — поддерживать соответствие между желаемым состоянием, описанным в Job, и фактическим состоянием кластера.

За консультацию по работе Nomad отдельное спасибо manefesto.

1. Типы рабочих нагрузок

В то время как Kubernetes ориентирован на использование контейнеров, Nomad работает с различными видами рабочих нагрузок. Он поддерживает виртуализированные, контейнерные и автономные, микросервисные и пакетные приложения, включая Docker, Java, Qemu и другие, полный список можно посмотреть здесь. Это позволяет оркестрировать не только контейнерами / виртуальными машинами, но и запускать приложения на нодах. Например, можно запустить на нодах тяжелые Java-приложения.

2. Легкость управления

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

Минимальный тестовый стенд можно поднять на хосте без использования сторонних утилит типа Minikube. Достаточно запустить Nomad в dev-режим, и он будет выполнять роль сервера/агента, чего вполне достаточно для локального тестирования.

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

K8s считается фреймворком для построения кластера, в то время как подход HashiCorp больше близок к UNIX-way. Настроить кластер Nomad под нужные требования можно с помощью внешних инструментов: Consul для обнаружения сервисов, Vault для управления конфиденциальной информацией и других. До определенного момента в Nomad не было возможности использовать внешние хранилища, сети, отличные от хостовых и Bridge, но сейчас есть поддержка плагинов CSI, CNI, появилась возможность использовать сети, хранилища так же, как это делает K8s.

В любом случае использовать Nomad несложно: по факту достаточно скопировать бинарный файл и создать Systemd-сервис, который работает в связке с Consul как Service Discovery.

3. Требования к платформе для развертывания

И Kubernetes, и Nomad могут быть развернуты в различных ОС: Linux, macOS, Windows. Однако Kubernetes требует различных настроек в зависимости от ОС — поэтому его установка, проводимая вручную, сложнее.

4. Производительность

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

5. Ограничения на количество узлов и контейнеров в кластере

Kubernetes поддерживает кластеры до 5 000 узлов и 300 000 контейнеров. В документации Nomad указано, что он масштабируется до размеров кластера, превышающих 10 000 узлов в реальных производственных средах. Также Nomad успешно участвовал в ряде напряженных тестов на масштабируемость: 1 миллион контейнеров в 2016 году и 2 миллиона контейнеров в 2020 году. Однако на практике вероятность применения настолько масштабных кластеров невелика.

6. Конфигурация как код

Kubernetes поддерживает декларативные развертывания на основе YAML-файлов. Nomad использует собственный язык описания конфигураций HashiCorp — HCL. То есть при использовании Nomad вам потребуется дополнительное обучение HCL. Но стоит отметить, что в Nomad присутствуют стандартные средства и команды для преобразования описаний из YAML и JSON в HCL (и обратно): yamlencode/yamldecode, jsonencode/jsondecode. Правда, работают они с определенными ограничениями, а некоторые в тестовом режиме.

7. Шаблоны

В Nomad нет инструмента для шаблонизации, аналогичного Helm для Kubernetes.

8. Сети

В плане организации сетей Kubernetes выглядит лаконичнее и стабильнее. В нем изначально была введена абстракция Pod, позволяющая запускать несколько контейнеров в одном сетевом пространстве, и использовался CNI (Container Networking Interface). Nomad же развивался от меньшего к большему и долгое время использовал исключительно хостовые сети без дополнительных слоев абстракции. Вместо Pod в нем использовались Job без возможности объединения контейнеров внутри них в единое сетевое пространство. Мультиинтерфейсные сети и возможность подключения CNI стали развиваться в Nomad относительно недавно. Можно подключить CNI-плагин для использования Calico, Cilium, Weave.

9. Возможность обнаружения сервисов

В отличие от Kubernetes, в Nomad нет Autodiscovery на основе DNS. Для обнаружения сервисов необходимо использовать дополнительный инструмент Consul. В этом Nomad сильно уступает Kubernetes. И многие считают это одной из основных причин, почему Nomad оказался менее востребован в свое время.

10. Автомасштабирование

Общая черта двух оркестраторов — поддержка следующих типов автомасштабирования:

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

11. Выполнение обновлений и отката

Оба оркестратора предоставляют возможность гибкого управления обновлениями, включая стратегии последовательного (Rolling update), сине-зеленого (Blue and Green) и канареечного (Canary) обновлений. Для настройки доступен целый ряд показателей, влияющих на ход обновлений, включая временные интервалы для проверки работоспособности и прочее.

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

12. Отказоустойчивость

По умолчанию поведение у обеих систем схожее. В Kubernetes дается минута на определение узла со сбоем и до пяти минут на вытеснение подов на другую ноду. В Nomad примерно такие же дефолтные показатели. Но в Kubernetes с использованием опций kubelet и Control Manager реально добиться того, чтобы уже в течение 10 секунд поды были вытеснены на другую работоспособную ноду.

13. Мониторинг

Оба оркестратора совместимы с популярными инструментами логирования и мониторинга: ELK, Prometheus/Grafana и прочими. Ведется сбор метрик, которые можно получить впоследствии через API либо настроив автоматическую пересылку стороннему провайдеру.

14. Безопасность

Основное, в чем проигрывает Nomad в плане безопасности, — это необходимость использования сторонней системы Vault для управления конфиденциальной информацией (логинами и паролями). Хотя безопаснее Vault на современном рынке Open Source-решений, пожалуй, нет — его настройка и использование совместно с Nomad является довольно сложной задачей. Коробочный Kubernetes в этом отношении проще, так как может предложить встроенное решение.

В Kubernetes по умолчанию поддерживаются пространства имен (Namespaces), которые можно эффективно использовать для разделения сред разработки. В Nomad данная функциональность ранее была доступна только в Enterprise-версии, а в Open Source-версии — доступна с Nomad 1.0.

III. Apache Mesos (+ Maraphon, Aurora) vs Kubernetes

Apache Mesos — это менеджер кластера, поддерживающий различные рабочие нагрузки. Основу архитектуры Mesos составляют мастер (Mesos Master), агенты (Mesos Agent), работающие на каждом узле кластера и управляемые мастером, и фреймворки (Mesos Frameworks), которые запускают задачи на агентах. Обычно разворачивается несколько резервных мастеров, готовых взять на себя управление в случае сбоя, а за выбор лидера среди них отвечает ZooKeeper.

Фреймворк состоит из двух компонентов: планировщика (Scheduler), он регистрируется на главном сервере, которому будут предлагаться ресурсы, и исполнителя (Executor), который запускается на узлах агентов для выполнения задач фреймворка. Мастер предлагает ресурсы агентов фреймворкам, а планировщики выбирают, какие из предложенных ресурсов использовать для запуска своих задач на агентах. В кластере Mesos может работать несколько фреймворков для разных типов задач.

То есть сам по себе Apache Mesos является лишь неким диспетчером, а конечная функциональность будет определяться используемым фреймворком. Поэтому при описании показателей будем иногда ссылаться на два конкретных фреймворка: Maraphon для управления контейнерными приложениями и Apache Aurora для планирования Cron-заданий и долго работающих служб. Aurora больше не поддерживается, но в свое время была довольно распространена и в том числе могла использоваться для контейнерных приложений. Также иногда будем упоминать Mesosphere DC/OS — операционную систему, основанную на Apache Mesos, Maraphon и предлагающую ряд дополнительных возможностей (правда, часть из них доступна в платной версии).

1. Типы рабочих нагрузок

Apache Mesos предназначен для обработки различных типов рабочих нагрузок, которые могут быть как контейнерными, так и неконтейнерными. В качестве планировщика заданий (Scheduler) могут быть использованы, например, Hadoop (Big Data), MPI (обмен сообщениями), Jenkins (система непрерывной интеграции). Используя Apache Mesos, можно разработать даже собственный планировщик.

Kubernetes ориентирован исключительно на контейнерные приложения.

2. Легкость управления

Apache Mesos проще развернуть, чем Kubernetes, если мы говорим о ручной установке. Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как необходимо работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее. Kubernetes с Golang в этом плане проще.

3. Требования к платформе для развертывания

Mesos работает на Linux и macOS. Агенты могут быть установлены и на Windows.
Kubernetes также поддерживает все ОС.

4. Производительность

Mesos изначально был ориентирован на работу с Big Data — поэтому по производительности он опережает Kubernetes.

5. Ограничения на количество узлов и контейнеров в кластере

По масштабируемости Apache Mesos выигрывает у Kubernetes, так как способен поддерживать десятки тысяч узлов (K8s рассчитан на 5 000 максимум). Когда Mesos сочетается с Mesosphere DC/OS, получается платформа, предлагающая практически неограниченную масштабируемость, которая идеально подходит для больших систем. Разработчики заявили, что прекратили ее развитие, но существующих клиентов продолжают поддерживать. Еще в 2015 году Mesos с успехом выдержал тест на масштабирование до 50 000 узлов.

6. Конфигурация как код

В Apache Mesos в сочетании с Maraphon можно использовать определения JSON (для указания репозиториев, ресурсов, числа экземпляров и команд для выполнения). В Kubernetes для этой цели поддерживаются декларативные развертывания и в YAML, и в JSON (первый предпочтительнее).

7. Шаблоны

Если вы работаете в Mesosphere DC/OS, то можете использовать шаблоны конфигураций (с использованием Maraphon-LB). В Apache Aurora при настройке услуг в DSL также были доступны шаблоны во избежание дублирования конфигураций. Но Helm, используемый в K8s, будет более мощным и удобным инструментом.

8. Сети

Долгое время Apache Mesos отставал от Kubernetes в плане сетевой реализации, так как по умолчанию в нем не назначались IP-адреса контейнерам, требовалось проведение сопоставления портов контейнера с портами хоста, которые являются ограниченным ресурсом. Впоследствии была добавлена поддержка CNI (Container Networking Interface) и появилась возможность использования виртуальных сетей вида Calico, Cilium, Weave. Но в Kubernetes сейчас поддерживается большее число сетевых решений.

9. Возможность обнаружения сервисов

Присутствует в обеих системах.

Mesos-DNS обеспечивает обнаружение служб и базовую балансировку нагрузки для приложений. При использовании совместно с Marathon дополнительно доступен Marathon-LB для обнаружения на основе портов с помощью HAProxy. В Aurora была также представлена экспериментальная поддержка Mesos DiscoveryInfo — для создания настраиваемой системы обнаружения без использования ZooKeeper.

В Kubernetes доступен встроенный DNS-сервер.

10. Автомасштабирование

Реализация автомасштабирования лучше в Kubernetes. Как уже отмечалось выше, доступны три стратегии: масштабирование кластера, горизонтальное масштабирование подов и вертикальное масштабирование подов. В качестве триггеров можно настраивать показатели ЦП, памяти и пользовательские показатели.

В Apache Mesos автомасштабирование доступно в комбинации с Maraphon (в Mesosphere DC/OS) — на основе значений ЦП, памяти и числа запросов в секунду.

11. Выполнение обновлений и отката

Поддерживается в обеих системах. Сине-зеленое (Blue and Green) развертывание доступно в Apache Mesos, также его можно реализовать в Kubernetes, используя встроенные механизмы.

12. Отказоустойчивость

Обе системы отказоустойчивы.

В Apache Mesos экземпляры приложений распределяются по агентам, обеспечивая высокую доступность. Кроме того, ZooKeeper поддерживает доступность кластера через кворум и выборы лидера.

Аналогично поды в Kubernetes реплицируются на несколько узлов. Обычно кластер Kubernetes состоит из нескольких рабочих узлов. В нем также может быть несколько мастеров.

Кроме этого, оба оркестратора предоставляют проверки работоспособности (Health Check). Для Mesos они доступны в случае использования Mesosphere DC/OS.

13. Мониторинг

И в Mesos, и в Kubernetes доступно получение метрик, относящихся к работоспособности и другим показателям. Данные можно запрашивать и агрегировать с помощью внешних инструментов. Типичной практикой является развертывание ELK и Prometheus + Grafana.
Но подключение мониторинга в Kubernetes происходит проще, так как многое строится на готовых решениях благодаря поддержке многочисленного сообщества и богатому инструментарию. В Mesos многое приходится делать самостоятельно, вследствие чего неизбежно увеличивается Time to Market.

14. Безопасность

Сложно отдать кому-то предпочтение. Если говорить об Apache Mesos в связке с Maraphon или Aurora вне Mesosphere DC/OS, то Kubernetes выглядит лучше. Долгое время Mesos не мог предложить в плане безопасности практически ничего. Так, встроенное решение по работе с секретами не имело в нем надлежащей реализации, и пользователи предпочитали использовать сторонние инструменты, например Vault.

Но если обратиться к ОС DC/OS Enterprise — сегодня она предлагает богатый функционал в плане корпоративной безопасности, возможно, даже лучший, чем в Kubernetes. Однако эта версия системы является платной, кроме того, ее развитие свернуто разработчиками в пользу новой платформы на основе как раз Kubernetes.

IV. Fleet vs Kubernetes

Fleet — это низкоуровневый кластерный движок от CoreOS, похожий на распределенную систему инициализации. В настоящее время он не поддерживается, так как компания стала активно продвигать Kubernetes.

Fleet был основан на systemd. В то время как systemd обеспечивал инициализацию системы и служб на уровне одной машины, Fleet расширил этот процесс до кластера. В архитектуре Fleet на каждой машине запускался fleetd-демон, обеспечивающий две роли: движок (Engine) и агент (Agent). Движок принимал решения по планированию, а агент обрабатывал Systemd Unit-файлы (Unit). Эта обработка чаще всего сводилась к запуску контейнера.

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

1. Типы рабочих нагрузок

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

2. Легкость управления

Установка Fleet проводилась значительно проще и быстрее по сравнению с Kubernetes. Чтобы запустить свои службы в кластере, необходимо было отправить обычные модули systemd в сочетании с несколькими свойствами, специфичными для Fleet. То есть для управления кластером было достаточно знаний по работе с systemd.

3. Требования к платформе для развертывания

Fleet изначально разрабатывался на базе CoreOS. Kubernetes в настоящее время поддерживает практически все виды ОС.

4. Производительность

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

5. Ограничения на количество узлов и контейнеров в кластере

Fleet уступал по масштабируемости. В последней версии продукта не рекомендовалось запускать кластеры более 100 узлов или с более чем 1000 служб. Kubernetes сейчас поддерживает до 5 000 узлов и 300 000 контейнеров в кластере.

6. Конфигурация как код

В документации Fleet отсутствуют данные о возможности загрузки определений приложений из YAML или JSON, доступной в Kubernetes. Но формировавшиеся представления сохранялись в etcd в формате JSON. Также Fleet предоставлял API для управления состоянием кластера с использованием JSON: создание и удаление модулей, изменение желаемого состояния, вывод списка модулей.

7. Шаблоны

Fleet поддерживал несколько простых шаблонов развертывания на основе настраиваемых параметров модуля systemd. В них, например, можно было использовать определения места запуска контейнеров (Affinity и Anti-Affinity), похожие на селекторы Kubernetes. Однако используемый в Kubernetes шаблонизатор Helm — более мощный инструмент.

8. Сети

Fleet — это низкоуровневое решение, и его нельзя сравнивать с K8s в плане организации сетей.

9. Возможность обнаружения сервисов

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

10. Автомасштабирование

В документации Fleet не описана возможность автомасштабирования.

11. Выполнение обновлений и отката

Fleet не поддерживал последовательные обновления, в отличие от K8s: новые модули (Units) планировались, а старые уничтожались вручную.

12. Отказоустойчивость

Обеспечивается в обоих оркестраторах. Архитектура Fleet разработана так, чтобы быть отказоустойчивой: если машина выходила из строя, любые запланированные на ней задания (Unit) перезапускались на новых хостах.

13. Мониторинг

Fleet уступал Kubernetes по возможностям мониторинга. Он поддерживал в экспериментальном режиме получение незначительного количества метрик в формате Prometheus. О возможности использования других инструментов логирования и мониторинга (ELK и прочее) в документации не сказано.

14. Безопасность

Fleet как низкоуровневое решение предлагал меньше возможностей в плане безопасности по сравнению с K8s. Например, он не поддерживал контроль доступа (Access Control List, ACL): все, кто имели доступ к etcd, могли управлять Fleet. Также в нем не было инструментов для управления конфиденциальной информацией (логины и пароли).

V. Преимущества и недостатки систем оркестрации

1. Docker Swarm

Для каких задач подходит: в небольших проектах, где предпочтение отдается простоте и быстрой разработке.

2. Nomad

Для каких задач подходит:

3. Apache Mesos (+ Maraphon, Aurora)

Для каких задач подходит:

4. Fleet

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

5. Kubernetes

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

Как перейти на Kubernetes с других оркестраторов

Предположим, вы использовали одно из рассмотренных решений и задумались о переходе на Kubernetes.

Что теперь предпринять?

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

Перепишите манифесты на YAML Kubernetes. Сложность операции будет определяться их количеством и особенностями прежнего оркестратора:

Разверните Kubernetes, вспомогательную инфраструктуру и настройте свой кластер. Если у вас нет команды, способной справиться с непростой задачей ручной установки, то можно использовать одно из готовых (Managed) решений. Их провайдеры не только предлагают услуги по развертыванию кластеров Kubernetes, но и оказывают дальнейшую техническую поддержку, а также могут помочь с миграцией (например, с Docker Swarm). В результате вы получите готовый кластер за считаные минуты и все преимущества Cloud Native-приложений.

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

Чек-лист: на что обратить внимание при выборе провайдера Kubernetes

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

Так, KaaS от Mail.ru Cloud Solutions «из коробки» включает:

Совместимость со стандартными инструментами Kubernetes. Нужно проверить, поддерживает ли провайдер интеграцию с другими приложениями экосистемы K8s, например:

Возможность подключения других сервисов провайдера. Обратите внимание на дополнительные решения провайдера и возможность их использования в своих кластерах. KaaS от MCS позволяет подключить объектное хранилище (Cloud Storage) и DBaaS для хранения данных Stateful-приложений, а также его легко совместно использовать с другими PaaS, например Cloud Big Data. Например, централизованно разворачивать нужные сервисы и управлять ими на одной платформе.

Сертификация CNCF. Подтверждает то, что сервис отвечает всем функциональным требованиям сообщества Cloud Native Computing Foundation (CNCF) и совместим со стандартным Kubernetes API. MCS — пока единственный в России облачный провайдер, получивший такую сертификацию.

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

Выводы: сравнительный анализ систем оркестрации

Результаты сравнения Kubernetes и других известных оркестраторов наглядно демонстрирует таблица ниже:

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

Источник