Probléma az állapotalapú alkalmazásokkal a Kubernetesben
Az alkalmazások és szolgáltatások konfigurálása, indítása és további méretezése egyszerű, ha állapotmentesnek minősített esetekről van szó, pl. adatok mentése nélkül. Kényelmes az ilyen szolgáltatásokat a Kubernetesben futtatni, annak szabványos API-jait használva, mert minden „dobozból” történik: szabványos konfigurációk szerint, különösebb részletek vagy varázslat nélkül.
Egyszerűen fogalmazva, a PHP/Ruby/Python háttérrendszer további öt példányának elindításához egy konténerfürtben mindössze ötször kell beállítania egy új szervert, és át kell másolnia a forrásokat. Mivel a forráskód és az init szkript is benne van a képben, az állapot nélküli alkalmazások méretezése teljesen elemivé válik. Ahogy a konténerek és a mikroszolgáltatás-architektúra rajongói jól tudják, a nehézség ott kezdődik állapotjelző alkalmazások, azaz adatperzisztenciával, például adatbázisokkal és gyorsítótárakkal (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ez vonatkozik mind azokra a szoftverekre, amelyek önállóan valósítanak meg kvórumfürtöt (például Percona XtraDB és Cassandra), mind pedig olyan szoftverekre, amelyek külön felügyeleti segédprogramokat igényelnek (például Redis, MySQL, PostgreSQL...).
Nehézségek merülnek fel, mert a forráskód és a szolgáltatás elindítása már nem elegendő - további lépéseket kell végrehajtania. Legalább másolja át az adatokat és/vagy csatlakozzon a fürthöz. Pontosabban, ezek a szolgáltatások megkövetelik annak megértését, hogyan lehet megfelelően méretezni, frissíteni és újrakonfigurálni őket adatvesztés vagy átmeneti elérhetetlenség nélkül. Ezen igények figyelembe vételét „operatív tudásnak” nevezzük.
CoreOS üzemeltetők
A működési ismeretek "programozása" érdekében tavaly év végén a CoreOS projektet benyújtott „egy új szoftverosztály” a Kubernetes platformhoz – Operátorok (az angol „operation”, azaz „operation” szóból).
A Kubernetes alapvető képességeit használó és bővítő üzemeltetők (pl. StatefulSets, lásd az alábbi különbséget) lehetővé teszik a DevOps-szakemberek számára, hogy működési ismereteket adhassanak az alkalmazás kódjához.
Üzemeltető célja — biztosítson a felhasználónak egy API-t, amely lehetővé teszi több állapottartó alkalmazás entitás kezelését egy Kubernetes-fürtben, anélkül, hogy átgondolná, mi van a burkolat alatt (milyen adatok és mit kell tenni velük, milyen parancsokat kell még végrehajtani a fürt karbantartásához ). Valójában az Operator célja, hogy a lehető legnagyobb mértékben leegyszerűsítse a klaszteren belüli alkalmazással végzett munkát, automatizálva a korábban manuálisan megoldandó üzemeltetési feladatok végrehajtását.
Hogyan működnek az üzemeltetők
ReplicaSets A Kubernetes lehetővé teszi a futó podok kívánt számának megadását, a vezérlők pedig biztosítják számuk fenntartását (a podok létrehozásával és törlésével). Az üzemeltető hasonló módon működik, és olyan működési ismereteket ad hozzá egy szabványos Kubernetes-erőforráshoz és vezérlőhöz, amely lehetővé teszi további műveletek végrehajtását a szükséges számú alkalmazási entitás támogatása érdekében.
Miben különbözik ez attól StatefulSets, amelyet olyan alkalmazásokhoz terveztek, amelyek megkövetelik, hogy a fürt állapotalapú erőforrásokat biztosítson számukra, például adattárolást vagy statikus IP-címeket? Az ilyen alkalmazásokhoz az üzemeltetők használhatják StatefulSets (helyett ReplicaSets) alapként, felajánlásként további automatizálás: összeomlás esetén hajtsa végre a szükséges műveleteket, készítsen biztonsági másolatot, frissítse a konfigurációt stb.
Így hogy működik ez az egész? Az operátor egy menedzser démon, amely:
előfizet a Kubernetes esemény API-jára;
adatokat kap tőle a rendszerről (annak ReplicaSets, Pods, Szolgáltatások stb.);
ról kap adatokat Harmadik fél forrásai (lásd alább a példákat);
reagál a megjelenésre/változásra Harmadik fél forrásai (például a méret megváltoztatásához, a verzió módosításához stb.);
reagál a rendszer állapotában bekövetkezett változásokra (kb ReplicaSets, Pods, Szolgáltatások stb.);
legfontosabb:
felhívja a Kubernetes API-t, hogy hozzon létre mindent, amire szüksége van (megint a sajátját ReplicaSets, Pods, Szolgáltatások...),
némi varázslatot hajt végre (az egyszerűsítés kedvéért gondolhatjuk úgy, hogy az operátor maga is bemegy a pod-okba, és parancsokat hív meg például egy fürthöz való csatlakozáshoz vagy az adatformátum frissítéséhez egy verzió frissítésekor).
Valójában, amint az a képen látható, egy külön alkalmazás egyszerűen hozzáadódik a Kuberneteshez (egy szokásos bevetés с ReplicaSet), amelyet Operátornak neveznek. Egy közönséges hüvelyben él (általában csak egyben), és általában csak ezért felelős névtér. Ez az operátor alkalmazás implementálja az API-ját - bár nem közvetlenül, hanem keresztül Harmadik fél forrásai Kubernetesben.
Így, miután létrehoztuk névtér Üzemeltető, hozzátehetjük Harmadik fél forrásai.
A CoreOS megfogalmazta azokat a fő mintákat, amelyeket a mérnökök az üzemeltetőkön dolgoztak. Annak ellenére, hogy minden Operátor egyéni (egy adott alkalmazáshoz, annak sajátosságaival és igényeivel készült), létrehozásuknak egyfajta keretrendszeren kell alapulnia, amely a következő követelményeket támasztja:
A telepítést egyen keresztül kell elvégezni bevetés: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - és nem igényel további műveleteket.
Operátor telepítésekor a Kubernetesben új, harmadik féltől származó típust kell létrehozni (Harmadik fél erőforrás). Alkalmazáspéldányok (fürtpéldányok) indításához és további kezeléséhez (verziók frissítése, átméretezés stb.) a felhasználó ezt a típust használja.
Amikor csak lehetséges, használd a Kubernetesbe épített primitíveket, mint pl Szolgáltatások и ReplicaSetsjól tesztelt és érthető kódot használni.
Az operátorok visszafelé kompatibilitását és a felhasználók által létrehozott erőforrások régebbi verzióinak támogatását igényli.
Ha az Operátort eltávolítják, magának az alkalmazásnak továbbra is változtatások nélkül kell működnie.
A felhasználóknak képesnek kell lenniük meghatározni a kívánt alkalmazásverziót, és meg kell szervezni az alkalmazásverzió frissítéseit. A szoftverfrissítések hiánya a működési és biztonsági problémák gyakori forrása, ezért az üzemeltetőknek segíteniük kell a felhasználókat ebben a kérdésben.
Az operátorokat olyan eszközzel kell tesztelni, mint a Chaos Monkey, amely azonosítja a podokban, konfigurációkban és a hálózatban előforduló lehetséges hibákat.
etcd Operátor
Üzemeltetői megvalósítási példa - etcd kezelő, előkészített e koncepció kihirdetésének napján. Az etcd fürt konfigurációja összetett lehet a kvórum fenntartása, a fürttagság újrakonfigurálása, biztonsági mentések létrehozása stb. miatt. Például egy etcd-fürt kézi méretezése azt jelenti, hogy létre kell hoznia egy DNS-nevet egy új fürttag számára, új etcd entitást kell indítania, és figyelmeztetnie kell a fürtöt az új tagról (etcdctl tag hozzáadása). Az Operator esetében a felhasználónak csak a klaszter méretét kell módosítania - minden más automatikusan megtörténik.
És mivel az etcd-t is CoreOS-ben hozták létre, teljesen logikus volt, hogy az Operator jelenik meg először. Hogyan dolgozik? Kezelői logika stb három összetevő határozza meg:
Figyeld meg. Az operátor a Kubernetes API segítségével figyeli a fürt állapotát.
Elemzés. Megkeresi az aktuális és a kívánt (a felhasználói konfiguráció által meghatározott) állapot közötti különbségeket.
Akció. Megoldja az észlelt eltéréseket az etcd és/vagy Kubernetes szolgáltatás API-k használatával.
Ennek a logikának a megvalósítására az Operatorban funkciókat készítettek elő Létrehozása/megsemmisítése (etcd fürttagok létrehozása és törlése) és Átméretezése (a klasztertagok számának változása). Működésének helyességét a Netflix Chaos Monkey hasonlatosságára létrehozott segédprogram segítségével ellenőrizték, azaz. stbd hüvelyek véletlenszerű megölése.
Az etcd teljes körű működéséhez az Operator további szolgáltatásokat biztosít: mentés (automatikus és a felhasználók számára láthatatlan biztonsági másolatok készítése - a konfigurációban elegendő meghatározni, hogy milyen gyakran és mennyit kell tárolni -, majd az adatok visszaállítása azokból) és frissítés (az etcd telepítések frissítése leállás nélkül).
Hogyan néz ki az operátorral való munka?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Az etcd Operator jelenlegi állapota béta verzió, amelyhez Kubernetes 1.5.3+ és etcd 3.0+ szükséges. A forráskód és a dokumentáció (beleértve a használati utasítást is) a címen érhető el GitHub.
Létrejött egy másik példa megvalósítás a CoreOS-ből - Prometheus operátor, de még mindig alfa verzióban van (nem minden tervezett funkció valósult meg).
Állapot és kilátások
5 hónap telt el a Kubernetes Operators bejelentése óta. Még mindig csak két megvalósítás érhető el a hivatalos CoreOS tárolóban (az etcd és a Prometheus számára). Mindkettő még nem érte el a stabil verzióját, de az elkövetéseket naponta megfigyelik.
A fejlesztők olyan jövőt képzelnek el, amelyben a felhasználók a Postgres Operatorokat, a Cassandra Operatorokat vagy a Redis Operatorokat telepítik Kubernetes-fürtjeikre, és olyan egyszerűen dolgozhatnak ezen alkalmazások méretezhető entitásaival, mint ma az állapot nélküli webalkalmazások replikáinak telepítése. Első Operátorok harmadik féltől származó fejlesztőktől tényleg elkezdett megjelenni:
A legnagyobb európai ingyenes szoftverkonferencián, a FOSDEM-en, amelyre 2017 februárjában került sor Brüsszelben, Josh Wood, a CoreOS munkatársa bejelentette, hogy Operators jelentés (a linken elérhető videó!), aminek hozzá kell járulnia a koncepció népszerűségének növekedéséhez a szélesebb Open Source közösségben.
PS Köszönjük érdeklődését a cikk iránt! Iratkozzon fel hubunkra, hogy ne maradjunk le a DevOps és a GNU/Linux rendszeradminisztrációról szóló új anyagokról és receptekről – rendszeresen közzétesszük!