Lány robogón. Illusztráció freepik, a Nomad logója HashiCorp

A Kubernetes egy 300 kilogrammos gorilla a konténer-orchestration számára. A világ legnagyobb konténeres rendszereiben működik, de költséges.

Különösen drága a kis csapatok számára, akiknek sok időt kell tölteniük a támogatásával és a meredek tanulási görbe miatt. A négyfős csapatunk számára ez túl sok adminisztratív költséget jelentett. Ezért alternatívákat kezdtünk keresni – és beleszerettünk a A Nomad.

Amit szeretnénk

Csapatunk számos tipikus szolgáltatást támogat a monitorozás és a teljesítmény-elemzés érdekében: metrikák API végpontjai, amelyeket Go nyelven írtunk, Prometheus-exportálás, logparser-ek, mint például a Logstash és a Gollum, valamint adatbázisok, mint az InfluxDB vagy az Elasticsearch. Mindegyik szolgáltatás a saját konténerében fut. Szükségünk van egy egyszerű rendszerre, hogy mindezt működtetni tudjuk.

Kezdtük egy követelménylistával a konténer-orchestrationhoz:

• Szolgáltatások futtatása több gépen.
• Futó szolgáltatások áttekintése.
• Kapcsolatok a szolgáltatások között.
• Automatikus újraindítás, ha a szolgáltatás leáll.
• Infrastrukturális karbantartás kis csapat által.

Ezen kívül a következő dolog kellemes lenne, de nem kötelező kiegészítések:

• Gépek megjelölése képességeik alapján (például gyors lemezekkel rendelkező gépek címkézése I/O-intenzív szolgáltatásokhoz).
• Lehetőség szolgáltatások független futtatására az orchestrátortól (például fejlesztés során).
• Közös hely a konfigurációk és titkok megosztására.
• Végpont metrikákhoz és naplókhoz.

Miért nem felel meg nekünk a Kubernetes

Amikor prototípust készítettünk a Kubernetesszel, észrevettük, hogy egyre bonyolultabb logikai rétegeket kezdtünk hozzáadni, amelyekre feltétel nélkül támaszkodtunk.

Például a Kubernetes beépített szolgáltatáskonfigurációkat támogat a ConfigMap-ek. Gyorsan el lehet veszni, különösen, ha több konfigurációs fájlt egyesítünk vagy további szolgáltatásokat adunk a podhoz. A Kubernetes (vagy helm Ebben az esetben lehetővé teszi a külső konfigurációk dinamikus integrálását az érdekek elkülönítésére. Ez azonban szoros rejtett kapcsolatot teremt a projektje és a Kubernetes között. Ugyanakkor a Helm és a ConfigMaps kiegészítő opciók, így nem kötelező őket használni. Egyszerűen átmásolhatja a konfigurációt a Docker képbe. Ennek ellenére csábító lehet ezen az úton elindulni, és felesleges absztrakciókat építeni, amit később megbánhat.

Továbbá, a Kubernetes ökoszisztéma gyorsan fejlődik. Nagyon sok időt és energiát igényel, hogy naprakészen kövesse a legjobb gyakorlatokat és a legújabb eszközöket. A Kubectl, a minikube, a kubeadm, a helm, a tiller, a kops, az oc - a lista folytatódik. Az induláskor nem szükséges mindez az eszköz, de nem tudja, mire lesz szüksége, ezért mindent érdemes nyomon követni. Emiatt a tanulási görbe meglehetősen meredek.

Mikor használjunk Kubernetes-t

Cégünknél sokan használják a Kubernetes-t, és elégedettek vele. Ezeket az instanciákat a Google vagy az Amazon kezeli, amelyek rendelkeznek a támogatásukhoz szükséges erőforrásokkal.

A Kubernetes a következőkkel érkezik lenyűgöző funkciókkal, amelyek kezelhetőbbé teszik a konténerek nagy léptékű orchestration-ját:

• Részletes hozzáférés-ellenőrzés.
• A testreszabott vezérlők logikát adnak a klaszterhez. Ezek egyszerű programok, amelyek kommunikálnak a Kubernetes API-val. Automatikus skálázás
• ! A Kubernetes képes a szolgáltatásokat igény szerint skálázni, szolgáltatási metrikák alapján, és nem igényel kézi beavatkozást.A kérdés az, hogy valóban szüksége van-e mindezekre a funkciókra. Nem lehet csak az absztrakciókra támaszkodni;

meg kell tanulnia, mi történik a motorháztető alatt Csapatunk a legtöbb szolgáltatást távolról nyújtja (a fő infrastruktúrával való szoros kapcsolat miatt), ezért nem akartunk saját Kubernetes klasztert létrehozni. Csak a szolgáltatásokat szerettük volna biztosítani..

Elemek nem tartoznak a csomaghoz

A Nomad a 20%-os orchestration, ami 80%-ot ad meg a szükségesből. Mindössze annyit tesz, hogy kezeli a telepítéseket. A Nomad foglalkozik a telepítésekkel, újraindítja a konténereket, ha hiba történik... és ennyi.

A Nomad lényege az, hogy mit csinál:

nincs részletes hozzáférés-ellenőrzés vagy minimumkiterjesztett hálózati politikák , ez szándékosan lett megtervezve. Ezeket az összetevőket külső források biztosítják, vagy egyáltalán nem elérhetők., ezt szándékosan így tervezték. Ezek az alkatrészek harmadik féltől származnak, vagy egyáltalán nem állnak rendelkezésre.

Úgy gondolom, hogy a Nomad megtalálta az ideális egyensúlyt a használhatóság és a funkcionalitás között. Kiválóan alkalmas kis, független szolgáltatásokhoz. Ha több kontrollra van szükség, akkor azt magának kell létrehoznia, vagy más megközelítést kell alkalmaznia. A Nomad egy egyszerűen orchestrátor.

A Nomad legjobb tulajdonsága, hogy könnyen ki kell cserélni. A vendorhoz való kötődés gyakorlatilag elhanyagolható, mivel a funkciói könnyen integrálhatók bármely más szolgáltatáskezelő rendszerbe. Csakúgy működik, mint egy sima bináris fájl a klaszter minden gépén, és ennyi!

A Nomad ökoszisztémája lazán összekapcsolt komponensekből áll.

A Nomad valódi ereje az ökoszisztémájában rejlik. Nagyon jól integrálódik más, teljesen opcionális termékekkel, például Consul (kulcs-érték tároló) vagy Vault (titkok kezelése). A Nomad fájlban szekciók találhatók az adatok kinyerésére ezekből a szolgáltatásokból:

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
}

Itt olvassuk a kulcsot service/geo-api/log-verbosity a Consul-ból, és a futás során környezeti változóként jelenítjük meg LOG_LEVEL. A kulcsot is bemutatjuk secret/geo-api-key a Vault-ból, mint API_KEY.Egyszerű, de hatékony!

A Nomad egyszerűsége révén könnyen bővíthető más szolgáltatásokkal az API-n keresztül. Például támogatja a címkézést a munkák számára. Minden szolgáltatóhoz, amely metrikákkal rendelkezik, hozzárendeljük a trv-metricscímkét. Így a Prometheus könnyen megtalálja ezeket a szolgáltatásokat a Consul révén, és időszakonként ellenőrzi a végpontot /metrics új adatokért. Ugyanezt meg lehet tenni például a naplókkal is, használva Loki.

Sok más példa van a bővíthetőségre:

• Jenkins feladat indítása egy hook-on keresztül, miközben a Consul figyeli a Nomad feladat újraelképzelését a szolgáltatás konfigurációs változásakor.
• A Ceph egy elosztott fájlrendszert ad a Nomad-hoz.
• fabio a terheléselosztáshoz.

Mindez lehetővé teszi a infrastruktúra organikus fejlődését különösebb vendorhoz való kötődés nélkül.

Őszinte figyelmeztetés.

Egyetlen rendszer sem tökéletes. Nem javaslom, hogy azonnal vezessék be a legújabb funkciókat a termelésbe. Természetesen vannak hibák és hiányzó funkciók, de ugyanez vonatkozik a Kubernetesre is.

A Kuberneteshez képest a Nomad közössége nem annyira nagy. A Kubernetes már körülbelül 75 000 elkötelezettéssel és 2000 hozzájárulóval rendelkezik, míg a Nomad körülbelül 14 000 elkötelezettéssel és 300 hozzájárulóval rendelkezik. A Nomadnak nehéz lesz tartani a lépést a Kubernetes sebességével, de talán ez nem is szükséges! Ez egy speciálisabb rendszer, és egy kisebb közösség azt is jelenti, hogy a pull kérelmét valószínűbb, hogy észreveszik és elfogadják, mint a Kubernetes esetében.

Összefoglaló

Következtetés: ne használja a Kubernetest csak azért, mert mindenki más azt csinálja. Gondosan értékelje a követelményeit, és nézze meg, hogy melyik eszköz a kedvezőbb.

Ha egy nagy léptékű infrastruktúrán számos homogén szolgáltatást kíván telepíteni, akkor a Kubernetes jó választás. Csak ne feledje a plusz bonyolultságot és működési költségeket. Egyes költségeket elkerülhet, ha használ egy kezelt Kubernetes környezetet, például Google Kubernetes Engine vagy Amazon EKS.

Ha csak egy megbízható, könnyen karbantartható és skálázható orchestratort keres, miért ne próbálná ki a Nomadot? Lehet, hogy meglepődik, hogy mennyire messzire eljuthat vele.

Ha a Kubernest autóhoz hasonlítjuk, a Nomad egy robogó. Néha egyiket szeretné, néha pedig a másikat. Mindkettőnek megvan a helye.

Forrás: habr.com