Девушка на скутере. Иллюстрация freepik, логотип Nomad от HashiCorp

Kubernetes — это 300-килограммовая горилла для оркестровки контейнеров. Она работает в некоторых самых крупных контейнерных системах в мире, но дорого обходится.

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

Чего хочется

Наша команда поддерживает ряд типичных сервисов для мониторинга и анализа производительности: конечные точки API для метрик, написанных на Go, экспорт Prometheus, парсеры логов, такие как Logstash и Gollum, а также базы данных, такие как InfluxDB или Elasticsearch. Каждая из этих служб работает в собственном контейнере. Нам нужна простая система, чтобы поддерживать всё это в рабочем состоянии.

Мы начали со списка требований для оркестровки контейнеров:

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

Кроме того, следующие вещи будут приятными, но не обязательными дополнениями:

Пометка машин по их возможностям (например, пометка машин с быстрыми дисками для тяжёлых сервисов ввода-вывода).
Возможность запуска служб независимо от оркестратора (например, во время разработки).
Общее место для обмена конфигурациями и секретами.
Конечная точка для метрик и логов.

Почему Kubernetes нам не подходит

При создании прототипа с Kubernetes мы заметили, что стали добавлять всё более сложные слои логики, на которую безоговорочно полагались.

В качестве примера, Kubernetes поддерживает встроенные конфигурации сервисов через ConfigMaps. Вы можете быстро запутаться, особенно при слиянии нескольких файлов конфигурации или добавлении дополнительных служб в pod. Kubernetes (или helm в данном случае) позволяет внедрять динамически внешние конфигурации для разделения интересов. Но это приводит к жёсткой скрытой связи между вашим проектом и Kubernetes. Впрочем, Helm и ConfigMaps являются дополнительными опциями, поэтому вам не обязательно их использовать. Вы можете просто скопировать конфигурацию в образ Docker. Тем не менее, заманчиво пойти по этому пути и построить ненужные абстракции, о чём потом можете пожалеть.

Кроме того, экосистема Kubernetes быстро развивается. Требуется много времени и энергии, чтобы оставаться в курсе лучших практик и новейших инструментов. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — список продолжается и продолжается. В начале работы необходимы не все эти инструменты, но вы не знаете, что понадобится, поэтому нужно быть в курсе всего. Из-за этого кривая обучения довольно крутая.

Когда использовать Kubernetes

У нас в компании многие используют Kubernetes и вполне довольны этим. Эти инстансы управляются Google или Amazon, у которых хватает ресурсов на поддержку.

Kubernetes поставляется с удивительными функциями, которые делают более управляемой масштабную оркестровку контейнеров:

Детализированное управление правами.
Кастомные контроллеры добавляют логику в кластер. Это просто программы, которые разговаривают с Kubernetes API.
Автомасштабирование! Kubernetes умеет масштабировать сервисы по требованию, используя сервисные метрики и не требуя ручного вмешательства.

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

Наша команда предоставляет большинство сервисов удалённо (из-за тесной связи с основной инфраструктурой), поэтому мы не хотели поднимать собственный кластер Kubernetes. Мы хотели просто предоставлять сервисы.

Батареи не включены

Nomad — это 20% оркестровки, которые дают 80% необходимого. Всё, что он делает, это управляет деплоями. Nomad заботится о деплоях, перезапускает контейнеры в случае ошибок… и это всё.

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

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

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

Экосистема Nomad из слабо связанных компонентов

Реальная сила Nomad в его экосистеме. Он очень хорошо интегрируется с другими — полностью необязательными — продуктами, такими как Consul (хранилище ключ-значение) или Vault (обработка секретов). Внутри файла Nomad есть разделы для извлечения данных из этих служб:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

Здесь мы читаем ключ service/geo-api/log-verbosity из Consul и в процессе работы представляем его переменной окружения LOG_LEVEL. Мы также представляем ключ secret/geo-api-key из Vault как API_KEY. Просто, но мощно!

Благодаря своей простоте Nomad легко расширяется с помощью других сервисов через API. Например, поддерживаются теги для заданий. Мы помечаем все службы с метриками тегом trv-metrics. Таким образом, Prometheus легко находит эти службы через Consul и периодически проверят конечную точку /metrics на предмет новых данных. То же самое можно сделать, например, для логов, используя Loki.

Есть много других примеров расширяемости:

Запуск задания Jenkins с помощью хука, а Consul отслеживает повторный деплой задания Nomad при изменениях конфигурации службы.
Ceph добавляет в Nomad распределённую файловую систему.
fabio для балансировки нагрузки.

Всё это позволяет органично развивать инфраструктуру без особой привязки к вендору.

Честное предупреждение

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

По сравнению с Kubernetes, сообщество Nomad не так велико. У Kubernetes уже около 75 000 коммитов и 2000 контрибуторов, в то время как у Nomad около 14 000 коммитов и 300 контрибуторов. Nomad будет трудно удержаться и не отставать по скорости от Kubernetes, но, возможно, это и не нужно! Это более специализированная система, а меньшее сообщество также означает, что ваш пулл-реквест скорее заметят и примут, по сравнению с Kubernetes.

Резюме

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

Если планируете развернуть массу однородных служб на крупномасштабной инфраструктуре, то Kubernetes — хороший вариант. Просто помните о дополнительной сложности и эксплуатационных расходах. Некоторых затрат можно избежать, используя управляемую среду Kubernetes, такую как Google Kubernetes Engine или Amazon EKS.

Если просто ищете надёжный оркестратор, простой в поддержке и расширяемый, почему бы не попробовать Nomad? Возможно, вы удивитесь, как далеко это вас заведёт.

Если Kubernetes сравнить с машиной, Nomad будет скутером. Иногда вам нужно одно, а иногда другое. Оба имеют право на существование.

Источник: habr.com

Возможно, вам не нужен Kubernetes