Lány egy robogón. Ábra , Nomad logó tól
A Kubernetes a konténerhangszerelés 300 kilós gorillája. A világ legnagyobb konténerrendszereiben működik, de drága.
Kisebb csapatok számára különösen drága, ami sok támogatási időt és meredek tanulási görbét igényel. Ez túl sok költség a négyfős csapatunknak. Így hát elkezdtünk alternatívákat keresni – és beleszerettünk .
Mit akarsz
Csapatunk számos általános teljesítményfigyelő és -elemző szolgáltatást támogat: API-végpontok a Go-ban írt metrikákhoz, Prometheus-exportok, naplóelemzők, mint például a Logstash és , valamint olyan adatbázisok, mint az InfluxDB vagy az Elasticsearch. Ezen szolgáltatások mindegyike saját tárolójában fut. Egy egyszerű rendszerre van szükségünk, hogy minden működjön.
A konténerhangszerelés követelményeinek listájával kezdtük:
- Szolgáltatáskészlet futtatása számos gépen.
- A futó szolgáltatások áttekintése.
- Szolgáltatások közötti kapcsolatok.
- Automatikus újraindítás, ha a szolgáltatás leáll.
- Infrastruktúra karbantartás egy kis csapat által.
Ezenkívül a következő dolgok szépek, de nem kötelező kiegészítések:
- Gépek címkézése képességeik alapján (például gyorslemezes gépek címkézése nehéz I/O szolgáltatásokhoz).
- Szolgáltatások futtatásának képessége a hangszerelőtől függetlenül (például a fejlesztés során).
- Közös hely a konfigurációk és a titkok megosztására.
- Végpont a mérőszámokhoz és a naplókhoz.
Miért nem jó nekünk a Kubernetes?
A Kubernetes-es prototípuskészítés során észrevettük, hogy egyre bonyolultabb logikai rétegeket adunk hozzá, amelyekre erősen támaszkodtunk.
Például a Kubernetes támogatja a beépített szolgáltatáskonfigurációkat a következőn keresztül . Gyorsan összezavarodhat, különösen, ha több konfigurációs fájlt egyesít, vagy további szolgáltatásokat ad hozzá egy podhoz. Kubernetes (vagy ebben az esetben) lehetővé teszi a külső konfigurációk dinamikus megvalósítását az egyes szempontok elkülönítésére. Ez azonban szoros, rejtett kapcsolatot eredményez a projekt és a Kubernetes között. A Helm és a ConfigMaps azonban további lehetőségek, így nem kell használnia őket. Egyszerűen átmásolhatja a konfigurációt a Docker-képbe. Csábító azonban ezen az úton haladni, és szükségtelen absztrakciókat építeni, amelyeket később megbánhat.
Ezenkívül a Kubernetes ökoszisztéma gyorsan fejlődik. Sok időt és energiát igényel, hogy naprakész maradjon a legjobb gyakorlatokkal és a legújabb eszközökkel. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - a lista hosszan folytatható. Ezeknek az eszközöknek nincs mindegyikére szükség az induláskor, de nem tudod, mire lesz szükséged, ezért mindennel tisztában kell lenned. Emiatt a tanulási görbe meglehetősen meredek.
Mikor kell használni a Kuberneteset?
Cégünkben sokan használják a Kubernetes-t, és nagyon elégedettek vele. Ezeket a példányokat a Google vagy az Amazon kezeli, akik rendelkeznek a támogatásukhoz szükséges erőforrásokkal.
Kubernetes jön , amelyek kezelhetőbbé teszik a konténerek hangszerelését a méretekben:
- Részletes .
- logikát adjon a klaszterhez. Ezek egyszerűen a Kubernetes API-val kommunikáló programok.
- ! A Kubernetes igény szerint méretezheti a szolgáltatásokat a szolgáltatási mérőszámok segítségével, manuális beavatkozás nélkül.
A kérdés az, hogy valóban szüksége van-e ezekre a funkciókra. Nem hagyatkozhatsz csak az absztrakciókra; .
Csapatunk a legtöbb szolgáltatást távolról nyújtja (a fő infrastruktúrához való szoros kapcsolat miatt), ezért nem akartunk saját Kubernetes klasztert felépíteni. Csak szolgáltatásokat akartunk nyújtani.
Az elemeket nem tartalmazza
A Nomad a hangszerelés 20%-a, amely a szükséges 80%-át biztosítja. Csak a telepítéseket kezeli. A Nomad gondoskodik a telepítésekről, hiba esetén újraindítja a konténereket...és ennyi.
A Nomad lényege az, amit csinál minimum: nincs részletes jogkezelés ill , ezt speciálisan tervezték. Ezeket az alkatrészeket kívülről biztosítják, vagy egyáltalán nem.
Úgy gondolom, hogy a Nomad megtalálta a tökéletes kompromisszumot a könnyű használat és a hasznosság között. Kis, független szolgáltatásokhoz jó. Ha több irányításra van szüksége, magának kell felnevelnie őket, vagy más megközelítést kell alkalmaznia. Nomád az éppen hangszerelő.
A Nomadban az a legjobb, hogy könnyű helyettesít. Gyakorlatilag nincs kapcsolat a szállítóval, mivel annak funkciói könnyen integrálhatók bármely más szolgáltatásokat kezelő rendszerbe. Csak úgy fut, mint egy normál bináris a fürt minden gépén, ez minden!
Nomád ökoszisztéma lazán összekapcsolt összetevőkből
A Nomad igazi ereje az ökoszisztémája. Nagyon jól integrálható más - teljesen opcionális - termékekkel, mint pl (kulcs-érték tároló) ill (titkok feldolgozása). A Nomad fájlban találhatók az adatok kinyerésére szolgáló szakaszok 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 Consultól, és munka közben környezeti változónak tesszük ki LOG_LEVEL. Bemutatjuk a kulcsot is secret/geo-api-key a Vault as API_KEY. Egyszerű, de erőteljes!
Egyszerűsége miatt a Nomad könnyen bővíthető más szolgáltatásokkal API-n keresztül. Például a feladatok címkéi támogatottak. Minden szolgáltatást mérőszámmal látunk el trv-metrics. Így a Prometheus könnyen megtalálhatja ezeket a szolgáltatásokat a Consulon keresztül, és rendszeresen ellenőrizheti a végpontot /metrics új adatokért. Ugyanezt megtehetjük például naplók esetében is, használatával .
Sok más példa is van a bővíthetőségre:
- Futtasson egy Jenkins-feladatot egy hook segítségével, és a Consul figyeli a Nomad job átcsoportosítását, amikor a szolgáltatás konfigurációja megváltozik.
- A Ceph elosztott fájlrendszert ad a Nomadhoz.
- terheléselosztáshoz.
Mindez lehetővé teszi az eladóval való különösebb kapcsolat nélkül.
Tisztességes figyelmeztetés
Egyetlen rendszer sem tökéletes. Nem javaslom a legújabb funkciók azonnali bevezetését a termelésbe. Természetesen vannak hibák és hiányzó funkciók, de ugyanez vonatkozik a Kubernetesre is.
Kuberneteshez képest a Nomád közösség nem olyan nagy. A Kubernetesnek már körülbelül 75 000 commitja és 2000 14 közreműködője van, míg a Nomadnak körülbelül 000 300 commitja és XNUMX közreműködője van. A Nomad nehezen fogja tartani a lépést a Kubernetes sebességével, de talán nem is kell! Ez egy speciálisabb rendszer, és a kisebb közösség azt is jelenti, hogy a Kuberneteshez képest nagyobb valószínűséggel veszik észre és fogadják el a lehívási kérelmet.
Összegzés
A lényeg: Ne használja a Kubernetes-t csak azért, mert mindenki más csinálja. Gondosan mérlegelje igényeit, és ellenőrizze, melyik eszköz előnyösebb.
Ha egy csomó homogén szolgáltatást tervez telepíteni egy nagyszabású infrastruktúrára, akkor a Kubernetes jó választás. Csak legyen tudatában a megnövekedett összetettségnek és a működési költségeknek. Egyes költségek elkerülhetők egy felügyelt Kubernetes környezet használatával, mint pl vagy .
Ha csak egy megbízható hangszerelőt keres, amely könnyen karbantartható és bővíthető, miért nem próbálja ki a Nomadot? Meglepődhet, milyen messzire visz ez téged.
Ha a Kubernetest egy autóhoz hasonlítjuk, a Nomad robogó lenne. Néha egy dologra van szükséged, néha pedig másra. Mindkettőnek joga van létezni.
Forrás: will.com