Проще, чем Kubernetes: когда стоит выбрать Nomad, Docker Swarm или другие решения

Введение

Kubernetes стал своего рода синонимом оркестрации контейнеров – мощным, но порой громоздким инструментом. Многие команды спешат внедрить его «ради соответствия трендам», даже если проект невелик. Но нужно ли «стрелять из пушки по воробьям»? Представьте небольшой стартап, где пара микросервисов и всего несколько разработчиков. Развертывать полноценный кластер Kubernetes для такой задачи – все равно что нанять целый оркестр, чтобы сыграть мелодию, которую мог бы исполнить один гитарист. В этой статье мы поговорим о более простых альтернативах Kubernetes – таких как HashiCorp Nomad, Docker Swarm и легковесные серверлесс-решения на одном хосте – и рассмотрим, когда Kubernetes избыточен для небольших команд и проектов.

Когда Kubernetes усложняет жизнь небольшой команды

Kubernetes блестяще решает задачи масштабирования и управления сотнями контейнеров, но расплачивается за это сложностью. Конфигурации в виде множества YAML-файлов, десятки компонентов (etcd, controller-manager, scheduler, kube-proxy и т.д.), сложная сеть и высокая кривая обучения – все это может превратить жизнь небольшой команды в кошмар. Для малых проектов затраты на поддержку Kubernetes зачастую перевешивают выгоды. По оценкам некоторых специалистов, типичный кластер Kubernetes требует примерно на 30% больше вычислительных ресурсов, чем сами приложения, которые на нем работают. Эти «лишние» ресурсы уходят на поддержание инфраструктуры самого Kubernetes. В результате небольшому стартапу приходится тратить деньги и время на серверы и настройку, вместо того чтобы быстро выводить продукт на рынок.

Кроме того, Kubernetes предполагает, что у вас есть целая «армия DevOps» для управления кластером. Если же команда маленькая, никто не хочет день и ночь разбираться, почему поды не стартуют или как настроить ingress. В отчете CloudFest отмечается, что простые оркестраторы способны дать 80% функциональности Kubernetes (сервис-дискавери, балансировку, декларативный деплой) без крутого порога входжения и операционных сложностей Kubernetes. Иначе говоря, небольшим командам зачастую нужнее решение, которое «работает на них, а не против них», позволяя сфокусироваться на разработке, а не на бесконечной настройке инфраструктуры.

Да и сама философия DevOps подразумевает быстрые итерации и доставку ценности. Если внедрение Kubernetes тормозит ваш time-to-market, стоит задуматься: возможно, проще обойтись без него? Как справедливо заметил CEO компании Portainer Нил Крессвелл, если команда недостаточно подготовлена к сложности Kubernetes, вполне нормально использовать Docker Swarm или Nomad – нет ничего хуже, чем первый опыт контейнеризации, омраченный «неподъемностью» Kubernetes. В следующих разделах рассмотрим несколько альтернатив, которые помогут избежать этой ситуации.

HashiCorp Nomad – оркестрация одним бинарником

Когда речь заходит о более легковесной альтернативе Kubernetes, часто вспоминают HashiCorp Nomad. Nomad – это оркестратор рабочих нагрузок от HashiCorp, примечательный своей простотой. Его часто называют «оркестратором в одном бинарнике», потому что и сервер, и клиент Nomad запускаются из одного исполняемого файла и не требуют массы внешних зависимостей. Согласно официальной документации, Nomad – полностью самодостаточный: запускается как единый процесс без внешних сервисов координации и хранения данных. Нет необходимости поднимать отдельную базу etcd или целый зоопарк микросервисов – вы просто запускаете Nomad-агенты, и у вас уже готов кластер.

Nomad придерживается философии «делай одно и делай это хорошо». В отличие от Kubernetes, который пытается быть «комбайном» для всех задач (оркестрация, сервис-меш, секреты, мониторинг и т.д.), Nomad фокусируется на основных функциях оркестрации – планировании и запуске задач на кластере – передавая другие задачи специализированным инструментам вроде Consul (для сервис-дискавери) и Vault (для секретов). Такой минималистичный подход снижает сложность: меньше движущихся частей – меньше шансов что-то сломается и меньше знаний требуется для базового обслуживания.

Что это дает на практике небольшим командам? Быстрота развертывания и экономия сил. Nomad можно поднять за считанные минуты, даже локально. Например, разработчик может скачать один бинарник, запустить Nomad в dev-режиме и уже через пару минут деплоить свой первый сервис. Нет громоздких YAML – конфигурации Nomad пишутся в более лаконичном HCL (HashiCorp Configuration Language), который многим кажется понятнее. Один из пользователей назвал Nomad «чемпионом простоты», отмечая, что в Nomad меньше сущностей – не нужно отдельно изучать pods, deployments, CRD и прочие мудрености Kubernetes.

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

Живой пример успешного применения Nomad – знаменитый Интернет-архив (Internet Archive). Столкнувшись со сложностью Kubernetes, команда Archive пошла нестандартным путем: мигрировала всю инфраструктуру с Kubernetes на Nomad, именно из-за выигрыша в простоте. Этот кейс наглядно показывает, что даже крупные проекты могут работать на более легковесном решении без потери качества. Для небольших же компаний Nomad и подавно выглядит привлекательно: минимальная конфигурация, интеграция с уже знакомыми инструментами HashiCorp (Terraform, Consul), адекватная учимсяемость.

Когда Nomad предпочтительнее Kubernetes? Если у вас небольшая команда DevOps или ее вовсе нет, а нужно быстро развернуть несколько сервисов на своих серверах – Nomad позволит сделать это с минимальными усилиями. Он отлично подходит для он-премис инфраструктуры и гибридных сред, где не хочется городить сложный кластер. Также Nomad ценят за гибкость: например, стартап может одновременно запускать контейнеры с приложением и batch-задачи в одном кластере Nomad, не размазывая логику по разным системам. Ну и как бонус – Nomad легок для разработки локально: разработчики могут воспроизводить продакшен-среду у себя без тяжелого Minikube, что ускоряет отладку. В итоге Nomad часто побеждает по ключевому показателю – удовлетворенность разработчиков, ведь им проще и приятнее с ним работать.

Docker Swarm – «встроенная» оркестрация Docker

Если ваша команда уже активно использует Docker, следующая альтернатива выглядит как естественное продолжение. Речь о Docker Swarm – встроенном режиме оркестрации, который Docker Engine поддерживает «из коробки». По сути, Swarm превращает несколько Docker-хостов в единый кластер, где контейнеры запускаются в виде сервисов. Главное преимущество – знакомство и простота. Все, кто умеет писать docker-compose.yml или запускать контейнеры через docker run, в кратчайшие сроки освоят и Docker Swarm. Недаром многие называют Swarm «Kubernetes на минималках» – он даёт базовые возможности оркестрации, но без всей той громоздкости, что присуща K8s.

Эксперты отмечают, что самая простая альтернатива Kubernetes – это Docker Swarm, который обеспечивает базовую оркестрацию контейнеров с гораздо более легким развертыванием, используя уже привычные инструменты Docker. Swarm не требует устанавливать никакого дополнительного ПО – вы просто запускаете на своих серверах Docker-демоны в режиме swarm и объединяете их в кластер командой docker swarm init (на первом узле) и docker swarm join (на остальных). Через пару минут у вас кластер, готовый принимать задачи. Развернуть 5 контейнеров на 3 нодах? Создайте docker-compose файл с описанием сервисов и выполните docker stack deploy – Swarm сам распределит контейнеры по узлам, настроит внутренний DNS для обнаружения сервисов и балансировку нагрузки между ними. Всё это без освоения новых абстракций – используете тот же Compose-файл, что и для одиночного Docker-хоста.

Для небольших и средних проектов Docker Swarm часто оказывается «достаточно хорошим» решением. Он предоставляет ключевые функции: декларативное описание desired state (состояние кластера), масштабирование сервисов, перекатные обновления, self-healing (перезапуск упавших контейнеров) и т.д. При этом Swarm гораздо менее требователен к ресурсам и знаниям. Не нужны отдельные мастер-узлы – менеджеры Swarm могут совмещать роли и тоже хостить контейнеры. Time-to-market ускоряется: если команда и так знает Docker, то внедрение оркестрации займет часы, а не недели. Экономится бюджет – можно обойтись парой виртуальных машин, тогда как Kubernetes обычно требует выделенных ресурсов под мастер-ноды и сложной настройки CI/CD.

Хороший сценарий для Swarm – стартап с ограниченным штатом DevOps. Допустим, у компании 3-4 сервиса (backend, frontend, база, кэш) и пара инженеров, отвечающих за инфраструктуру. Развернуть всё это можно в рамках одного Docker Swarm-кластера на нескольких виртуалках, не привлекая внешних консультантов по Kubernetes. Swarm особенно привлекателен, если приложение планируется держать on-premises или на простом VPS-хостинге без наворотов: не нужны никакие сторонние сервисы – только Docker. Как отмечает один обзор, Docker Swarm – простое и эффективное решение для малых/средних проектов, где приоритетом является интеграция в экосистему Docker и простота использования, а не богатство функций.

Конечно, Swarm не лишен ограничений. Он уступает Kubernetes по части расширяемости и сообщества: новых фич почти не появляется, активность разработки снизилась. Тем не менее, его стабильность и проверенность временем играют на руку небольшим командам. За годы использования в Swarm остался относительно небольшой набор функций, но и багов там немного – система достаточно «отлежалась», многие продолжают ей пользоваться благодаря предсказуемости. Если проект вырастет или потребует более сложного управления, всегда можно будет мигрировать на Kubernetes или другую платформу. Но на первых порах Docker Swarm способен закрыть потребности без лишней боли. Как говорится, лучшее – враг хорошего: не всегда есть смысл сразу браться за «лучший в классе» Kubernetes, когда более простое решение уже решает задачу.

Локальный серверлесс на одном хосте: OpenFaaS и faasd

Мы рассмотрели варианты классической оркестрации, а теперь – об альтернативном подходе. Что если вам вообще не нужен кластер из многих машин, а достаточно запустить всё на одном сервере? Более того, может, вам и контейнеры вручную крутить не хочется – вы просто хотите писать код функций, а платформа сама позаботится о запуске, масштабировании и т.п. В таких случаях на помощь приходят локальные серверлесс-решения. Одно из ярких имен здесь – OpenFaaS (Functions as a Service), точнее его легковесная вариация faasd.

OpenFaaS изначально создавался как надстройка над Kubernetes (или Docker Swarm) для запуска функций, но разработчики поняли, что для многих случаев Kubernetes не нужен. Так появился faasd – упрощенная версия OpenFaaS, работающая без Kubernetes. Faasd представляет собой набор демонов, запускаемых на одном хосте, которые используют containerd для контейнеров и CNI для сети – те же технологии, что под капотом у Kubernetes, но без самого Kubernetes и его сложности. Проще говоря, faasd – это «OpenFaaS для всех остальных», кто не хочет поднимать кластер. Его можно установить скриптом или через cloud-init за считанные минуты, и вы получите локальную серверлесс-платформу: веб-интерфейс, CLI и REST API для деплоя функций.

Почему это важно для небольших команд? Во-первых, отсутствие порога входа. Чтобы начать писать серверлесс-функции, вам не нужно учить Kubernetes-манифесты или платить за AWS Lambda. Faasd запускается на обычном VM или даже на Raspberry Pi – то есть требования к ресурсам смешные. Во-вторых, мгновенное масштабирование и экономия ресурсов. Faasd умеет автоматически выгружать неиспользуемые функции и поднимать их при запросе за доли секунды (холодный старт ~0.3 с). В Kubernetes тоже можно сделать авто-масштабирование функций, но это сложно и зачастую медленнее. Здесь же все встроено: вы не платите постоянным ресурсом за простаивающие контейнеры – идеальная схема для нерегулярных нагрузок.

Рассмотрим пример: предположим, у стартапа есть небольшое веб-приложение и отдельная функция, обрабатывающая, скажем, загрузку изображений (или webhook от платежной системы). Вместо того чтобы держать приложение и функцию постоянно запущенными на отдельных серверах или в Kubernetes, команда может развернуть OpenFaaS/faasd на одном хосте. Веб-приложение будет обычным сервисом (контейнером), а функция деплоится в OpenFaaS как FaaS-функция. В итоге функция «спит», пока нет вызовов, потребляя ноль ресурсов, а при событии быстро просыпается. Поддержка такой инфраструктуры минимальна – один DevOps-инженер или даже разработчик легко разберется с настройкой faasd, потому что нет множества движущихся частей. Как говорится, «серверлесс для всех»: автор OpenFaaS Алекс Эллис так и позиционирует faasd – как вариант для команд, которым нужны возможности функций и микросервисов, но нет ресурса разбираться с Kubernetes.

Отдельно отметим простоту сопровождения: faasd – это по сути несколько процессов на сервере. Обновить его не сложнее, чем обновить обычное приложение. Логи – обычные файлы или вывод systemd journal, метрики сразу доступны через Prometheus, входящий в состав. Нет необходимости мониторить etcd, следить за состоянием control plane, как в Kubernetes. Для бэкапов – просто сохраните пользовательские функции (Docker образы) и конфиги. Таким образом, стоимость владения (TCO) серверлесс-платформой на одном хосте получается мизерной. Вы экономите не только деньги, но и время: развернули один раз – и дальше пользуетесь, почти не трогая. Это особенно ценно для DevOps-команд малых проектов, где каждый человек на счету.

Конечно, такой подход подходит не везде. Faasd рассчитан на один хост, без кластеризации (хотя можно настроить несколько экземпляров для отказоустойчивости). Но в контексте нашей темы – «проще, чем Kubernetes» – локальный серверлесс идеален для маленьких сервисов, внутренних инструментов, прототипов. Зачем поднимать весь Kubernetes, чтобы раз в час запускать функцию обработки данных? Проще использовать faasd на одной машине – и получить результат за день вместо недели. Это ускоряет вывод новых фич: разработчики могут сами деплоить функции, не отвлекаясь на инфраструктуру. А если проект вырастет, ничто не мешает позднее перенести функции в «большой» OpenFaaS на Kubernetes или в облачные Lambda/Azure Functions. Зато на старте вы добились главного – быстро запустились и проверили идею, не утонув в настройке инфраструктуры.

Заключение: подбирайте инструмент под задачу

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

HashiCorp Nomad дает возможность управлять контейнерами и другими приложениями без громоздкого контроллера – достаточно одного бинарника, и ваша инфраструктура уже работает. Docker Swarm предлагает знакомый путь к оркестрации – используя преимущества Docker экосистемы без крутого обучения, позволяя за считанные дни (а то и часы) перейти от одиночных контейнеров к отказоустойчивому кластеру. OpenFaaS/faasd и похожие серверлесс-решения вообще освобождают от мыслей об оркестраторе – вы фокусируетесь на коде функций, а платформа сама масштабирует их на одном небольшом сервере, экономя ваши ресурсы.

Для DevOps-инженеров и CTO стартапов здесь главный посыл: подбирайте инструмент под задачу, а не под резюме. Если вашему проекту не требуется гипермасштабирование с первых дней, нет смысла усложнять жизнь Kubernetes’ом. Время – самый ценный ресурс маленькой команды. Лучшая инфраструктура та, которая ускоряет разработку продукта, а не тормозит ее. Легковесные альтернативы позволяют сократить time-to-market, сэкономить бюджет на инфраструктуре и поддержке, а команду избавить от лишнего стресса. Вы всегда успеете освоить Kubernetes, когда в этом действительно появится необходимость (например, когда сервисы вырастут до сотни и пойдут в глобальный масштаб).

А на начальном этапе проще – значит эффективнее. Используйте Nomad, Swarm, faasd или даже просто один Docker-хост, если этого достаточно, и движетесь вперед. В мире стартапов и небольших проектов выигрывает тот, кто быстрее доставляет ценность пользователям. Пусть ваша инфраструктура будет вашим союзником в этом деле, а не тормозом. Как говорится, не усложняй без нужды – иногда маленькая лодка довезет к цели быстрее, чем громоздкий лайнер. Успехов вам в построении простой и надежной контейнерной инфраструктуры!