Что такое оркестратор ит
Для обеспечения балансировки нагрузки, масштабируемости и повышения отказоустойчивости могут использоваться вспомогательные средства — оркестраторы. Среди них большой популярностью сейчас пользуется сервис 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.
Напоминаем, что это полная версия статьи из журнала Хакер. Ее автор — Алексей Соммер.
От микросервисного монолита к оркестратору бизнес-сервисов
Когда компании решают разделить монолит на микросервисы, в большинстве случаев они последовательно проходят четыре этапа: монолит, микросервисный монолит, микросервисы, оркестратор бизнес-сервисов.
Если вы определите, на каком из этапов находитесь сейчас, это поможет вам понять плюсы и минусы текущего этапа, оценить стоит ли идти на следующий этап и, если стоит, увидеть шаги необходимые для перехода.
В каждом разделе вы найдете ссылки для более глубокого погружения в нюансы конкретного перехода.
Этап №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 Как перейти на следующий этап
На данный момент я не вижу сформировавшегося пятого этапа. Если вы видели жизнь после оркестратора бизнес-сервисов, буду рад увидеть описание вашего опыта в комментариях.
Заключение
Эти четыре этапа показывают, как мне кажется, естественный ход вещей:
☸️ Первое знакомство с Kubernetes: что под капотом у системы оркестрации?
Андрей Трошин
Что под капотом у оркестратора?
Любой ИТ-дирижер позволяет развертывать приложения, управлять ими и реагировать в реальном времени на происходящие в них изменения. Типичные, задачи которые стоят перед оркестратором:
Примеры оркестраторов
Apache Mesos
Apache Mesos – централизованная система управления кластером. Она объединяет в группы отдельные узлы согласно требованиям, а также обеспечивает их изоляцию от остальных IT-ресурсов. Разработанный в университете Беркли продукт вышел в 2009 г. и имеет нестандартный подход к архитектуре. Apache Mesos отлично подходит для создания очень больших систем и реализации масштабных проектов.
Kubernetes
Самый модный оркестратор основан на разработках Google. В 2014 г. корпорация открыла код Kubernetes и стала распространять систему под лицензией Apache 2.0. В результате началось быстрое развитие продукта сообществом, и на данный момент он используется как в небольших проектах, так и в сегменте Enterprise.
Docker Swarm
Компания Docker (в девичестве dotCloud) одной из первых предложила реализацию контейнеров и систему управления ими. Kubernetes внутри себя обычно использует Docker как среду исполнения контейнеров (Container runtimes). Docker swarm позволяет объединять хосты Docker в общий виртуальный хост. Обычно это решение используют в относительно небольших проектах.
Что под капотом у Kubernetes?
Любой оркестратор позволяет развертывать и масштабировать приложения, а также реагировать на изменения в них. Все эти функции реализуются в Kubernetes слоем Control plane. В предыдущей статье мы рассмотрели простой способ развертывания кластера, а сейчас разберем его компоненты более подробно.
На схеме видно, что внутри кластера есть некоторое количество нод (от англ. node – узел), на которых запущена среда исполнения контейнеров (Container runtimes). В Conteiner runtime живет контейнер, а в нем – наше приложение. Вот такая матрешка получается. Kubernetes управляет этими матрешками, отслеживает их состояние, планирует ресурсы (CPU, RAM, HDD) и осуществляет при необходимости масштабирование.
Control Plane
Мозгом Kubernetes кластера является набор компонентов, которые обычно устанавливаются на Master node (мастер-узел). В разных конфигурациях k8s мастеров может быть несколько – это необходимо, если требуется высокая доступность кластера. На схеме показан набор компонентов мастер-ноды.
Познакомимся поближе с каждым из них.
API server
Этот компонент является endpoint, т.е. точкой контакта, на которую приходят запросы на создание объектов Kubernetes. API Server – единственный компонент, который общается с Сluster store напрямую.
Scheduler
Компонент, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать с учетом запрошенных ресурсов и фактических ресурсов ноды.
Cluster store (etcd)
Этот компонент реализует распределенное и высоконадежное хранилище данных в формате key-value, которое используется как основное для данных кластера Kubernetes. Рекомендуется делать его резервные копии, поскольку если Cluster store разрушится, под угрозой весь кластер k8s.
Controllers
Компонент, осуществляющий контроль на всех уровнях кластера Kubernetes.
Мы разобрали на верхнем уровне, что из себя представляет Control plane. Это своего рода серверная часть, обслуживающая очередь клиентов. Клиентами являются Worker node (рабочие ноды), на которых мы и развертываем наши приложения.
На каждой Worker node есть определенный набор компонентов, представленный на схеме.
Познакомимся с ними.
Kubelet
Самый главный компонент Worker node. Через него происходит обмен данными с API-сервером. Основная функция – слушать сервер на предмет появления новых заданий и выполнять их при необходимости. Также Kubelet отчитывается серверу о проделанной работе.
Container runtime
Для выполнения задач на ноде необходима некая среда исполнения, внутри которой запускаются контейнеры с приложениями: обычно это Docker, но Kubernetes поддерживает и другие варианты. Например containerd, реализующий модель Container Runtime Interface (CRI). Выбор среды исполнения остается за вами.
Kube proxy
Последний компонент Worker node отвечает за локальную сеть. Он гарантирует, что каждый узел получит свой уникальный IP, реализует правила IPTABLES или IPVS для управления маршрутизацией и балансировкой нагрузки трафика во внутренней сети k8s.
Подведем итог. Если соединить компоненты Control Plan и компоненты Worker nodes, получится следующая схема.
Надеюсь, пазл сложился. В третьей публикации цикла мы начнем углубляться в практическую часть и изучим базовые конструкции кластера, а в четвертой перейдем к развертыванию приложений.
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.
Приходите к нам учиться и расскажите в комментариях, с какими оркестраторами работаете вы? Есть ли плюсы и минусы, о которых мы забыли сказать?