Një vajzë në skuter. Ilustrim freepik, logotipi Nomad nga HashiCorp

Kubernetes është një gorilë 300-kilogramëshe për orkestrimin e kontejnerëve. Ajo funksionon në disa nga sistemet më të mëdha të kontejnerëve në botë, por është shumë e kushtueshme.

Veçanërisht e shtrenjtë për ekipet e vogla, të cilat do të duhet të kalojnë shumë kohë në mbështetje dhe një kurbë të mësuarit të theksuar. Për ekipin tonë prej katër personash, kjo është shumë shpenzim i tepruar. Kështu që filluam të kërkojmë alternativa - dhe u dashuruam me Nomad.

Çfarë na nevojitet

Ekipi ynë mbështet një sërë shërbimesh tipike për monitorimin dhe analizimin e performancës: pikët e fundit të API-ve për metrikat, të shkruara në Go, eksportin e Prometheus, parserët e log-eve si Logstash dhe Gollum, si dhe bazat e të dhënave si InfluxDB ose Elasticsearch. Çdo njëri nga këto shërbime funksionon në kontejnerin e tij. Na nevojitet një sistem i thjeshtë për ta mbajtur të gjithë këtë në gjendje operative.

Filluam me një listë kërkesash për orkestrimin e kontejnerëve:

• Nisja e një seti shërbimesh në shumë makina.
• Përmbledhja e shërbimeve të nisura.
• Lidhjet midis shërbimeve.
• Rifillim automatik nëse shërbimi dështon.
• Menaxhimi i infrastrukturës nga një ekip i vogël.

Për më tepër, gjërat e mëposhtme do të ishin të këndshme, por jo të domosdoshme:

• Shënimi i makinave sipas mundësive të tyre (p.sh., shënimi i makinave me disqe të shpejtë për shërbime të rënda hyrjeje-daljeje).
• Mundësia për të ekzekutuar shërbime pavarësisht nga orkestratori (p.sh., gjatë zhvillimit).
• Një vend i përbashkët për ndarjen e konfigurimeve dhe sekreteve.
• Një fund për metrikat dhe logët.

Pse Kubernetes nuk është për ne

Kur krijonim një prototip me Kubernetes, vërejtëm se po shtonim gjithnjë e më shumë shtresa komplekse logjike, në të cilat besonim pa dyshim.

Si një shembull, Kubernetes mbështet konfigurimet e integruara të shërbimeve përmes ConfigMaps. Ju mund të ngatërroheni shpejt, veçanërisht kur bashkoni disa skedarë konfigurimi ose shtoni shërbime të tjera në pod. Kubernetes (ose helm në këtë rast) lejon integrimin e konfigurimeve të jashtme dinamikisht për ndarjen e interesave. Por kjo çon në një lidhje të fortë të fshehtë midis projektit tuaj dhe Kubernetes. Megjithatë, Helm dhe ConfigMaps janë opsione shtesë, prandaj nuk është e domosdoshme t’i përdorni ato. Mund të kopjoni thjesht konfigurimin në imazhin Docker. Megjithatë, është joshëse të shkojmë në këtë rrugë dhe të ndërtojmë abstraksione të panevojshme, për të cilat mund të pendoheni më vonë.

Për më tepër, ekosistemi i Kubernetes po zhvillohet shpejt. Kërkohet shumë kohë dhe energji për të qenë në dijeni të praktikave më të mira dhe mjeteve më të reja. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - lista vazhdon e vazhdon. Në fillim të punës, nuk nevojiten të gjithë këto mjete, por nuk e dini se çfarë do të nevojitet, prandaj duhet të jeni në dijeni të gjithçkaje. Për këtë arsye, ecuria e të mësuarit është mjaft e pjerrët.

Kur të përdorni Kubernetes

Në kompaninë tonë, shumë përdorin Kubernetes dhe janë mjaft të kënaqur me të. Këto instance menaxhohen nga Google ose Amazon, të cilët kanë burimet e mjaftueshme për ta mbështetur.

Kubernetes vjen me veçori të mahnitshme, që e bëjnë orkestrimin masiv të kontejnerëve më të menaxhueshëm:

• Detajuar menaxhimi i të drejtave.
• Kontrollues të personalizuar shtojnë logjikë në klaster. Këto janë thjesht programe që komunikojnë me Kubernetes API.
• Automatikisht shkallëzimi! Kubernetes është në gjendje të shkallëzojë shërbimet sipas nevojës, duke përdorur metrikat e shërbimit dhe pa kërkuar ndërhyrje manuale.

Çështja është nëse vërtet keni nevojë për të gjitha këto funksione. Nuk mund të mbështeteni vetëm në abstraksione; duhet të mësoni se çfarë ndodh nën kapak.

Ekipi ynë ofron shumicën e shërbimeve në distancë (për shkak të lidhjes së ngushtë me infrastrukturën kryesore), kështu që ne nuk donim të ngrinim një klaster Kubernetes. Dëshironim thjesht të ofronim shërbime.

Bateritë nuk janë të përfshira

Nomad është 20% orkestrim, i cili jep 80% të nevojshëm. E gjithë ajo që bën është menaxhimi i implementimeve. Nomad merret me implementimet, rinis konteineret në rast gabimesh… dhe kjo është e gjitha.

Ideja e Nomad është që ai bën minimumi: asnjë menaxhim të detajuar të të drejtave ose politikat e avancuara të rrjetit, ashtu si është menduar. Këto komponentë ofrohen nga jashtë ose nuk ofrohen fare.

Mendoj se Nomad ka gjetur një kompromis të përsosur midis lehtësisë së përdorimit dhe dobisë. Ai është i mirë për shërbime të vogla, të pavarura. Nëse ju nevojitet më shumë kontroll, do t'ju duhet ta ngrini vetë ose të përdorni një qasje tjetër. Nomad është thjesht një orkestrues.

Më e mira në Nomad është se është lehtë zëvendësuar. Kapja ndaj shitësit është praktikisht e paeksistueshme, pasi funksionaliteti i tij integrohet lehtësisht në çdo sistem tjetër që menaxhon shërbime. Ai funksionon thjesht si një binar normal në çdo makinë në klaster, ky është gjithë qëllimi!

Ekosistemi i Nomad përbëhet nga komponente të lidhura dobët

Forca reale e Nomad është në ekosistemin e tij. Ai integrohet shumë mirë me produkte të tjera — krejtësisht opcionale — si Consul (depo çelës-vlerë) apo Vault (menaxhimi i sekreteve). Brenda skedarit të Nomad ka seksione për nxjerrjen e të dhënave nga këto shërbime:

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
}

Këtu ne lexojmë çelësin service/geo-api/log-verbosity nga Consul dhe gjatë funksionimit e paraqesim atë si një variabël të ambientit LOG_LEVEL. Ne gjithashtu paraqesim çelësin secret/geo-api-key nga Vault si API_KEY. E thjeshtë, por e fuqishme!

Falë thjeshtësisë së tij, Nomad lehtësohet zgjerimi me shërbime të tjera përmes API-së. Për shembull, etiketat për detyrat mbështeten. Ne etiketojmë të gjitha shërbimet me metrika me etiketën trv-metrics. Kështu, Prometheus i gjen lehtësisht këto shërbime përmes Consul dhe kontrollon periodicisht pikën e fundit /metrics për të dhëna të reja. E njëjta gjë mund të bëhet, për shembull, për logs, duke përdorur Loki.

Ka shumë shembuj të tjerë të zgjerueshmërisë:

• Ekzekutimi i një detyre Jenkins përmes një hook, ndërsa Consul ndjek ri-deploy të detyrës Nomad kur ndodhin ndryshime në konfigurimin e shërbimit.
• Ceph shton në Nomad një sistem të shpërndarë skedarësh.
• fabio për balancimin e ngarkesës.

Të gjitha këto lejojnë zhvillimin organik të infrastrukturës pa lidhje të veçantë me ofruesin.

Kujdes i sinqertë

Asnjë sistem nuk është perfekt. Nuk rekomandoj të implementoni menjëherë funksionalitetet më të reja në prodhim. Sigurisht, ka gabime dhe funksione që mungojnë, por e njëjta gjë vlen edhe për Kubernetes.

Në krahasim me Kubernetes, komuniteti i Nomad nuk është aq i madh. Kubernetes ka rreth 75,000 komitete dhe 2000 kontribues, ndërsa Nomad ka rreth 14,000 komitete dhe 300 kontribues. Do të jetë e vështirë për Nomad që të mbetet në konkurrencë me Kubernetes në shpejtësi, por ndoshta kjo nuk është e nevojshme! Kjo është një sistem më i specializuar, dhe një komunitet më i vogël gjithashtu do të thotë se kërkesat tuaja për pull-request ka më shumë gjasa të duken dhe të pranojnë, krahasuar me Kubernetes.

Curriculum Vitae

Përfundim: mos e përdorni Kubernetes thjesht sepse e bëjnë të gjitha. Vlerësoni me kujdes kërkesat tuaja dhe shikoni se cili është mjeti më i përshtatshëm.

Nëse planifikoni të vendosni shumë shërbime homogjene në një infrastrukturë të madhe, Kubernetes është një opsion i mirë. Thjesht mbani mend kompleksitetin shtesë dhe shpenzimet operative. Disa shpenzime mund të shmangen duke përdorur një mjedis të menaxhuar Kubernetes, siç është Google Kubernetes Engine ose Amazon EKS.

Nëse thjesht po kërkoni një orkestrues të besueshëm, të lehtë për tu mbajtur dhe të zgjerueshëm, pse mos ta provoni Nomad? Ndoshta do të befasoheni se sa larg mund t'ju çojë.

Nëse Kubernetes mund të krahasohet me një makinë, Nomad do të ishte një skuter. Ndonjëherë ju nevojitet njëra, ndonjëherë tjetra. Të dy kanë vendin e tyre.

Burimi: habr.com