Helló, a nevem Dmitrij Krasznov. Több mint öt éve foglalkozom Kubernetes-fürtök adminisztrálásával és komplex mikroszolgáltatási architektúrák kiépítésével. Az idei év elején elindítottuk a Kubernetes klaszterek kezelésére szolgáló szolgáltatást a Containerum bázisán. Megragadva a lehetőséget, elmondom, mi az a Kubernetes, és miben különbözik a szállítóval való integráció a nyílt forráskódtól.
Kezdetnek mi az . Ez egy rendszer a konténerek kezelésére nagyszámú gazdagépen. Görögből egyébként „pilóta” vagy „kormányos”-nak fordítják. Eredetileg a Google fejlesztette ki, majd technológiai hozzájárulásként adományozták a Cloud Native Computing Foundation nevű nemzetközi non-profit szervezetnek, amely a világ vezető fejlesztőit, végfelhasználóit és konténertechnológiai szolgáltatóit tömöríti.
Nagyszámú konténer kezelése
Most nézzük meg, hogy milyen konténerek ezek. Ez egy alkalmazás a teljes környezetével - főként a programkönyvtárakkal, amelyektől a program függ. Mindezt archívumba csomagolják, és operációs rendszertől függetlenül futtatható, tesztelhető és így továbbfejlesztett kép formájában mutatják be. De van egy probléma - a konténerek kezelése nagyszámú gazdagépen nagyon nehéz. Ezért jött létre a Kubernetes.
A tárolókép egy alkalmazást és annak függőségeit képviseli. Az alkalmazás, annak függőségei és az operációs rendszer fájlrendszer-képe a kép különböző részein, úgynevezett rétegekben található. A rétegek újra felhasználhatók különböző tartályokhoz. Például egy vállalat összes alkalmazása használhatja az Ubuntu alapréteget. Tárolók futtatásakor nincs szükség egyetlen alapréteg több példányának tárolására a gazdagépen. Ez lehetővé teszi a képtárolás és -szállítás optimalizálását.
Amikor egy alkalmazást egy tárolóból akarunk futtatni, a szükséges rétegek egymásra kerülnek, és egy átfedő fájlrendszer jön létre. A tetejére egy rögzítőréteg kerül, amelyet eltávolítanak, amikor a tartály megáll. Ez biztosítja, hogy amikor a tároló fut, az alkalmazás mindig ugyanazt a környezetet használja, amely nem módosítható. Ez garantálja a környezet reprodukálhatóságát különböző gazdagép operációs rendszereken. Legyen szó Ubunturól vagy CentOS-ről, a környezet mindig ugyanaz lesz. Ezenkívül a tárolót a Linux kernelbe épített mechanizmusok segítségével elkülönítik a gazdagéptől. A tárolóban lévő alkalmazások nem látják a fájlokat, a gazdagép és a szomszédos tárolók folyamatait. Az alkalmazásoknak a gazdagép operációs rendszertől való elkülönítése további biztonsági réteget biztosít.
Számos eszköz áll rendelkezésre a tárolók kezeléséhez egy gazdagépen. Közülük a legnépszerűbb a Docker. Lehetővé teszi a konténerek teljes életciklusának biztosítását. Ez azonban csak egy gazdagépen működik. Ha több gazdagépen kell konténereket kezelnie, a Docker pokollá teheti a mérnökök életét. Ezért jött létre a Kubernetes.
A Kubernetes iránti kereslet pontosan annak köszönhető, hogy a konténerek csoportjait több gazdagépen egyetlen entitásként lehet kezelni. A rendszer népszerűsége lehetőséget ad DevOps vagy fejlesztési műveletek készítésére, amelyekben a Kubernetes éppen ennek a DevOps-nak a folyamatait futtatja.
1. ábra. A Kubernetes működésének sematikus ábrázolása
Teljes automatizálás
A DevOps alapvetően a fejlesztési folyamat automatizálása. Nagyjából a fejlesztők írnak olyan kódot, amelyet feltöltenek a tárolóba. Ezután ez a kód automatikusan azonnal összegyűjthető egy tárolóba az összes könyvtárral, tesztelhető és „kiteríthető” a következő szakaszba - a szakaszolásba, majd azonnal a gyártásba.
A Kubernetes-szel együtt a DevOps lehetővé teszi ennek a folyamatnak a automatizálását, így az gyakorlatilag a fejlesztők részvétele nélkül megy végbe. Ennek köszönhetően a felépítés lényegesen gyorsabb, mivel a fejlesztőnek ezt nem kell megtennie a számítógépén - egyszerűen csak ír egy kódrészletet, betolja a kódot a repositoryba, ami után elindul a folyamat, amely magában foglalhatja a folyamatot. az építés, a tesztelés és a kihelyezés. És ez minden commitnál megtörténik, tehát a tesztelés folyamatosan történik.
Ugyanakkor a konténer használatával biztos lehet benne, hogy a program teljes környezete pontosan abban a formában kerül termelésbe, ahogyan tesztelték. Vagyis nem lesznek olyan problémák, mint „egyes verziók voltak a tesztben, mások gyártásban, de amikor telepítettük őket, minden leesett”. És amióta manapság a mikroszolgáltatási architektúra irányába mutató trend, amikor egy hatalmas alkalmazás helyett több száz kicsi van, ezek manuális adminisztrálásához hatalmas létszámra lesz szükség. Ezért használjuk a Kuberneteset.
Profik, profik, profik
Ha a Kubernetes, mint platform előnyeiről beszélünk, akkor jelentős előnyökkel jár a mikroszolgáltatási architektúra kezelése szempontjából.
- Több replika kezelése. A legfontosabb dolog a konténerek kezelése több gazdagépen. Ennél is fontosabb, hogy egyetlen entitásként kezelje a több alkalmazásreplikát a tárolókban. Ennek köszönhetően a mérnököknek nem kell aggódniuk minden egyes konténer miatt. Ha az egyik tároló összeomlik, a Kubernetes ezt látja, és újraindítja.
- Klaszter hálózat. A Kubernetesnek van egy úgynevezett fürthálózata is, saját címterével. Ennek köszönhetően minden podnak saját címe van. Az alpod egy fürt minimális szerkezeti egysége, amelyben a konténereket közvetlenül elindítják. Ezenkívül a Kubernetes olyan funkciókkal rendelkezik, amelyek egyesítik a terheléselosztót és a szolgáltatáskeresést. Ezzel megszabadulhat a kézi IP-címkezeléstől, és átruházhatja ezt a feladatot a Kubernetesre. Az automatikus állapotellenőrzések pedig segítik a problémák észlelését és a forgalom működő podokra való átirányítását.
- Konfiguráció-menedzsment. Nagyszámú alkalmazás kezelésekor nehézkessé válik az alkalmazáskonfiguráció kezelése. Erre a célra a Kubernetes speciális ConfigMap erőforrásokkal rendelkezik. Lehetővé teszik a konfigurációk központi tárolását, és az alkalmazások futtatása közben a podoknak való kitételt. Ez a mechanizmus lehetővé teszi, hogy garantáljuk a konfiguráció konzisztenciáját legalább tíz vagy száz alkalmazásreplikában.
- Állandó kötetek. A tárolók természetüknél fogva megváltoztathatatlanok, és amikor a tárolót leállítják, a fájlrendszerbe írt összes adat megsemmisül. Néhány alkalmazás azonban közvetlenül a lemezen tárolja az adatokat. A probléma megoldására a Kubernetes rendelkezik egy lemeztárkezelési funkcióval – Persistent Volumes. Ez a mechanizmus külső tárolót használ az adatokhoz, és állandó tárolót, blokkot vagy fájlt tud átvinni tárolókba. Ez a megoldás lehetővé teszi az adatok elkülönített tárolását a dolgozóktól, ami megmenti őket, ha ugyanazok a dolgozók meghibásodnak.
- Terhelés elosztó. Annak ellenére, hogy a Kubernetesben olyan absztrakt entitásokat kezelünk, mint a Deployment, StatefulSet stb., a konténerek végső soron normál virtuális gépeken vagy hardverkiszolgálókon futnak. Nem tökéletesek, és bármikor leeshetnek. A Kubernetes látni fogja ezt, és átirányítja a belső forgalmat más replikákra. De mit kezdjünk a kintről érkező forgalommal? Ha egyszerűen az egyik dolgozóhoz irányítja a forgalmat, és ha az összeomlik, a szolgáltatás elérhetetlenné válik. A probléma megoldására a Kubernetes olyan szolgáltatásokkal rendelkezik, mint a Load Balancer. Úgy tervezték, hogy automatikusan konfiguráljanak egy külső felhőkiegyenlítőt a fürt összes dolgozója számára. Ez a külső kiegyenlítő irányítja a külső forgalmat a dolgozókhoz, és maga figyeli állapotukat. Ha egy vagy több dolgozó elérhetetlenné válik, a rendszer átirányítja a forgalmat másokhoz. Ez lehetővé teszi, hogy magasan elérhető szolgáltatásokat hozzon létre a Kubernetes használatával.
A Kubernetes mikroszolgáltatási architektúrák futtatásakor működik a legjobban. Lehetséges a rendszert a klasszikus architektúrába átültetni, de értelmetlen. Ha egy alkalmazás nem futhat több replikán, akkor mi a különbség – Kubernetesben vagy sem?
Nyílt forráskódú Kubernetes
A nyílt forráskódú Kubernetes nagyszerű dolog: telepítettem és működik. Telepítheti saját hardverszervereire, saját infrastruktúrájára, telepítheti a mastereket és a dolgozókat, amelyeken minden alkalmazás futni fog. És ami a legfontosabb, mindez ingyenes. Vannak azonban árnyalatok.
- Az első az adminisztrátorok és mérnökök tudása és tapasztalata iránti igény, akik mindezt telepítik és támogatják. Mivel az ügyfél teljes cselekvési szabadságot kap a klaszterben, ezért ő maga felelős a klaszter teljesítményéért. És itt nagyon könnyű mindent összetörni.
- A második az integrációk hiánya. Ha népszerű virtualizációs platform nélkül futtatja a Kubernetes-et, akkor nem fogja élvezni a program minden előnyét. Ilyen például az állandó kötetek és a terheléselosztó szolgáltatások használata.
2. ábra k8s architektúra
Kubernetes az eladótól
A felhőszolgáltatóval való integráció két lehetőséget kínál:
- Először is, egy személy egyszerűen rákattinthat a „fürt létrehozása” gombra, és megkapja a már konfigurált és használatra kész klasztert.
- Másodszor, a szállító maga telepíti a fürtöt, és beállítja az integrációt a felhővel.
Hogyan történik ez itt. A klasztert elindító mérnök határozza meg, hogy hány dolgozóra van szüksége és milyen paraméterekkel (például 5 dolgozó, mindegyik 10 CPU-val, 16 GB RAM-mal és mondjuk 100 GB lemezzel). Ezt követően hozzáfér a már kialakított klaszterhez. Ebben az esetben a munkások, amelyeken a terhelés elindul, teljesen átkerülnek az ügyfélhez, de a teljes felügyeleti sík a szállító felelőssége marad (ha a szolgáltatást a menedzselt szolgáltatási modell szerint nyújtják).
Ennek a rendszernek azonban megvannak a maga hátrányai. Tekintettel arra, hogy a felügyeleti sík a szállítónál marad, a szállító nem ad teljes hozzáférést az ügyfélnek, és ez csökkenti a Kubernetes-szel való munka rugalmasságát. Néha előfordul, hogy egy kliens bizonyos funkciókat szeretne hozzáadni a Kuberneteshez, például LDAP-on keresztüli hitelesítést, de a felügyeleti sík konfigurációja ezt nem teszi lehetővé.
3. ábra: Példa egy felhőszolgáltató Kubernetes-fürtjére
Mit válasszunk: nyílt forráskódú vagy szállító
Tehát a Kubernetes nyílt forráskódú vagy gyártóspecifikus? Ha nyílt forráskódú Kubernetes-et vesszük, akkor a felhasználó azt csinál vele, amit akar. De nagy esély van arra, hogy lábon lőd magad. Az eladóval ez nehezebb, mert minden a cégre van átgondolva és beállítva. A nyílt forráskódú Kubernetes legnagyobb hátránya a szakemberigény. Az eladói opcióval a cég megszabadul ettől a fejfájástól, de el kell döntenie, hogy a szakembereit vagy az eladót fizeti.
Nos, az előnyök nyilvánvalóak, a hátrányok is ismertek. Egy dolog állandó: a Kubernetes sok problémát megold sok konténer kezelésének automatizálásával. És melyiket válassza, nyílt forráskódot vagy szállítót – mindenki maga dönt.
A cikket Dmitrij Krasznov, a #CloudMTS szolgáltató Containerum szolgáltatásának vezető építésze készítette
Forrás: will.com