Fată pe scuter. Ilustrație , logo-ul Nomad de la
Kubernetes este un gorilă de 300 de kilograme pentru orchestrarea containerelor. Funcționează în unele dintre cele mai mari sisteme de containere din lume, dar este costisitoare.
Este în special prea costisitor pentru echipele mici, care vor trebui să cheltuie mult timp pentru întreținere și pentru o curbă de învățare abruptă. Pentru echipa noastră de patru persoane, aceasta reprezintă prea multe cheltuieli indirecte. Așa că am început să căutăm alternative și ne-am îndrăgostit de .
Ce ne dorim
Echipa noastră susține o serie de servicii tipice pentru monitorizarea și analiza performanței: puncte finale API pentru metrici scrise în Go, export Prometheus, analizorii de loguri, precum Logstash și , precum și baze de date, cum ar fi InfluxDB sau Elasticsearch. Fiecare dintre aceste servicii funcționează într-un container propriu. Avem nevoie de un sistem simplu pentru a menține totul în stare de funcționare.
Am început cu o listă de cerințe pentru orchestrarea containerelor:
- Pornirea unui set de servicii pe multe mașini.
- Tabelul de servicii pornite.
- Legăturile dintre servicii.
- Repornire automată dacă un serviciu se oprește.
- Întreținerea infrastructurii de către o echipă mică.
În plus, următoarele lucruri ar fi plăcute, dar nu sunt necesare:
- Etichetarea mașinilor în funcție de capacitățile lor (de exemplu, etichetarea mașinilor cu discuri rapide pentru servicii de intrare-ieșire intensive).
- Posibilitatea de a lansa servicii indiferent de orchestrator (de exemplu, în timpul dezvoltării).
- Un loc comun pentru a partaja configurații și secrete.
- Un punct final pentru metrici și loguri.
De ce Kubernetes nu ni se potrivește
Când am creat un prototip cu Kubernetes, am observat că am început să adăugăm tot mai multe straturi complexe de logică, pe care ne-am bazat fără ezitare.
De exemplu, Kubernetes suportă configurații încorporate ale serviciilor prin . Poți să te complici rapid, mai ales când îmbini mai multe fișiere de configurație sau adaugi servicii suplimentare în pod. Kubernetes (sau În acest caz, permite implementarea dinamică a configurațiilor externe pentru a separa interesele. Totuși, aceasta duce la o legătură rigidă între proiectul dumneavoastră și Kubernetes. Helm și ConfigMaps sunt opțiuni suplimentare, deci nu trebuie neapărat să le folosiți. Puteți pur și simplu să copiați configurația în imaginea Docker. Cu toate acestea, este tentant să mergeți pe acest drum și să construiți abstracții inutile, despre care s-ar putea să regretați ulterior.
În plus, ecosistemul Kubernetes se dezvoltă rapid. Este nevoie de mult timp și energie pentru a rămâne la curent cu cele mai bune practici și cele mai recente instrumente. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — lista continuă. La început, nu aveți nevoie de toate aceste instrumente, dar nu știți ce o să vă fie necesar, așa că trebuie să fiți la curent cu tot. Din această cauză, curba de învățare este destul de abruptă.
Când să folosiți Kubernetes
La compania noastră, mulți folosesc Kubernetes și sunt destul de mulțumiți de acest lucru. Aceste instanțe sunt gestionate de Google sau Amazon, care au suficiente resurse pentru a oferi suport.
Kubernetes vine cu , care fac orchestrarea pe scară largă a containerelor mai gestionabilă:
- Gestionare detaliată .
- adaugă logică în cluster. Acestea sunt pur și simplu programe care comunică cu API-ul Kubernetes.
- ! Kubernetes poate scala serviciile la cerere, folosind metrici de servicii și fără a necesita intervenție manuală.
Întrebarea este, aveți cu adevărat nevoie de toate aceste funcții? Nu puteți conta doar pe abstracții; .
Echipa noastră furnizează majoritatea serviciilor la distanță (datorită legăturii strânse cu infrastructura principală), așa că nu am dorit să ridicăm propriul nostru cluster Kubernetes. Am dorit să furnizăm pur și simplu servicii.
Bateriile nu sunt incluse
Nomad este 20% orchestration care oferă 80% din ceea ce este necesar. Tot ce face este să gestioneze implementările. Nomad se ocupă de implementări, repornește containerele în caz de erori… și cam asta e tot.
Ideea principală a Nomad este că el face minim: fără gestionare detaliată a drepturilor sau , astfel a fost conceput intentionat. Aceste componente sunt furnizate extern sau nu sunt furnizate deloc.
Cred că Nomad a găsit un compromis ideal între ușurința de utilizare și utilitate. Este potrivit pentru servicii mici și independente. Dacă ai nevoie de mai mult control, va trebui să le gestionezi singur sau să folosești o altă abordare. Nomad este pur și simplu un orchestrator.
Cel mai bun aspect al Nomad este că poate fi ușor înlocuit.Legătura cu furnizorul este practic inexistentă, deoarece funcțiile sale pot fi integrate cu ușurință în orice alt sistem care gestionează servicii. Funcționează pur și simplu ca un binary obișnuit pe fiecare mașină din cluster, cam atât!
Ecosistemul Nomad este format din componente slab legate.
Puterea reală a Nomad se află în ecosistemul său. Se integrează foarte bine cu alte produse complet opționale, cum ar fi (magazin cheie-valoare) sau (gestionarea secretelor). În interiorul fișierului Nomad există secțiuni pentru a extrage date din aceste servicii:
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
} Aici citim cheia service/geo-api/log-verbosity din Consul și, pe parcursul execuției, o prezentăm ca variabilă de mediu LOG_LEVEL.De asemenea, prezentăm cheia secret/geo-api-key din Vault ca API_KEY.Simplu, dar puternic!
Datorită simplității sale, Nomad poate fi ușor extins cu alte servicii prin API. De exemplu, sunt acceptate etichete pentru sarcini. Marcăm toate serviciile cu metrici folosind eticheta trv-metrics.Astfel, Prometheus găsește cu ușurință aceste servicii prin Consul și verifică periodic endpoint-ul /metrics pentru date noi. Același lucru se poate face, de exemplu, pentru loguri, folosind .
Există multe alte exemple de extensibilitate:
- Rularea unei sarcini Jenkins printr-un hook, iar Consul monitorizează redeploy-ul sarcinii Nomad atunci când există modificări în configurația serviciului.
- Ceph adaugă în Nomad un sistem de fișiere distribuit.
- pentru echilibrarea încărcării.
Toate acestea permit fără o legătură strânsă cu furnizorul.
Atenție sinceră
Niciun sistem nu este perfect. Nu recomand implementarea imediată în producție a celor mai noi funcții. Desigur, există erori și funcții lipsă, dar aceeași regulă se aplică și Kubernetes.
Comparativ cu Kubernetes, comunitatea Nomad nu este atât de mare. Kubernetes are deja aproximativ 75.000 de commit-uri și 2000 de contribuitori, în timp ce Nomad are cam 14.000 de commit-uri și 300 de contribuitori. Va fi greu pentru Nomad să țină pasul cu Kubernetes în ceea ce privește viteza, dar poate că nici nu este necesar! Este un sistem mai specializat, iar o comunitate mai mică înseamnă că cererea dvs. de pull-request va fi observată și acceptată mai repede în comparație cu Kubernetes.
Rezumat
Concluzie: nu folosiți Kubernetes doar pentru că o fac toți. Evaluați cu atenție cerințele dvs. și verificați care instrument este mai avantajos.
Dacă planificați să desfășurați o mulțime de servicii omogene pe o infrastructură la scară mare, Kubernetes este o opțiune bună. Doar amintiți-vă de complexitatea și costurile operaționale suplimentare. Unele cheltuieli pot fi evitate folosind un mediu Kubernetes gestionat, cum ar fi sau .
Dacă căutați doar un orchestrator de încredere, ușor de întreținut și scalabil, de ce să nu încercați Nomad? S-ar putea să fiți surprins cât de departe vă poate duce.
Dacă comparăm Kubernetes cu o mașină, Nomad ar fi un scooter. Uneori aveți nevoie de unul, alteori de celălalt. Ambele au dreptul de a exista.
Sursa: habr.com
