Një vajzë në skuter. Ilustrim , logoja Nomad nga
Kubernetes është një gorillë prej 300 kilogramësh për orkestrimin e kontejnerëve. Ajo punon në disa nga sistemet më të mëdha të kontejnerizimit në botë, por është e shtrenjtë.
Veçanërisht e shtrenjtë për ekipet e vogla, që do të duhet të kalojnë shumë kohë në mbështetje dhe një kurbë të vështirë të të mësuarit. Për ekipin tonë prej katër personash, kjo është shumë kostot e shtuara. Prandaj, filluam të kërkojmë alternativa dhe u dashuruam me .
Çfarë dëshirojmë
Ekipi ynë mbështet një gamë të shërbimeve tipike për monitorimin dhe analizimin e performancës: pika API për metrikat e shkruara në Go, eksportimi i Prometheus, parsers log për shumëllojshmëri si Logstash dhe , si dhe baza të dhënash si InfluxDB ose Elasticsearch. Çdo një nga këto shërbime funksionon në kontejnerin e vet. Na nevojitet një sistem i thjeshtë për të mbajtur gjithçka në gjendje pune.
Ne filluam me një listë kërkesash për orkestrimin e kontejnerëve:
- Nisja e një grupi shërbimesh në shumë makina.
- Përmbledhja e shërbimeve të nisura.
- Lidhjet midis shërbimeve.
- Rifillimi automatik nëse shërbimi pushon.
- Kujdesi 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 shtesa të detyrueshme:
- Etiketimi i makinave sipas mundësive të tyre (p.sh. etiketimi i makinave me disqe të shpejtë për shërbimet e rënda të I/O).
- Mundësia për të nismuar shërbime pa orkestrator (p.sh. gjatë zhvillimit).
- Një vend i përbashkët për ndarjen e konfigurimeve dhe sekretëve.
- Një pikë për metrikat dhe logjet.
Pse Kubernetes nuk na përshtatet
Kur krijonim një prototip me Kubernetes, vërejta se po shtonim gjithnjë e më shumë shtresa komplekse logjike në të cilat mbështeteshim pa ndonjë hezitim.
Si një shembull, Kubernetes mbështet konfigurimet e shërbimeve të integruara përmes . Ju mund të ngatërroni shpejt, sidomos kur bashkoni disa skedarë konfigurimi apo shtoni shërbime shtesë në pod. Kubernetes (ose në këtë rast) lejon integrimin e konfiguratave dinamike të jashtme 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ë mundësi shtesë, kështu që nuk është e nevojshme t'i përdorni ato. Ju mund të kopjoni thjesht konfigurimin në imazhin Docker. Sidoqoftë, është tërheqëse të shkoni në këtë drejtim dhe të ndërtoni 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ë mbajtur gjurmët e praktikave më të mira dhe mjeteve më të reja. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - lista vazhdon. Në fillim, nuk nevojiten të gjitha këto mjete, por nuk e dini se çfarë do t’ju nevojitet, kështu që duhet të jeni në dijeni të gjithçkaje. Për këtë arsye, curva e mësimit është mjaft e pjerrët.
Kur të përdorni Kubernetes
Në kompaninë tonë, shumë përdorin Kubernetes dhe janë të kënaqur me të. Këto instance menaxhohen nga Google ose Amazon, të cilët kanë burime të mjaftueshme për ta mbështetur.
Kubernetes vjen me , të cilat e bëjnë orkestrimin e konteinerëve më të menaxhueshëm:
- Menaxhim të detajuar .
- shtojnë logjikë në klaster. Këto janë thjesht programe që komunikojnë me Kubernetes API.
- ! Kubernetes di të shkallëzojë shërbimet sipas kërkesës, duke përdorur metrikat e shërbimeve dhe pa kërkuar ndërhyrje manuale.
Pyetja është nëse ju nevojiten vërtet të gjitha këto funksionalitete. Nuk do të mund të mbështeteni thjesht në abstraksione; .
Ekipi ynë ofron shumicën e shërbimeve në distancë (për shkak të lidhjes së ngushtë me infrastrukturën kryesore), prandaj nuk deshëm të ngrinim një klaster Kubernetes tonë. Ne thjesht donim të ofronim shërbime.
Bateritë nuk janë përfshira
Nomad është 20% orkestrim, që ofron 80% të nevojshme. E gjithë ajo që bën është menaxhimi i shpërndarjeve. Nomad kujdeset për shpërndarjet, riparon konteinerët në rast gabimesh... dhe kjo është gjithçka.
E gjithë kuptimi i Nomad është se çfarë bën minimum: nuk ka menaxhim të detajuar të të drejtave ose , ashtu siç është menduar. Këto komponente ofrohen nga jashtë ose nuk ofrohen fare.
Mendoj se Nomad ka gjetur kompromisin ideal midis lehtësisë së përdorimit dhe përdorshmërisë. Është i shkëlqyer për shërbime të vogla, të pavarura. Nëse nevojitet më shumë kontroll, do të duhet t'i ngrini ato vetë ose të përdorni një qasje tjetër. Nomad është thjesht orkestrator.
Më e mira në lidhje me Nomad është se është e lehtë të zëvendësohet. Përgjigja ndaj çdo ofruesi praktikisht mungon, pasi funksionet e tij integrohen lehtësisht në çdo sistem tjetër që menaxhon shërbime. Ai funksionon thjesht si një binar i zakonshëm në çdo makinë në klaster, kjo është e gjitha!
Ekosistemi i Nomad përbëhet nga komponentë të lidhur në mënyrë të lirë
Fuqia reale e Nomad është në ekosistemin e tij. Ai integrohet shumë mirë me produkte të tjera - tërësisht opsionale - si (magazinë çelës-vlerë) ose (përpunimi i sekreteve). Brenda skedarit 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ë procesit e prezantojmë atë si një variabël mjedisore LOG_LEVEL. Ne gjithashtu e prezantojmë çelësin secret\/geo-api-key nga Vault si API_KEY. Thjesht, por e fuqishme!
Falë thjeshtësisë së tij, Nomad lehtësohet përmes shërbjeve të tjera përmes API. Për shembull, mbështeten etiketat për detyrat. Ne e markojmë 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 rregullisht skedarin /metrics për të gjetur të dhëna të reja. E njëjta gjë mund të bëhet, për shembull, për logët, duke përdorur .
Ka shumë shembuj të tjerë të zgjerueshmërisë:
- Nisja e një detyre Jenkins përmes një hiku, dhe Consul monitoron ri-deploy-n e detyrës Nomad me ndryshimet në konfigurimin e shërbimit.
- Ceph shton në Nomad një sistem të shpërndarë skedarësh.
- për balancimin e ngarkesës.
Të gjithë këta faktorë lejojnë pa ndonjë lidhje të veçantë me ofruesin.
Kujdes i sinqertë
Asnjë sistem nuk është i përsosur. Nuk rekomandoj të aplikoni menjëherë funksionet më të reja në prodhim. Sigurisht, ka gabime dhe funksione të 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 kontribuues, ndërsa Nomad ka rreth 14,000 komitete dhe 300 kontribuues. Do të jetë e vështirë për Nomad të qëndrojë dhe të mos mbetet pas në shpejtësi krahasuar me Kubernetes, por ndoshta kjo nuk është e nevojshme! Është një sistem më i specializuar, dhe një komunitet më i vogël do të thotë gjithashtu që kërkesa juaj do të vërehet dhe pranohet më shpejt, krahasuar me Kubernetes.
CV
Përfundimi: mos përdorni Kubernetes thjesht sepse të tjerët e bëjnë këtë. Vlerësoi me kujdes kërkesat e tua dhe shiko se cili mjet është më i favorshëm.
Nëse planifikoni të Zhvilloni shumë shërbime homogjene në një Infrastrukturë të madhe, atëherë Kubernetes është një mundësi e mirë. Thjesht kini parasysh kompleksitetin e shtuar dhe shpenzimet operacionale. Disa shpenzime mund të shmangen duke përdorur një mjedis të menaxhuar Kubernetes, të tillë si ose .
Nëse thjesht po kërkoni një orkestrues të besueshëm, të lehtë për t'u mbajtur dhe të zgjerueshëm, pse të mos provoni Nomad? Ndoshta do të habiteni se sa larg mund t'ju çojë.
Nëse e krahasojmë Kubernetes me një makinë, Nomad do të ishte një skuter. Ndonjëherë keni nevojë për njëra, ndonjëherë për tjetrën. Të dyja kanë të drejtë për të ekzistuar.
Burimi: habr.com
