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

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

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

Какво искаш

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

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

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

В допълнение, следните неща ще бъдат хубави, но не са задължителни допълнения:

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

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

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

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

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

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

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

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

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

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

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

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

Nomad е 20% от оркестрацията, която осигурява 80% от необходимото. Всичко, което прави, е да управлява внедряванията. 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 as 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, като напр Google Kubernetes Engine или Amazon EKS.

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

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

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