Dívka na skútru. Ilustrace , logo Nomad od
Kubernetes je 300kilogramová gorila pro orchestrace kontejnerů. Funguje v některých z největších kontejnerových systémů na světě, ale je drahá.
Obzvlášť drahá pro malé týmy, které stráví spoustu času na údržbu a strmé křivce učení. Pro náš čtyřčlenný tým je to příliš mnoho režijních nákladů. Začali jsme hledat alternativy - a zamilovali jsme si .
Co chceme
Náš tým podporuje řadu běžných služeb pro monitorování a analýzu výkonu: API koncové body pro metriky napsané v Go, export Prometheus, analyzátory logů, jako je Logstash a , stejně jako databáze, jako je InfluxDB nebo Elasticsearch. Každá z těchto služeb běží v vlastním kontejneru. Potřebujeme jednoduchý systém, který udržuje všechno v chodu.
Začali jsme seznamem požadavků na orchestrace kontejnerů:
- Spouštění sady služeb na mnoha strojích.
- Přehled spuštěných služeb.
- Spojení mezi službami.
- Automatické restartování, pokud služba spadne.
- Údržba infrastruktury malým týmem.
Kromě toho by následující věci byly příjemné, ale ne nezbytné doplňky:
- Označení strojů podle jejich schopností (například označení strojů s rychlými disky pro těžké služby s vysokým výkonem I/O).
- Možnost spouštění služeb nezávisle na orchestrátoru (například během vývoje).
- Společné místo pro sdílení konfigurací a tajemství.
- Koncový bod pro metriky a logy.
Proč nám Kubernetes nevyhovuje
Při vytváření prototypu s Kubernetes jsme si všimli, že jsme začali přidávat stále složitější vrstvy logiky, na kterou jsme se bezvýhradně spoléhali.
Například Kubernetes podporuje vestavěné konfigurace služeb prostřednictvím . Můžete se rychle zamotat, zejména při slučování několika konfiguračních souborů nebo přidávání dalších služeb do podu. Kubernetes (nebo V tomto případě) umožňuje implementaci dynamických externích konfigurací pro sdílení zájmů. To však vede k pevnému skrytému propojení mezi vaším projektem a Kubernetes. Helm a ConfigMaps jsou nicméně dalšími možnostmi, takže je nemusíte nutně používat. Můžete jednoduše zkopírovat konfiguraci do obrazu Docker. Přesto je lákavé jít touto cestou a vytvářet zbytečné abstrakce, čehož můžete později litovat.
Ekosystém Kubernetes se navíc rychle vyvíjí. Vyžaduje to spoustu času a energie, abyste byli v obraze s nejlepšími praktikami a nejnovějšími nástroji. Kubectl, minikube, kubeadm, helm, tiller, kops, oc – seznam pokračuje. Na začátku nemusíte mít všechny tyto nástroje, ale nevíte, co budete potřebovat, a proto je důležité být informován o všem. Kvůli tomu je křivka učení docela strmá.
Kdy používat Kubernetes
V naší společnosti mnoho lidí používá Kubernetes a jsou s ním velmi spokojeni. Tyto instance jsou spravovány Googlem nebo Amazonem, kteří mají dostatek prostředků na podporu.
Kubernetes přichází s , které činí rozsáhlou orchestraci kontejnerů lépe spravovatelnou:
- Podrobné .
- přidávají logiku do clusteru. Jsou to prostě programy, které komunikují s API Kubernetes.
- ! Kubernetes dokáže škálovat služby na vyžádání, využívající metriky služeb a nevyžaduje manuální zásah.
Otázka je, zda skutečně potřebujete všechny tyto funkce. Není možné se jen spoléhat na abstrakce; .
Náš tým poskytuje většinu služeb na dálku (kvůli blízkému propojení se základní infrastrukturou), takže jsme nechtěli zakládat vlastní cluster Kubernetes. Chtěli jsme jen poskytovat služby.
Baterie nejsou součástí balení
Nomad je 20% orchestrace, která poskytuje 80% potřebného. To, co dělá, je správa nasazení. Nomad se stará o nasazení, restartuje kontejnery v případě chyb... a to je vše.
Celý smysl Nomadu spočívá v tom, co dělá minimum: žádné podrobné řízení přístupových práv ani , tak to bylo speciálně navrženo. Tyto komponenty jsou poskytovány externě nebo nejsou poskytovány vůbec.
Myslím, že Nomad našel ideální rovnováhu mezi jednoduchostí použití a užitečností. Je skvělý pro malé, nezávislé služby. Pokud potřebujete více kontroly, budete muset služby nasadit sami nebo použít jiný přístup. Nomad je prostě orchestrátor.
Nejlepší na Nomadu je, že ho lze snadno nahradit. Vázanost na dodavatele je prakticky nulová, protože jeho funkce se snadno integrují do jakéhokoli jiného systému pro správu služeb. Funguje jednoduše jako běžný binární soubor na každém počítači v clustru, to je celé!
Ekosystém Nomadu se skládá z volně spojených komponentů
Skutečná síla Nomadu spočívá v jeho ekosystému. Velmi dobře se integruje s dalšími – plně volitelnými – produkty, jako jsou (úložiště klíč-hodnota) nebo (zpracování tajemství). Uvnitř souboru Nomad existují sekce pro extrakci dat z těchto služeb:
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
} Zde čteme klíč service/geo-api/log-verbosity z Consulu a během běhu ho prezentujeme jako proměnnou prostředí LOG_LEVEL. Také prezentujeme klíč secret/geo-api-key z Vaultu jako API_KEY. Jednoduché, ale mocné!
Díky své jednoduchosti se Nomad snadno rozšiřuje pomocí dalších služeb přes API. Například podporuje tagy pro úkoly. Označujeme všechny služby s metrikami tagem trv-metrics. Tímto způsobem Prometheus snadno najde tyto služby přes Consul a pravidelně zkontroluje koncovou platnost /metrics na nové údaje. Totéž lze udělat například pro logy, pomocí .
Existuje mnoho dalších příkladů rozšiřitelnosti:
- Spuštění úlohy Jenkins pomocí hooku, přičemž Consul sledoval opětovné nasazení úlohy Nomad při změnách konfigurace služby.
- Ceph přidává do Nomadu distribuovaný souborový systém.
- pro vyvažování zátěže.
To vše umožňuje bez výrazného vázání na dodavatele.
Poctivé varování
Žádný systém není dokonalý. Nedoporučuji okamžitě implementovat nejnovější funkce do produkce. Samozřejmě existují chyby a chybějící funkce, ale to samé platí pro Kubernetes.
Ve srovnání s Kubernetes není komunita Nomad tak rozsáhlá. Kubernetes již má kolem 75 000 commitů a 2000 přispěvatelů, zatímco Nomad má přibližně 14 000 commitů a 300 přispěvatelů. Bude pro Nomad obtížné udržet krok a nespadnout na rychlosti za Kubernetes, ale možná to ani není potřeba! Je to specializovanější systém a menší komunita také znamená, že váš pull request bude pravděpodobněji všimnut a přijat ve srovnání s Kubernetes.
Shrnutí
Závěr: nepoužívejte Kubernetes jen proto, že to dělají všichni. Pečlivě zhodnoťte své požadavky a zjistěte, který nástroj je výhodnější.
Pokud plánujete nasadit velké množství homogenních služeb na rozsáhlé infrastruktuře, Kubernetes je dobrá volba. Jen si pamatujte na dodatečnou složitost a provozní náklady. Některým nákladům se můžete vyhnout použitím spravovaného prostředí Kubernetes, jako je nebo .
Pokud prostě hledáte spolehlivého orchestrátora, který je snadný na údržbu a škálovatelný, proč nezkusit Nomad? Možná budete překvapeni, jak daleko vás to zavede.
Pokud srovnáme Kubernetes s automobilem, Nomad bude skútr. Někdy potřebujete jedno, jindy druhé. Oba mají právo na existenci.
Zdroj: habr.com
