Девушка на скутере. Иллюстрация freepik, логотип Nomad от HashiCorp
Kubernetes — это 300-килограммовая горилла для оркестровки контейнеров. Она работает в некоторых самых крупных контейнерных системах в мире, но дорого обходится.
Особенно дорого для небольших команд, которым придётся потратить много времени на поддержку и крутую кривую обучения. Для нашей команды из четырёх человек это слишком много накладных расходов. Поэтому мы стали искать альтернативы — и влюбились в Nomad.
Наша команда поддерживает ряд типичных сервисов для мониторинга и анализа производительности: конечные точки API для метрик, написанных на Go, экспорт Prometheus, парсеры логов, такие как Logstash и Gollum, а также базы данных, такие как InfluxDB или Elasticsearch. Каждая из этих служб работает в собственном контейнере. Нам нужна простая система, чтобы поддерживать всё это в рабочем состоянии.
Мы начали со списка требований для оркестровки контейнеров:
- Запуск набора сервисов на многих машинах.
- Обзор запущенных служб.
- Связи между службами.
- Автоматический перезапуск, если сервис падает.
- Обслуживание инфраструктуры небольшой командой.
Кроме того, следующие вещи будут приятными, но не обязательными дополнениями:
- Пометка машин по их возможностям (например, пометка машин с быстрыми дисками для тяжёлых сервисов ввода-вывода).
- Возможность запуска служб независимо от оркестратора (например, во время разработки).
- Общее место для обмена конфигурациями и секретами.
- Конечная точка для метрик и логов.
При создании прототипа с Kubernetes мы заметили, что стали добавлять всё более сложные слои логики, на которую безоговорочно полагались.
В качестве примера, Kubernetes поддерживает встроенные конфигурации сервисов через ConfigMaps. Вы можете быстро запутаться, особенно при слиянии нескольких файлов конфигурации или добавлении дополнительных служб в pod. Kubernetes (или helm в данном случае) позволяет внедрять динамически внешние конфигурации для разделения интересов. Но это приводит к жёсткой скрытой связи между вашим проектом и Kubernetes. Впрочем, Helm и ConfigMaps являются дополнительными опциями, поэтому вам не обязательно их использовать. Вы можете просто скопировать конфигурацию в образ Docker. Тем не менее, заманчиво пойти по этому пути и построить ненужные абстракции, о чём потом можете пожалеть.
Кроме того, экосистема Kubernetes быстро развивается. Требуется много времени и энергии, чтобы оставаться в курсе лучших практик и новейших инструментов. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — список продолжается и продолжается. В начале работы необходимы не все эти инструменты, но вы не знаете, что понадобится, поэтому нужно быть в курсе всего. Из-за этого кривая обучения довольно крутая.
У нас в компании многие используют Kubernetes и вполне довольны этим. Эти инстансы управляются Google или Amazon, у которых хватает ресурсов на поддержку.
Kubernetes поставляется с удивительными функциями, которые делают более управляемой масштабную оркестровку контейнеров:
Вопрос в том, действительно ли вам нужны все эти функции. Не получится только полагаться на абстракции; вам придётся узнать, что происходит под капотом.
Наша команда предоставляет большинство сервисов удалённо (из-за тесной связи с основной инфраструктурой), поэтому мы не хотели поднимать собственный кластер Kubernetes. Мы хотели просто предоставлять сервисы.
Nomad — это 20% оркестровки, которые дают 80% необходимого. Всё, что он делает, это управляет деплоями. Nomad заботится о деплоях, перезапускает контейнеры в случае ошибок… и это всё.
Весь смысл Nomad в том, что он делает минимум: никакого детализированного управления правами или расширенных сетевых политик, так специально задумано. Эти компоненты предоставляются со стороны или не предоставляются вовсе.
Думаю, что Nomad нашёл идеальный компромисс между простотой использования и полезностью. Он хорош для небольших, независимых сервисов. Если нужно больше контроля, то придётся поднять их самостоятельно или использовать другой подход. Nomad — это просто оркестратор.
Самое лучшее в Nomad — то, что его легко заменить. Привязка к вендору практически отсутствует, поскольку его функции легко интегрируются в любую другую систему, управляющую сервисами. Он работает просто как обычный бинарник на каждой машине в кластере, вот и всё!
Реальная сила Nomad в его экосистеме. Он очень хорошо интегрируется с другими — полностью необязательными — продуктами, такими как Consul (хранилище ключ-значение) или Vault (обработка секретов). Внутри файла Nomad есть разделы для извлечения данных из этих служб:
template {
data = <<EOH
LOG_LEVEL=""
API_KEY=""
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 будет скутером. Иногда вам нужно одно, а иногда другое. Оба имеют право на существование.
Комментариев нет:
Отправить комментарий