Момиче на скутер. Илюстрация 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 с помощта на hook, а Consul наблюдава повторното разполагане на задачата Nomad при промени в конфигурацията на услугата.
• Ceph добавя разпределена файловата система в Nomad.
• fabio за натоварване.

Всичко това позволява органично да развивате инфраструктурата без особена привързаност към доставчика.

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

Няма система, която да е перфектна. Не препоръчвам незабавно да внедрявате най-новите функции вproduction. Разбира се, има грешки и липсващи функции, но същото важи и за Kubernetes.

В сравнение с Kubernetes, общността на Nomad не е толкова голяма. Kubernetes вече има около 75 000 коммита и 2000 сътрудници, докато Nomad разполага с около 14 000 коммита и 300 сътрудници. Nomad ще бъде трудно да се задържи и да не отстъпва по скорост на Kubernetes, но може би това не е и нужно! Това е по-специализирана система, а по-малката общност също означава, че вашият pull request вероятно ще бъде забелязан и приет, в сравнение с Kubernetes.

Резюме

Извод: не използвайте Kubernetes просто защото всички го правят. Внимателно оценете своите изисквания и проверете кой инструмент е по-изгоден.

Ако планирате да разгръщате маса от хомогенни услуги на мащабна инфраструктура, Kubernetes е добро решение. Просто имайте предвид допълнителната сложност и експлоатационни разходи. Някои разходи могат да бъдат избегнати, използвайки управлявана среда Kubernetes, като Google Kubernetes Engine или Amazon EKS.

Ако търсите надежден оркестратор, лесен за поддръжка и разширяем, защо да не опитате Nomad? Може би ще бъдете приятно изненадани колко далеч ще ви отведе.

Ако сравним Kubernetes с машина, Nomad ще бъде скутер. Понякога имате нужда от едното, понякога от другото. И двата имат право на съществуване.

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