Kas iš tiesų yra Nomad ir kodėl apie jį vis daugiau kalbama
Kubernetes jau seniai tapo orkestravimo pasaulio karaliumi – tai tiesiog faktas. Bet ar kada susimąstėte, kodėl vis daugiau komandų pradeda žvalgytis į HashiCorp Nomad? Tai nėra paprastas „dar vienas Kubernetes alternatyvas” – tai visiškai kitoks požiūris į tai, kaip turėtų veikti orkestravimo platforma.
Nomad atsirado 2015 metais kaip HashiCorp atsakas į sudėtingą konteinerių orkestravimo problemą. Skirtingai nei Kubernetes, kuris gimė Google viduje sprendžiant milžiniškos apimties infrastruktūros iššūkius, Nomad buvo sukurtas su mintimi, kad ne visiems reikia tokio sudėtingumo lygio. Ir čia slypi pagrindinis skirtumas – filosofija.
HashiCorp komanda padarė drąsų sprendimą: sukurti įrankį, kuris būtų paprastas naudoti, lengvai diegiamas ir tuo pat metu pakankamai galingas realių problemų sprendimui. Ar jiems tai pavyko? Pažiūrėkime giliau.
Architektūros filosofija: paprastumas prieš funkcionalumą?
Čia prasideda įdomiausia dalis. Kubernetes architektūra yra… sudėtinga. Tai ne kritika, tai tiesiog faktas. Turite etcd klasterį, API serverį, scheduler’į, controller manager’į, kubelet’us kiekviename node’e, ir tai tik pradžia. Norint pilnai funkcionuojančio Kubernetes klasterio, jums reikės dar ingress controller’io, storage orchestrator’iaus, tinklo plugin’o ir daugybės kitų komponentų.
Nomad pasuko visiškai kitu keliu. Visa platforma – tai vienas binarinis failas. Taip, teisingai skaitote – vienas failas, kurį galite nukopijuoti į serverį ir paleisti. Tai ne magiška supergalia, bet gerai apgalvotas inžinerinis sprendimas. Nomad serveriai formuoja klasterį naudodami Raft konsensuso algoritmą (panašiai kaip etcd), o klientai (agent’ai) veikia kiekviename darbo node’e.
Bet ar tai reiškia, kad Nomad yra „nupieštas” įrankis? Visai ne. Jis gali orkestruoti ne tik Docker konteinerius, bet ir Java aplikacijas, standalone binarinių failų, Qemu virtualias mašinas, ir net Windows užduotis. Tai universalus orkestravimo sprendimas, o ne tik konteinerių platforma.
Kai deployment’as neturėtų būti magistro darbas
Pabandykite paklausti bet kurio DevOps inžinieriaus apie jų pirmąją Kubernetes diegimo patirtį. Greičiausiai išgirsite istoriją, kurioje figūruoja daug keiksmažodžių, neveikiantys tinklai ir kelios dienos debugging’o. Kubernetes diegimas nėra paprastas – net su tokiais įrankiais kaip kubeadm ar managed sprendimais kaip EKS ar GKE.
Nomad diegimas atrodo taip: atsisiuntėte binarinį failą, sukūrėte konfigūracijos failą (dažniausiai 20-30 eilučių HCL formato), paleidote `nomad agent -config=config.hcl`. Viskas. Turite veikiantį Nomad serverį. Norite klasterio? Pakartokite procesą keliuose serveriuose ir nurodykite jiems vienas kitą. Tai tikrai veikia taip paprastai.
Štai pavyzdys minimalios Nomad serverio konfigūracijos:
„`hcl
datacenter = „dc1”
data_dir = „/opt/nomad/data”
server {
enabled = true
bootstrap_expect = 3
}
„`
Palyginkite tai su Kubernetes, kur net su kubeadm jums reikės sukonfigūruoti CNI plugin’ą, pod network CIDR, service CIDR, ir dar daugybę kitų parametrų. O jei kas nors nepavyksta? Sėkmės ieškant, kuriame iš daugybės komponentų slypi problema.
Resursų suvartojimas: kai RAM’as kainuoja pinigus
Štai kur Nomad tikrai spindi. Minimalus Kubernetes control plane lengvai suėda 2-4GB RAM. Pridėkite dar kubelet’us, kube-proxy, CNI daemon’us kiekviename node’e, ir jūsų bazinė infrastruktūra jau naudoja nemažai resursų dar prieš paleisdami bet kokią aplikaciją.
Nomad serveris gali veikti su 512MB RAM nedidelėse aplinkose, o klientas (agent’as) paprastai naudoja apie 50-100MB. Tai ne tik teoriniai skaičiai – realaus pasaulio deployment’uose šis skirtumas reiškia realius pinigus. Jei turite 50 node’ų klasterį, Nomad infrastruktūra gali sutaupyti kelis gigabaitus RAM’o, kuriuos galite panaudoti savo aplikacijoms.
Bet resursai – tai ne tik atmintis. Nomad scheduler’is yra neįtikėtinai greitas. Jis gali apdoroti tūkstančius užduočių per sekundę viename serveryje. Kubernetes scheduler’is, nors ir galingas, yra žymiai lėtesnis dėl sudėtingesnės logikos ir daugybės extension point’ų.
Kai jums reikia daugiau nei tik konteinerių
Čia Nomad turi unikalų pranašumą. Kubernetes yra sukurtas konteinerių orkestracijai – ir jis tai daro puikiai. Bet kas, jei jūsų infrastruktūroje yra legacy Java aplikacijos, kurios tiesiog veikia kaip JAR failai? Arba turite Windows servisus? Arba naudojate Qemu virtualias mašinas specifiniams use case’ams?
Su Kubernetes jums reikės konteinerizuoti viską. Tai gali būti gera praktika ilgalaikėje perspektyvoje, bet kartais jums tiesiog reikia orkestruoti tai, kas jau yra. Nomad palaiko daugybę „task driver’ių”:
- Docker – standartinis konteinerių palaikymas
- exec – bet kokių binarinių failų paleidimas
- Java – JAR failų orkestravimas su JVM valdymu
- Qemu – virtualių mašinų orkestravimas
- raw_exec – pilna prieiga prie host sistemos (naudokite atsargiai!)
Tai reiškia, kad galite turėti vieną platformą, kuri orkestruoja jūsų Docker konteinerius, legacy Java aplikacijas ir net specialias VM workload’us. Nebereikia kelių skirtingų sistemų ir įrankių.
Ekosistema ir integracija su HashiCorp stack’u
Vienas dalykas, kurio negalima ignoruoti kalbant apie Nomad – tai jo vieta HashiCorp ekosistemoje. Jei jau naudojate Consul service discovery ir service mesh’ui, Vault paslapčių valdymui, ir Terraform infrastruktūros kodui, Nomad integruojasi su jais beveik magiškai.
Consul integracija leidžia automatinį service discovery – jūsų Nomad užduotys automatiškai registruojasi Consul’e ir gali rasti viena kitą be jokios papildomos konfigūracijos. Vault integracija reiškia, kad jūsų aplikacijos gali saugiai gauti paslapčius be jokio hardcoded credentials. Terraform gali valdyti Nomad job’us kaip infrastruktūros dalį.
Štai pavyzdys, kaip atrodo Nomad job’as su Consul ir Vault integracija:
„`hcl
job „webapp” {
datacenters = [„dc1”]
group „web” {
count = 3
network {
port „http” {
to = 8080
}
}
service {
name = „webapp”
port = „http”
check {
type = „http”
path = „/health”
interval = „10s”
timeout = „2s”
}
}
task „server” {
driver = „docker”
config {
image = „myapp:latest”
ports = [„http”]
}
vault {
policies = [„webapp-policy”]
}
template { Gerai, užteks teorijos. Pažiūrėkime į realius scenarijus, kada turėtumėte rinktis Nomad, o kada Kubernetes. Rinkitės Nomad, kai: Turite mažą ar vidutinio dydžio komandą (iki 20-30 žmonių) ir nenorite skirti viso žmogaus tik Kubernetes valdymui. Rimtai, Kubernetes reikalauja dedikuoto dėmesio, o Nomad gali būti „šalutinis projektas” jūsų DevOps inžinieriaus. Jūsų infrastruktūra yra heterogeniška – turite konteinerių, legacy aplikacijų, galbūt kelias VM’as. Nomad gali viską tai orkestruoti vienoje platformoje. Veikiate edge computing aplinkoje arba turite daug mažų deployment’ų skirtingose lokacijose. Nomad lengvumas ir maži resursų reikalavimai čia yra didžiulis pranašumas. Jau naudojate HashiCorp stack’ą ir norite visko integracijos. Jei Consul, Vault ir Terraform jau yra jūsų kasdienybė, Nomad bus natūrali papildoma dalis. Rinkitės Kubernetes, kai: Jums reikia maksimalaus ekosistemos palaikymo. Kubernetes turi tūkstančius ready-made sprendimų, operator’ių, Helm chart’ų. Bet kokiai problemai greičiausiai jau yra Kubernetes sprendimas. Planuojate labai didelę apimtį – tūkstančiai node’ų, dešimtys tūkstančių pod’ų. Kubernetes buvo sukurtas būtent tokiems scenarijams ir yra geriau ištestuotas tokioje apimtyje. Jums reikia labai sudėtingų deployment strategijų, canary releases, blue-green deployments su fine-grained kontrole. Nors Nomad palaiko deployment strategijas, Kubernetes ekosistemoje yra daugiau įrankių ir brandesnių sprendimų. Samdote žmones, kurie jau žino Kubernetes. Tai pragmatiškas argumentas – Kubernetes žinios yra daug labiau paplitusios darbo rinkoje. Įdomus dalykas – jums nebūtinai reikia rinktis tik vieną. Kai kurios organizacijos naudoja abu sprendimus skirtingoms užduotims. Pavyzdžiui, Kubernetes production aplikacijoms, o Nomad batch job’ams ar edge deployment’ams. Jei svarstote migraciją iš Kubernetes į Nomad (arba atvirkščiai), žinokite, kad tai nėra trivialus procesas. Konceptai yra panašūs, bet ne identiški: Bet yra ir skirtumų. Kubernetes turi daug daugiau abstrakcijų – StatefulSets, DaemonSets, Jobs, CronJobs. Nomad turi paprastesnį modelį, bet kartais tam reikia daugiau rankinio darbo. Praktinis patarimas: jei svarstote Nomad, pradėkite nuo ne-kritinės sistemos dalies. Deployment’inkite kažką, kas nėra production critical, ir pamatykite, kaip jums patinka dirbti su platforma. Nomad mokymosi kreivė yra žymiai švelnesnė nei Kubernetes, tad per kelias savaites turėsite gerą supratimą, ar tai tinka jūsų use case’ui. Po visų šių palyginimų ir techninių detalių, grįžkime prie pagrindinio klausimo: ar Nomad yra realus Kubernetes konkurentas? Atsakymas priklauso nuo to, ką reiškia „konkurentas”. Jei kalbame apie rinkos dalį ir adoption rate’ą, Kubernetes yra aiškus lyderis ir greičiausiai toks išliks. Bet tai nereiškia, kad Nomad neturi savo vietos. Yra vis daugiau kompanijų, kurios renkasi Nomad būtent dėl jo paprastumo ir universalumo. Cloudflare, Roblox, Pandora – tai tik keletas žinomų vardų, kurie naudoja Nomad production’e. Tendencija, kurią matome – tai „right-sizing” orkestravimo sprendimų. Ne visiems reikia Kubernetes galios ir sudėtingumo. Kartais paprastesnis sprendimas yra geresnis sprendimas. Nomad užpildo tą nišą kompanijoms, kurioms reikia orkestravimo, bet ne Kubernetes kompleksiškumo. Jei esate startupo ar mažos/vidutinės kompanijos DevOps inžinierius, rimtai apsvarstykite Nomad. Galite turėti veikiančią production orkestraciją per dieną, o ne per savaites. Jei jau kovojate su Kubernetes kompleksiškumu ir jaučiate, kad 80% funkcionalumo jums nereikalingas – Nomad gali būti atsakymas. Tuo tarpu, jei esate didelėje organizacijoje su dedikuota platform engineering komanda, Kubernetes greičiausiai išlieka geresniu pasirinkimu dėl brandesnės ekosistemos ir platesnio community palaikymo. Bet net ir tada, Nomad gali būti puikus įrankis specifiniams use case’ams – edge computing, batch processing, ar legacy sistemų orkestravimas. Galiausiai, abu įrankiai sprendžia tą pačią fundamentalią problemą – kaip efektyviai valdyti ir orkestruoti workload’us modernioje infrastruktūroje. Jūsų pasirinkimas turėtų priklausyti nuo jūsų komandos dydžio, techninio background’o, infrastruktūros poreikių ir to, kiek laiko bei resursų galite skirti orkestravimo platformos valdymui. Nebijokite išbandyti Nomad – geriausiu atveju rasite paprastesnį sprendimą savo problemoms, blogiausiu – išmoksite kažką naujo apie orkestravimą.
data = <Migracija ir hibridiniai scenarijai
Ką rodo praktika ir kur link judame
