Момиче на скутер. Илюстрация freepik, лого на Nomad от HashiCorp

Kubernetes е 300-килограмовата горила за оркестрация на контейнери. Тя работи в някои от най-големите контейнерни системи в света, но е скъпа.

Особено скъпо за малки екипи, които ще трябва да инвестират много време в поддръжка и извивка на обучението. За нашия екип от четирима това е твърде много разходи. Затова започнахме да търсим алтернативи — и се влюбихме в Nomad.

Какво искаме

Нашият екип поддържа редица типични услуги за мониторинг и анализ на производителността: API крайни точки за метрики, написани на Go, Prometheus експортер, парсери на логове, като Logstash и Gollum, както и бази данни, като InfluxDB или Elasticsearch. Всяка от тези услуги работи в собствен контейнер. Нуждаем се от проста система, за да поддържаме всичко в работно състояние.

Започнахме със списък на изискванията за оркестриране на контейнери:

• Стартиране на набор от услуги на много машини.
• Преглед на стартираните услуги.
• Връзки между услугите.
• Автоматичен рестарт, ако услугата падне.
• Поддръжка на инфраструктура от малък екип.

Освен това, следните неща ще бъдат приятни, но не задължителни допълнения:

• Маркировка на машините според техните възможности (например, маркировка на машини с бързи дискове за тежки I/O услуги).
• Възможност за стартиране на услуги независимо от оркестратора (например, по време на разработка).
• Общо място за обмен на конфигурации и тайни.
• Крайна точка за метрики и логове.

Защо Kubernetes не е подходящ за нас

При създаването на прототип с Kubernetes забелязахме, че започваме да добавяме все по-сложни слоеве логика, на които безусловно разчитахме.

Например, Kubernetes поддържа вградени конфигурации на услуги чрез ConfigMaps. Можете да се объркате бързо, особено при сливане на няколко конфигурационни файла или добавяне на допълнителни услуги в pod. helm в този случай) позволява динамично да се внедряват външни конфигурации за разделяне на интересите. Но това води до стриктна скрита връзка между вашия проект и Kubernetes. Все пак, Helm и ConfigMaps са допълнителни опции, затова не е необходимо да ги използвате. Може просто да копирате конфигурацията в Docker образ. Въпреки това, примамливо е да се поеме по този път и да се изградят ненужни абстракции, за които по-късно може да съжалявате.

Освен това, екосистемата на Kubernetes бързо се развива. Нужно е много време и усилие, за да сте в крак с най-добрите практики и най-новите инструменти. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — списъкът продължава и продължава. В началото на работата не са нужни всички тези инструменти, но не знаете какво ще ви е необходимо, затова трябва да бъдете наясно с всичко. Поради това, кривата на обучение е доста стръмна.

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

В нашата компания много хора използват Kubernetes и са доста доволни от него. Тези инстанции се управляват от Google или Amazon, които имат достатъчно ресурси за поддръжка.

Kubernetes идва с удивителни функции, които правят мащабиране на контейнерна оркестрация по-управляемо:

• Детайлно управление на правата.
• Персонализирани контролери добавят логика в клъстера. Това са просто програми, които комуникират с Kubernetes API.
• Автоматично мащабиране! Kubernetes може да мащабира услуги при необходимост, използвайки метрики на услугите и без нужда от ръчен намеса.

Въпросът е, дали наистина ви трябват всички тези функции. Не можете просто да разчитате на абстракции; трябва да разберете какво се случва подmotoc.

Нашият екип предоставя повечето услуги дистанционно (поради тясната връзка с основната инфраструктура), затова не искахме да стартираме собствен Kubernetes клъстер. Искахме просто да предоставяме услуги.

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

Nomad е 20% от оркестрацията, която дава 80% от необходимото. Всичко, което прави, е да управлява разгръщанията. Nomad се грижи за разгръщанията, рестартира контейнерите при грешки… и това е всичко.

Смисълът на Nomad е, че той прави минимум: никакво детайлно управление на правата или разширени мрежови политики, това е замислено по този начин. Тези компоненти се предоставят отстрани или изобщо не се предоставят.

Мисля, че Nomad е намерил идеален компромис между леснотата на използване и полезността. Той е чудесен за малки, независими услуги. Ако е нужно повече контрол, ще трябва да ги стартирате сами или да използвате друг подход. Nomad е просто оркестратор.

Най-доброто в Nomad е, че е лесно да се замени. Привързаността към доставчици е почти незначителна, тъй като функциите му лесно се интегрират в всяка друга система за управление на услуги. Той работи просто като обикновен бинарен файл на всяка машина в клъстера, и това е всичко!

Екосистемата на Nomad е от слабо свързани компоненти

Истинската сила на Nomad е в неговата екосистема. Той много добре се интегрира с други — напълно незадължителни — продукти, като Consul (съхранение на ключ-стойност) или за съхранение на тайни): (обработка на тайни). Вътре в файла на 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, но може би това изобщо не е необходимо! Това е по-специализирана система и по-малката общност също означава, че вашият pull-request вероятно ще бъде забелязан и приет, в сравнение с Kubernetes.

Резюме

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

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

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

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

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