Девушка на скутере. Иллюстрация 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