Kas yra Nomad ir kodėl jis vis dažniau minimas IT sluoksniuose
Kai kalbama apie konteinerių orkestratorius, dažniausiai pirmasis į galvą šauna Kubernetes. Ir tai suprantama – K8s tapo savotiška industrijos standartu, apie kurį kalbama kiekvienoje konferencijoje. Tačiau kas nutinka, kai jūsų projektui nereikia tokio sudėtingumo? Kai norite paprasčiau, bet vis tiek efektyviai valdyti savo darbo krūvius? Čia į sceną įžengia HashiCorp Nomad.
Nomad – tai lengvesnis, lankstesnis ir, drįsčiau teigti, žmogiškesnis požiūris į darbo krūvių orkestraciją. Jis nepretenduoja būti visagaliu sprendimu visiems atvejams, bet tai, ką daro, daro gerai. Nomad gali valdyti ne tik konteinerius, bet ir virtualias mašinas, Java aplikacijas, net paprastus binarnius failus. Tai tikrai universalus įrankis, kuris neįkalina jūsų į vieną technologijų ekosistemą.
Pirmą kartą susidūrus su Nomad dokumentacija, iškart jaučiamas skirtumas. Ten, kur Kubernetes turi šimtus puslapių konfigūracijos pavyzdžių ir sąvokų, Nomad siūlo gana tiesmuką požiūrį. Tai nereiškia, kad jis primityvus – tiesiog sukurtas su mintimi, jog ne visi nori tapti orkestratorių ekspertais.
Architektūra be bereikalingo sudėtingumo
Vienas didžiausių Nomad privalumų – jo architektūros paprastumas. Sistema susideda iš dviejų pagrindinių komponentų: serverių ir klientų (agentų). Serveriai priima užduotis ir priima sprendimus dėl jų paskirstymo, o klientai vykdo tas užduotis savo mazguose. Viskas. Nereikia mokytis apie etcd, control plane komponentus, įvairius tinklo plaginius ir kitas sudėtingas detales.
Nomad serveriai gali veikti klasterio režimu, paprastai rekomenduojama turėti 3 arba 5 serverius produkcinėje aplinkoje. Jie naudoja Raft konsensuso algoritmą, kad išlaikytų duomenų vientisumą ir būtų atsparūs gedimams. Tai patikimas, išbandytas metodas, kurį naudoja daugelis paskirstytų sistemų.
Klientai – tai mašinos, kuriose faktiškai vykdomi jūsų darbai. Jie reguliariai komunikuoja su serveriais, praneša apie savo resursus ir būseną. Kas įdomu – vienas Nomad klasteris gali valdyti tūkstančius klientų be jokių papildomų optimizacijų ar sudėtingų konfigūracijų. HashiCorp teigia, kad jų vidiniuose testuose vienas klasteris lengvai tvarkosi su 10,000+ mazgų.
Darbo su Nomad pradžia – tikrai ne raketų mokslas
Vienas dalykas, kuris mane tikrai nustebino pirmą kartą bandant Nomad – kaip greitai galima pradėti. Jei turite Linux mašiną, viskas, ko reikia, tai atsisiųsti vieną binarinį failą. Taip, tik vieną. Ne helm charts, ne kubectl, ne dešimtys YAML failų su tūkstančiais eilučių.
Pradėti galima net viename kompiuteryje development režimu:
nomad agent -dev
Ir viskas – turite veikiantį Nomad klasterį. Žinoma, tai tik vystymo aplinkoje, bet jau galite pradėti eksperimentuoti, kurti darbus, matyti, kaip viskas veikia. Produkcinei aplinkai konfigūracija šiek tiek sudėtingesnė, bet vis tiek daug paprastesnė nei Kubernetes.
Darbo aprašai Nomad sistemoje rašomi HCL (HashiCorp Configuration Language) kalba arba JSON formatu. HCL yra žymiai skaityviškesnė už YAML, ypač kai konfigūracijos tampa sudėtingesnės. Štai paprastas pavyzdys:
job "webapp" {
datacenters = ["dc1"]
group "web" {
count = 3
task "frontend" {
driver = "docker"
config {
image = "nginx:latest"
port_map {
http = 80
}
}
resources {
cpu = 500
memory = 256
}
}
}
}
Matote? Viskas aiškiai perskaitoma ir suprantama net nematant dokumentacijos. Apibrėžiate darbą (job), grupę (group), užduotį (task), nurodote, kokius resursus ji naudos, ir tiek.
Lankstumas, kurio Kubernetes pavydi
Viena sritis, kur Nomad tikrai šviečia – tai jo gebėjimas dirbti su įvairiausiais darbo krūvių tipais. Kubernetes buvo sukurtas konteinerių orkestracijai ir, nors galima pridėti papildomų funkcijų, jis vis tiek lieka orientuotas į konteinerius.
Nomad nuo pat pradžių buvo kuriamas kaip universalus orkestratorius. Jis turi vadinamuosius „task drivers” – plaginius, kurie leidžia vykdyti skirtingus darbo krūvių tipus. Standartiškai palaikomi:
- Docker – konteinerių vykdymui
- Exec – paprastiems binarniniams failams
- Java – Java aplikacijoms tiesiogiai
- QEMU – virtualioms mašinoms
- Raw exec – bet kokiems vykdomiesiems failams
Tai reiškia, kad galite tame pačiame klasteryje vykdyti Docker konteinerius šalia senosios Java aplikacijos, kuri dar nebuvo sukontenerizuota, ir virtualios mašinos, kuri reikalinga dėl tam tikrų legacy sistemų. Bandykite tai padaryti su Kubernetes be galvos skausmo.
Praktiškai tai atrodo taip: jūsų komanda gali migruoti į modernią infrastruktūrą palaipsniui. Nereikia viską iš karto perkelti į konteinerius. Galite pradėti nuo to, kas paprasta, o senesnes sistemas palikti veikti kaip yra, kol atsiras laiko jas modernizuoti.
Integracija su HashiCorp ekosistema
Nomad nėra vienišas vilkas – jis puikiai integruojasi su kitais HashiCorp produktais, sudarydamas galingą infrastruktūros valdymo rinkinį. Ši integracija nėra prievartinė, bet kai naudojate kelis produktus kartu, gaunate tikrai sklandžią patirtį.
Consul – tai service discovery ir service mesh sprendimas. Nomad automatiškai gali registruoti savo servisus Consul, o Consul Connect suteikia saugią tarpserviso komunikaciją be papildomo konfigūravimo. Tai kaip Kubernetes su Istio, tik be to viso sudėtingumo.
Vault – slaptažodžių ir sertifikatų valdymui. Nomad gali automatiškai gauti kredencialus iš Vault ir juos įterpti į savo užduotis. Tai daroma saugiai, be jokių slaptažodžių hardcode’inimo į konfigūracijas ar aplinkos kintamuosius.
Terraform – infrastruktūros kaip kodo įrankis. Naudojant Terraform, galite aprašyti visą savo Nomad klasterį, jo konfigūraciją, net darbus, kurie jame turėtų veikti. Viskas versijuojama, atkuriama, audituojama.
Kai visa ši ekosistema veikia kartu, gaunate platformą, kuri konkuruoja su bet kokia enterprise Kubernetes distribucija, bet yra žymiai paprastesnė valdyti. Vienas mano kolega, dirbęs su abiem sistemomis, sakė: „Su Kubernetes jaučiausi kaip pilotų kabinoje – šimtai mygtukų ir jungiklių. Su Nomad – kaip geros mašinos vairuotojo sėdynėje. Viskas, ko reikia, po ranka, bet ne per daug.”
Realūs naudojimo scenarijai ir patirtys
Kalbant apie Nomad, svarbu suprasti, kam jis tikrai tinka. Tai ne Kubernetes pakaitalas visais atvejais – tai alternatyva, kuri tam tikrose situacijose yra tiesiog geresnis pasirinkimas.
Mažesnės ir vidutinės komandos – jei turite 2-10 žmonių DevOps/SRE komandą, Nomad leidžia pasiekti daug su mažiau pastangų. Nereikia dedikuoto Kubernetes eksperto, kuris žinotų visus niuansus. Bet kuris protingas inžinierius gali išmokti Nomad per kelias savaites ir efektyviai jį naudoti.
Multi-cloud ir hybrid aplinkos – Nomad puikiai veikia skirtinguose debesyse ir on-premise. Jis neturi tokių priklausomybių nuo specifinių cloud provider funkcijų kaip kai kurios Kubernetes distribucijos. Vienas klasteris gali apimti AWS, Azure ir jūsų duomenų centrą vienu metu.
Edge computing – kai reikia valdyti darbo krūvius geografiškai paskirstytuose mazguose, Nomad lengvumas ir mažas resursų poreikis tampa dideliu privalumu. Nomad agentas gali veikti net Raspberry Pi, o tai Kubernetes būtų iššūkis.
Viena įmonė, kurią konsultavau, migravo nuo Kubernetes į Nomad ir sumažino savo infrastruktūros valdymo laiką 60%. Ne todėl, kad Kubernetes būtų blogas, bet todėl, kad jiems tiesiog nereikėjo tokio sudėtingumo. Jie vykdė keliolika mikroservisų, turėjo 50 serverių, ir Nomad puikiai atitiko jų poreikius.
Ką reikia žinoti apie trūkumus
Būkime sąžiningi – Nomad nėra tobulas, ir yra situacijų, kai Kubernetes vis tiek yra geresnis pasirinkimas. Svarbiausia – ekosistema. Kubernetes turi milžinišką bendruomenę, tūkstančius įrankių, plaginių, operatorių. Bet kokiai problemai greičiausiai jau yra paruoštas sprendimas.
Nomad bendruomenė mažesnė. Tai reiškia, kad kai susiduriate su specifine problema, gali būti sunkiau rasti paruoštą sprendimą. Teks daugiau improvizuoti, kurti patiems. Kai kuriems tai yra privalumas (daugiau kontrolės), kitiems – trūkumas.
Stateful aplikacijos – nors Nomad palaiko persistent volumes, Kubernetes StatefulSets funkcionalumas yra brandesnė ir labiau išvystyta. Jei jūsų pagrindinis use case yra duomenų bazių orkestracija, Kubernetes su operatoriais gali būti geresnis pasirinkimas.
Automatinis mastelio keitimas – Kubernetes turi labai išvystytą horizontal pod autoscaling funkcionalumą. Nomad turi bazinį autoscaling, bet jis nėra toks galingas. Tiesa, su Nomad galite naudoti išorinius įrankius, kaip Nomad Autoscaler, bet tai papildomas komponentas.
Monitoring ir observability – Kubernetes ekosistemoje yra Prometheus, Grafana, daugybė ready-made sprendimų. Su Nomad teks daugiau konfigūruoti patiems. Tiesa, Nomad puikiai integruojasi su tais pačiais įrankiais, tiesiog nėra tiek ready-made dashboardų ir alert rules.
Praktiniai patarimai pradedantiesiems
Jei nusprendėte išbandyti Nomad, štai keletas patarimų, kurie padės išvengti įprastų klaidų:
Pradėkite mažai – nekurkite iš karto sudėtingos multi-region infrastruktūros. Pradėkite nuo vieno datacenter, kelių serverių ir klientų. Išmokite pagrindus, supaskite, kaip viskas veikia, ir tik tada plėskite.
Naudokite Consul – net jei pradžioje atrodo, kad galite apsieiti be jo, Consul prideda tiek daug vertės (service discovery, health checking, KV store), kad tikrai verta nuo pat pradžių. Integracija su Nomad yra labai sklandi.
Versijuokite savo job failus – laikykite visus Nomad job aprašus Git repository. Tai leidžia sekti pakeitimus, grįžti atgal jei kas negerai, ir turėti audit trail. Galite net sukurti CI/CD pipeline, kuris automatiškai deploy’ina pakeitimus.
Mokykitės iš pavyzdžių – HashiCorp turi puikią dokumentaciją su daugybe pavyzdžių. Taip pat GitHub’e yra nomad-guides repository su įvairiais use case’ais. Nereikia visko išradinėti iš naujo.
Monitorinkite nuo pat pradžių – integruokite Prometheus arba kitą monitoring sprendimą nuo pirmos dienos. Nomad eksportuoja daug metrikų, kurios padeda suprasti, kas vyksta sistemoje. Tai ypač svarbu, kai pradėsite vykdyti produkcinius darbo krūvius.
Kada tikrai verta rinktis Nomad vietoj Kubernetes
Grįžkime prie pagrindinės dilemos – kada Nomad yra geresnis pasirinkimas nei Kubernetes? Iš mano patirties, yra keletas aiškių scenarijų.
Jei jūsų komanda mažesnė nei 15 žmonių ir neturite dedikuoto Kubernetes eksperto, Nomad leis pasiekti 80% Kubernetes funkcionalumo su 20% pastangų. Tai klasikinis Pareto principas veikime.
Kai turite heterogenišką infrastruktūrą – konteinerius, VM, legacy aplikacijas – ir nenorite valdyti kelių skirtingų orkestratorių. Nomad gali būti ta vienintelė platforma, kuri viską suvaldo.
Jei jūsų prioritetas yra paprastumas ir greitis, o ne turėti naujausią ir galingiausią funkcionalumą. Kartais „good enough” yra geriau nei „perfect but complex”.
Kai dirbate su edge computing ar geografiškai paskirstytomis sistemomis, kur svarbus lengvumas ir mažas resursų poreikis. Nomad čia tikrai pranaša.
Ir galiausiai – jei jau naudojate kitus HashiCorp produktus (Terraform, Vault, Consul), Nomad natūraliai įsilieja į jūsų ekosistemą. Integracija yra tokia sklandi, kad visa platforma jaučiasi kaip vientisas sprendimas.
Tačiau jei kuriate platformą, kuri turi aptarnauti šimtus developerių, reikia labai sudėtingo multi-tenancy, arba jūsų pagrindinis focus yra stateful aplikacijos su sudėtingais operatoriais – Kubernetes vis dar gali būti geresnis pasirinkimas. Ir tai visiškai normalu.
Svarbu suprasti, kad tai nėra „arba-arba” situacija. Kai kurios organizacijos naudoja abu – Kubernetes tam, kur jis tikrai reikalingas, ir Nomad paprastesnėms užduotims. Technologijos turėtų tarnauti jums, o ne atvirkščiai.
Galiausiai, Nomad primena, kad orkestracija neturi būti sudėtinga. Kartais paprastesnis sprendimas yra protingesnis sprendimas. Ir jei jūsų projektas neturi Google ar Netflix masto, galbūt jums ir nereikia tokio sudėtingumo. Nomad įrodo, kad galima turėti galingą, patikimą orkestratorių, kuris neprašo jūsų skirti mėnesių jo išmokimui. Ir tai, mano nuomone, yra tikrai vertinga alternatyva šiuolaikiniame IT pasaulyje.
