кубернетис что это простыми словами
Kubernetes для чайников: установка, настройка и основы
Содержание:
Контейнеризация приложений — один из главных трендов современных IT-разработок. Однако, у контейнеров есть один существенный недостаток для массового потребителя — сложная настройка масштабирования.
Решением стали автоматические системы управления контейнеризацией, наиболее популярной из которых является Kubernetes. Это программное обеспечение с открытым исходным кодом от компании Google завоевало признание благодаря сочетанию гибкости, безопасности и мощности.
Cтатья «Kubernetes для чайников» поможет разобраться как устроена платформа управления контейнеризацией, как установить ПО и для чего его можно использовать в дальнейшем. Она будет полезна как для начинающих пользователей Kubernetes, так и для профильных IT-специалистов.
История создания
Проект Kubernetes (сокращенно K8s) вырос из системы управления кластерами Borg. Внутренний продукт поискового гиганта Google получил название в честь кибер-рассы боргов из легендарного сериала «Звездный путь».
Команде разработчиков Google Borg была поставлена масштабная задача — создать открытое программное обеспечение для оркестрирования* контейнеров, которое станет вкладом Google в развитие мировых IT-технологий. Приложение было написано на основе языка Go.
* Под «оркестрированием» подразумевается автоматизированное управление связанными сущностями — контейнерами или виртуальными машинами.
На этапе разработки K8s назвался Project Seven («Проект «Седьмая»). Это было прямой отсылкой к персонажу «Звездного пути» Seven of Nine («Седьмая-из-девяти») — андроиду-боргу, сумевшему вернуть себе человечность. Позже проект получил имя «Кубернетес», от греческого слова κυβερνήτης, которое означает «управляющий», «рулевой» или «кормчий».
В 2014 году общественности представили исходные коды, а годом позже появилась первая версия программы Kubernetes 1.0. В дальнейшем все права на продукт были переданы некоммерческому фонду Cloud Native Computing Foundation (CNCF), куда входят Google, The Linux Foundation и ряд крупнейших технологических корпораций.
Как работает технология
Принципы устройства
Основы работы K8s – применение декларативного подхода. От разработчика требуется указать, чего необходимо достичь, а не способы достижения.
Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.
Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.
Основные задачи Kubernetes
Преимущества K8s
Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.
Основные компоненты
Схема взаимодействия основных компонентов K8s
Node (Нода)
Ноды или узлы — виртуальные или физические машины, на которых разворачивают и запускают контейнеры. Совокупность нод образует кластер Kubernetes.
Первая запущенная нода или мастер-нода непосредственно управляет кластером, используя для этого менеджер контроллеров (controller manager) и планировщик (scheduler). Она ответственна за интерфейс взаимодействия с пользователями через сервер API и содержит в себе хранилище «etcd» с конфигурацией кластера, метаданными и статусами объектов.
Namespace (Пространство имен)
Объект, предназначенный для разграничения ресурсов кластера между командами и проектами. Пространства имен — несколько виртуальных кластеров, запущенные на одном физическом.
Pod (Под)
Первичный объект развертывания и основной логический юнит в K8s. Поды — набор из одного и более контейнеров для совместного развертывания на ноде.
Группировка контейнеров разных типов требуется в том случае, когда они взаимозависимы и должны запускаться в одной ноде. Это позволяет увеличить скорость отклика во время взаимодействия. Например, это могут быть контейнеры, хранящие веб-приложение и сервис для его кэширования.
ReplicaSet (Набор реплик)
Объект, отвечающий за описание и контроль за несколькими экземплярами (репликами) подов, созданных на кластере. Наличие более одной реплики позволяет повысить устойчивость от отказов и масштабирование приложение. На практике ReplicaSet создается с использованием Deployment.
ReplicaSet является более продвинутой версией предыдущего способа организации создания реплик (репликации) в K8s – Replication Controller.
Deployment (Развертывание)
Объект, в котором хранится описание подов, количество реплик и алгоритм их замены в случае изменения параметров. Контроллер развертывания позволяет выполнять декларативные обновления (с помощью описания нужного состояния) на таких объектах, как ноды и наборы реплик.
StatefulSet (Набор состояния)
Как и другие объекты, например — ReplicaSet или Deployment, Statefulset позволяет развертывать и управлять одним или несколькими подами. Но в отличие от них, идентификаторы подов имеют предсказуемые и сохраняемые при перезапуске значения.
DaemonSet (Набор даемона)
Объект, который отвечает за то, чтобы на каждой отдельной ноде (или ряде выбранных) запускался один экземпляр выбранного пода.
Job/CronJob (Задания/Задания по расписанию)
Объекты для регулировки однократного или регулярного запуска выбранных подов и контроля завершения их работы. Контроллер Job отвечает за однократный запуск, CronJob — за запуск нескольких заданий по расписанию.
Label/Selector (Метки/Селекторы)
Метки предназначены для маркировки ресурсов. Позволяют упростить групповые манипуляции с ними. Селекторы позволяют выбирать/фильтровать объекты на основе значения меток.
По факту, метки и селекторы не являются самостоятельными объектами Kubernetes, но без них система не сможет полноценно функционировать.
Service (Сервис)
Средство для публикации приложения как сетевого сервиса. Используется, в том числе, для балансировки трафика/нагрузки между подами.
Процесс установки
Установка Kubernetes, рассмотренная ниже, предполагает наличие одного (или более) серверов с операционной системой Centos 7 или Ubuntu 16.04.
Затем открыть «/etc/fstab» с правами root и удалить соответствующую команде строчку «#/swapfile».
Проект Kubernetes действует на основе контейнеров Docker, существенно расширяя их функциональность. Логично, что начинать работу Kubernetes следует именно с установки Docker.
Проще всего остановить выбор на версии, добавленной на текущий момент в репозитории. Ее протестировали разработчики Kubernetes и она работает наиболее стабильно.
Установка контейнеров на Ubuntu 16.04
Чтобы установить Docker на Ubuntu 16.04, необходимо выполнить следующие команды с правами суперпользователя:
Если требуется работать с более новыми версиями контейнеров, запустите команды:
Установка контейнеров в CentOS 7
Для установки Docker на Centos, в консоли нужно выполнить команды:
Установка kubeadm, kubelet и kubectl в Ubuntu
Для работы с Kubernetes понадобится установить компоненты kubeadm, kubelet и kubectl. Эти утилиты понадобятся для создания управления кластером Kubernetes.
В Ubuntu эти компоненты можно установить следующим способом:
Установка kubeadm, kubelet и kubectl в CentOS
В CentOS 7 компоненты устанавливаются следующим образом:
Обращаем внимание! Команда setenforce 0 позволит получить корректный доступ контейнеров к файловой системе хоста. Последняя необходима для функционирования сети у подов.
Нужно убедиться, что «kubelet» и «docker» пользуются одним и тем же драйвером «cgroup». В этом может помочь команда:
Настройка Kubernetes
Инициализация кластера
Нужно указать сервер, на котором установлен K8s (он будет первичным — там будут запускаться остальные операции) и выполнить инициализацию кластера:
Обращаем внимание! Опция «—pod-network-cidr» задает адрес виртуальной сети подов и может отличаться, в зависимости от используемого сетевого плагина.
В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.
При выполнении команды в консоли, есть вероятность появления ошибок или предупреждений. Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production».
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к первичному хосту. Команда может отличаться, в зависимости от структуры кластера. Ее нужно сохранить на будущее.
После выполнения этой команды система выведет примерный результат:
Остается выполнить следующие команды от имени пользователя, который будет управлять кластером:
Настройка CNI
Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.
Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.
Чтобы установить Flannel, выполните в терминале команду:
В выводе будут отображены имена всех созданных ресурсов.
Добавление узлов (нод) в кластер
Чтобы добавить новые ноды в существующий кластер, требуется выполнить следующий алгоритм:
Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.
Если команда не была сохранена, то можно ее составить повторно.
Получение токена авторизации кластера ( )
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
Вывод должен быть примерно таков:
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
Вывод будет примерно таков:
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
Будет получен примерно такой вывод:
Для ввода IPv6-адреса в параметр « : », адрес должен быть заключен в квадратные скобки. Например:
Дополнительные настройки
В дефолтной конфигурации мастер-нода не запускает контейнеры, так как занимается отслеживанием состояния кластера и перераспределением ресурсов. Ввод данной команды даст возможность запускать контейнеры на мастере, собенно, если кластер содержит лишь одну ноду:
Проверка работоспособности кластера
Проверить, что кластер запустился и правильно работает, можно так:
Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.
Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.
Заключение
Несмотря на кажущуюся сложность настройки, K8s стоит времени, потраченного на его изучение. Kubernetes — наиболее совершенный на сегодня инструмент оркестрирования контейнеров. Он позволяет не только автоматизировать процесс развертывания, но и максимально упрощает дальнейший процесс работы с массивами контейнеров.
С помощью этого краткого руководства начать работу с K8s сможет даже начинающий пользователь. В дальнейшей работе с платформой поможет подробная официальная документация, доступная, в том числе, на русском языке.
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.
Приходите к нам учиться и расскажите в комментариях, с какими оркестраторами работаете вы? Есть ли плюсы и минусы, о которых мы забыли сказать?