Fata pe scuter. Ilustrare Freepik, Logo Nomad de la HashiCorp

Kubernetes este gorila de 300 de lire a orchestrarii containerelor. Funcționează în unele dintre cele mai mari sisteme de containere din lume, dar este scump.

Deosebit de costisitoare pentru echipele mai mici, care vor necesita mult timp de suport și o curbă abruptă de învățare. Acest lucru este prea mult pentru echipa noastră de patru. Așa că am început să căutăm alternative – și ne-am îndrăgostit nomad.

Ce vrei

Echipa noastră acceptă o serie de servicii comune de monitorizare și analiză a performanței: puncte finale API pentru valorile scrise în Go, exporturi Prometheus, analizoare de jurnal, cum ar fi Logstash și Gollum, precum și baze de date precum InfluxDB sau Elasticsearch. Fiecare dintre aceste servicii rulează în propriul container. Avem nevoie de un sistem simplu pentru a menține totul în funcțiune.

Am început cu o listă de cerințe pentru orchestrarea containerelor:

• Rularea unui set de servicii pe multe mașini.
• Prezentare generală a serviciilor care rulează.
• Legături între servicii.
• Repornire automată dacă serviciul scade.
• Întreținerea infrastructurii de către o echipă mică.

În plus, următoarele lucruri vor fi drăguțe, dar nu sunt necesare completări:

• Etichetarea mașinilor pe baza capacităților lor (de exemplu, etichetarea mașinilor cu discuri rapide pentru servicii I/O grele).
• Abilitatea de a rula servicii independent de orchestrator (de exemplu, în timpul dezvoltării).
• Un loc comun pentru a împărtăși configurații și secrete.
• Punct final pentru valori și jurnale.

De ce Kubernetes nu este potrivit pentru noi

Pe măsură ce am creat prototipuri cu Kubernetes, am observat că adăugam straturi din ce în ce mai complexe de logică pe care ne bazam foarte mult.

De exemplu, Kubernetes acceptă configurații de servicii încorporate prin ConfigMaps. Puteți deveni rapid confuz, mai ales când îmbinați mai multe fișiere de configurare sau adăugați servicii suplimentare la un pod. Kubernetes (sau cârmă în acest caz) vă permite să implementați în mod dinamic configurații externe pentru a separa preocupările. Dar acest lucru are ca rezultat o cuplare strânsă și ascunsă între proiectul dvs. și Kubernetes. Cu toate acestea, Helm și ConfigMaps sunt opțiuni suplimentare, așa că nu trebuie să le utilizați. Puteți copia pur și simplu configurația în imaginea Docker. Cu toate acestea, este tentant să mergi pe această cale și să construiești abstracții inutile pe care s-ar putea să le regreti mai târziu.

În plus, ecosistemul Kubernetes evoluează rapid. Este nevoie de mult timp și energie pentru a fi la curent cu cele mai bune practici și cu cele mai recente instrumente. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - lista poate continua. Nu toate aceste instrumente sunt necesare atunci când începi, dar nu știi de ce vei avea nevoie, așa că trebuie să fii conștient de tot. Din această cauză, curba de învățare este destul de abruptă.

Când să folosiți Kubernetes

În compania noastră, mulți oameni folosesc Kubernetes și sunt destul de mulțumiți de el. Aceste instanțe sunt gestionate de Google sau Amazon, care au resursele necesare pentru a le susține.

Kubernetes vine cu caracteristici uimitoare, care fac orchestrarea containerelor la scară mai gestionabilă:

• Detaliat managementul drepturilor.
• Controlere personalizate adăugați logica clusterului. Acestea sunt pur și simplu programe care vorbesc cu API-ul Kubernetes.
• Autoscaling! Kubernetes poate scala serviciile la cerere utilizând valorile serviciilor și fără a necesita intervenție manuală.

Întrebarea este dacă într-adevăr aveți nevoie de toate aceste caracteristici. Nu te poți baza doar pe abstracții; va trebui să afli ce se întâmplă sub capotă.

Echipa noastră oferă cele mai multe servicii de la distanță (datorită conexiunii strânse la infrastructura principală), așa că nu am vrut să ne ridicăm propriul cluster Kubernetes. Am vrut doar să oferim servicii.

Bateriile nu sunt incluse

Nomad este 20% din orchestrație 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 atât.

Scopul lui Nomad este ceea ce face minim: fără gestionare granulară a drepturilor sau politici extinse de rețea, acesta este special conceput. Aceste componente sunt furnizate extern sau deloc.

Cred că Nomad a găsit compromisul perfect între ușurința în utilizare și utilitate. Este bun pentru servicii mici, independente. Dacă aveți nevoie de mai mult control, va trebui să le ridicați singur sau să utilizați o abordare diferită. Nomad este doar orchestrator.

Cel mai bun lucru despre Nomad este că este ușor înlocuiți. Practic, nu există nicio conexiune cu vânzătorul, deoarece funcțiile acestuia sunt ușor de integrat în orice alt sistem care gestionează serviciile. Pur și simplu rulează ca un binar obișnuit pe fiecare mașină din cluster, asta e tot!

Ecosistem nomad de componente slab cuplate

Adevărata forță a Nomadului este ecosistemul său. Se integrează foarte bine cu alte produse - complet opționale - precum Consul (magazin cheie-valoare) sau Boltă (prelucrarea secretelor). În interiorul fișierului Nomad există secțiuni pentru extragerea datelor 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 de la Consul și în timp ce lucrăm îl expunem unei variabile de mediu LOG_LEVEL. Vă prezentăm și cheia secret/geo-api-key din Vault ca API_KEY. Simplu dar puternic!

Datorită simplității sale, Nomad este ușor de extensibil cu alte servicii prin API. De exemplu, etichetele pentru sarcini sunt acceptate. Etichetăm toate serviciile cu valori trv-metrics. În acest fel, Prometheus poate găsi cu ușurință aceste servicii prin Consul și poate verifica periodic punctul final /metrics pentru date noi. Același lucru se poate face, de exemplu, pentru jurnalele, folosind Loki.

Există multe alte exemple de extensibilitate:

• Rulați un job Jenkins folosind un cârlig, iar Consul monitorizează redistribuirea jobului Nomad atunci când configurația serviciului se modifică.
• Ceph adaugă un sistem de fișiere distribuit la Nomad.
• Fabio pentru echilibrarea sarcinii.

Toate acestea permit dezvoltarea organică a infrastructurii fără nicio legătură specială cu vânzătorul.

Avertisment corect

Niciun sistem nu este perfect. Nu recomand introducerea imediată a celor mai noi funcții în producție. Desigur, există erori și funcții lipsă, dar același lucru este valabil și pentru Kubernetes.

În comparație cu Kubernetes, comunitatea Nomad nu este atât de mare. Kubernetes are deja aproximativ 75 de comiteri și 000 de colaboratori, în timp ce Nomad are aproximativ 2000 de comiteri și 14 de colaboratori. Nomad va avea greu să țină pasul cu viteza Kubernetes, dar poate că nu trebuie! Este un sistem mai specializat, iar comunitatea mai mică înseamnă, de asemenea, că cererea dvs. de extragere este mai probabil să fie observată și acceptată, în comparație cu Kubernetes.

Rezumat

Concluzie: nu utilizați Kubernetes doar pentru că toți ceilalți o fac. Evaluați-vă cerințele cu atenție și verificați care instrument este mai benefic.

Dacă intenționați să implementați o mulțime de servicii omogene pe o infrastructură la scară largă, atunci Kubernetes este o opțiune bună. Trebuie doar să fiți conștienți de complexitatea suplimentară și costurile de operare. Unele costuri pot fi evitate prin utilizarea unui mediu Kubernetes gestionat, cum ar fi Google Kubernetes Engine sau Amazon EKS.

Dacă sunteți doar în căutarea unui orchestrator de încredere, ușor de întreținut și extensibil, de ce să nu încercați Nomad? S-ar putea să fii surprins cât de departe te va duce asta.

Dacă Kubernetes este comparat cu o mașină, Nomad ar fi un scuter. Uneori ai nevoie de un lucru, alteori ai nevoie de altul. Ambii au dreptul de a exista.

Sursa: www.habr.com