Дівчина на скутері. Ілюстрація , логотип Nomad від
Kubernetes – це 300-кілограмова горила для оркестрування контейнерів. Вона працює в деяких найбільших контейнерних системах у світі, але дорого коштує.
Особливо дорого для невеликих команд, яким доведеться витратити багато часу на підтримку та круту криву навчання. Для нашої команди з чотирьох чоловік це занадто багато витрат. Тому ми почали шукати альтернативи і закохалися в .
Чого хочеться
Наша команда підтримує ряд типових сервісів для моніторингу та аналізу продуктивності: кінцеві точки API для метрик, написаних на Go, експорт Prometheus, парсери логів, такі як Logstash та , а також бази даних, такі як InfluxDB або Elasticsearch. Кожна з цих служб працює у власному контейнері. Нам потрібна проста система, щоб підтримувати все це у робочому стані.
Ми почали зі списку вимог для оркестрування контейнерів:
- Запуск набору сервісів на багатьох машинах.
- Огляд запущених служб.
- Зв'язки між службами.
- Автоматичний перезапуск, якщо падає сервіс.
- Обслуговує інфраструктуру невеликою командою.
Крім того, такі речі будуть приємними, але не обов'язковими доповненнями:
- Позначка машин за їхніми можливостями (наприклад, позначка машин зі швидкими дисками для важких сервісів вводу-виводу).
- Можливість запуску служб незалежно від оркестратора (наприклад під час розробки).
- Загальне місце для обміну конфігураціями та секретами.
- Кінцева точка для метрик та логів.
Чому Kubernetes нам не підходить
При створенні прототипу з Kubernetes ми помітили, що стали додавати все складніші шари логіки, на яку покладалися беззастережно.
Як приклад, Kubernetes підтримує вбудовані конфігурації сервісів через . Ви можете швидко заплутатися, особливо при злитті кількох файлів конфігурації або додаванні додаткових служб до під. Kubernetes (або у разі) дозволяє впроваджувати динамічно зовнішні зміни для поділу інтересів. Але це призводить до жорсткого прихованого зв'язку між вашим проектом та 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 у його екосистемі. Він дуже добре інтегрується з іншими – цілком необов'язковими – продуктами, такими як (сховище ключ-значення) або (Обробка секретів). Всередині файлу 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 щодо нових даних. Те саме можна зробити, наприклад, для логів, використовуючи .
Є багато інших прикладів розширюваності:
- Запуск завдання Jenkins за допомогою хука, а Consul відслідковує повторний деплой завдання Nomad при зміні конфігурації служби.
- Ceph додає до Nomad розподілену файлову систему.
- для балансування навантаження.
Все це дозволяє без особливої прив'язки до вендору.
Чесне попередження
Жодна система не досконала. Не раджу відразу впроваджувати в продакшн нові функції. Звичайно, є помилки і відсутні функції, але те ж саме стосується Kubernetes.
Порівняно з Kubernetes, спільнота Nomad не така велика. У Kubernetes вже близько 75 000 коммітів та 2000 контрібуторів, тоді як у Nomad близько 14 000 коммітів та 300 контрибуторів. Nomad буде важко втриматись і не відставати за швидкістю від Kubernetes, але, можливо, це і не потрібно! Це більш спеціалізована система, а менша спільнота також означає, що ваш пулл-реквест швидше за помітять і приймуть порівняно з Kubernetes.
Резюме
Висновок: не використовуйте Kubernetes тільки тому, що так роблять все. Ретельно оцініть свої вимоги та перевірте, який інструмент вигідніший.
Якщо плануєте розгорнути масу однорідних служб на великомасштабній інфраструктурі, то Kubernetes – гарний варіант. Просто пам'ятайте про додаткову складність та експлуатаційні витрати. Деяких витрат можна уникнути, використовуючи кероване середовище Kubernetes, таке як або .
Якщо просто шукаєте надійний оркестратор, простий у підтримці та розширюваний, чому б не спробувати Nomad? Можливо, ви здивуєтеся, як далеко вас заведе.
Якщо Kubernetes порівняти з машиною, Nomad буде скутером. Іноді вам потрібне одне, а іноді інше. Обидва мають право на існування.
Джерело: habr.com