A Kubernetes egy nagyszerű eszköz a Docker-konténerek futtatásához klaszterizált, termelési környezetben. Azonban vannak olyan feladatok, amelyeket a Kubernetes nem tud megoldani. Gyakori telepítések esetén teljesen automatizált Blue/Green telepítésre van szükség, hogy elkerüljük a leállásokat ebben a folyamatban, amely során a külső HTTP-kérések feldolgozása és az SSL kivezetése is szükséges. Ez integrációt igényel egy terheléselosztóval, mint például a ha-proxy. Egy másik feladat a Kubernetes klaszter félautomatikus méretezése felhőalapú környezetben, például a klaszter részleges csökkentése éjszaka.
Bár a Kubernetes nem rendelkezik ezekkel a funkciókkal közvetlenül "do-it-yourself" verzióban, API-t biztosít, amelyeket felhasználhatunk az ilyen feladatok megoldásához. A Kubernetes klaszter automatizált Blue/Green telepítésére és méretezésére szolgáló eszközöket a Cloud RTI projekt keretein belül fejlesztették ki, amely open-source alapokra épült.
Ebben a cikkben, a videó dekódolásában, arról van szó, hogyan állítsuk be a Kubernetes-t más nyílt forráskódú komponensekkel együtt, hogy egy kész termelési környezetet kapjunk, amely kimaradások nélkül veszi át a kódot a git commit-ból.
Miután hozzáférést kapott alkalmazásaihoz a külső világ felől, megkezdheti a teljes automatizálás beállítását, azaz eljutni arra a szintre, ahol a git commit végrehajtható, és biztos lehet benne, hogy ez a git commit átkerül a termelési környezetbe. Természetesen, amikor ezeket a lépéseket megvalósítjuk, a telepítés során szeretnénk elkerülni a leállásokat. Tehát minden automatizálás a Kubernetes-ben az API-val kezdődik.
A Kubernetes nem az az eszköz, amelyet produktívan használhatunk "do-it-yourself" módon. Természetesen használhatja a kubectl-t és hasonlókat, de az API az, ami a legérdekesebb és legértékesebb ebben a platformban. Az API-t funkciók készleteként használva gyakorlatilag hozzáférhet mindenhez, amit szeretne megtenni a Kubernetes-ben. Magában a kubectl is használja a REST API-t.
Ez egy REST API, így bármilyen nyelvet és eszközt használhat a működtetéséhez, de a felhasználói könyvtárak jelentősen megkönnyítik az életét. Csapatom írt két ilyen könyvtárat: egyet Java / OSGi-hoz és egyet Go-hoz. A másodikat nem használják gyakran, de mindenesetre ezek az hasznos eszközök a rendelkezésére állnak. Ezek részben licencelt open-source projektek. Számos ilyen könyvtár létezik különböző nyelvekhez, így választhatja a legmegfelelőbbet.
Tehát, mielőtt nekilátna a telepítés automatizálásának, győződjön meg arról, hogy ez a folyamat nem szenved el késéseket. Például csapatunk a legforgalmasabb időszakban, délben hajt végre termelési telepítést, amikor az emberek maximálisan használják az alkalmazásokat, ezért nagyon fontos, hogy elkerülje a késéseket ebben a folyamatban. Az állásidő elkerülése érdekében két módszert használnak: blue/green telepítés vagy folyamatos frissítés (rolling update). Az utóbbi esetén, ha öt példány fut az alkalmazásból, azokat egymás után frissítik. Ez a módszer remekül működik, de nem megfelelő, ha a telepítés folyamán egyszerre különböző verziójú alkalmazásokat futtat. Ilyen esetben frissítheti a felhasználói felületet, míg a háttér működik a régi verzióval, és az alkalmazás működése leáll. Ezért programozási szempontból eléggé nehéz ilyen körülmények között dolgozni.
Ez egyik oka annak, hogy mi a blue/green deployment-ot részesítjük előnyben az alkalmazásaink telepítésének automatizálásában. E módszer alkalmazása esetén biztosítania kell, hogy egy adott pillanatban csak egy verzió legyen aktív az alkalmazásból.
A blue/green deployment mechanizmusa a következőképpen működik. A forgalmat az alkalmazásaink számára a ha-proxy-n keresztül kapjuk, amely azonos verziójú futó példányokra irányítja azt.
Amikor új telepítést hajtunk végre, a Deployer-t használjuk, amely új komponenseket kap, és ezzel végrehajtja az új verzió telepítését. Az alkalmazás új verziójának telepítése azt jelenti, hogy „felállítunk” egy új replikasort, amelyeket külön, új podban indítunk el. Azonban a ha-proxy semmit sem tud róluk, és egyelőre nem irányít feléjük munkaterhelést.
Ezért először is szükséges ellenőrizni az új verziók működőképességét, hogy megbizonyosodjunk arról, hogy a replikák készen állnak a terhelés kezelésére.
Minden telepítési komponensnek támogatnia kell valamilyen formáját az egészségellenőrzésnek. Ez lehet egy nagyon egyszerű HTTP-kérések általi ellenőrzés, amikor 200-as státuszkódot kapunk, vagy egy mélyebb ellenőrzés, amely során az replikák kapcsolatát vizsgáljuk az adatbázissal és más szolgáltatásokkal, a dinamikus környezet kapcsolati stabilitását, valamint azt, hogy minden megfelelően indul-e el és működik-e. Ez a folyamat meglehetősen bonyolult lehet.
Miután a rendszer megbizonyosodott az összes frissített replika működőképességéről, a Deployer frissíti a konfigurációt és átadja a megfelelő confd-t, amely átállítja a ha-proxy-t.
Csak ezután irányítják a forgalmat az új verzióval rendelkező pod felé, míg a régi pod eltűnik.
Ez a mechanizmus nem Kubernetes sajátosság. A Blue/green deployment koncepciója már régóta létezik, és mindig is terheléselosztót használt. Először az összes forgalmat a régi alkalmazásverzióhoz irányítod, majd a frissítést követően teljesen átütemezed az új verzióra. Ezt az elvet nemcsak a Kubernetes használja.
Most bemutatom az új telepítési komponenst – a Deployer-t, amely egészségellenőrzést végez, újrakonfigurálja a proxyt és így tovább. Ez egy koncepció, amely nem kapcsolódik a külső világhoz, és létezik a Kubernetes-en belül. Megmutatom, hogyan hozhatod létre a saját Deployer koncepciódat open-source eszközök segítségével.
Tehát az első dolog, amit a Deployer tesz, hogy létrehoz egy replikációs kontroller (RC) alkalmazást a Kubernetes API használatával. Ez az API létrehozza a podokat és szolgáltatásokat a telepítés további lépéseihez, vagyis teljesen új klasztert hoz létre az alkalmazásaink számára. Amint az RC megbizonyosodik arról, hogy a replikák elindultak, elvégzi a működőképességi ellenőrzést (Health check). Ehhez a Deployer a GET /health parancsot használja. Ez elindítja a megfelelő ellenőrző komponenseket, és ellenőrzi az összes elemet, amely biztosítja a klaszter működését.
Miután minden pod bejelentette a "szükséges egészségügyi állapotát", a Deployer létrehoz egy új konfigurációs elemet – egy elosztott tárolót (etcd), amely a Kubernetes belső működéséhez szükséges, beleértve a terheléselosztó konfigurációjának tárolását is. Az adatokat az etcd-be írjuk, és egy kis eszköz, a confd figyeli az etcd-t az új adatok megjelenésére.
Ha észlelte a kezdeti konfiguráció bármilyen változását, akkor új beállítási fájlt generál, és továbbítja azt a ha-proxy-nak. Ebben az esetben a ha-proxy újraindul kapcsolatok megszakítása nélkül, és a terhelést az új szolgáltatásokra irányítja, amelyek az alkalmazásaink új verzióját biztosítják.
Ahogy látható, a sok komponens ellenére itt nincs semmi bonyolult. Csak annyira kell figyelni az API-ra és az etcd-re. Szeretném bemutatni az open-source deployert, amit mi magunk is használunk – ez az Amdatu Kubernetes Deployer.
Ez egy Kubernetes telepítések kezelésére szolgáló eszköz, amely a következő funkciókkal rendelkezik:
- Kék/Zöld telepítés;
- Külső terheléselosztó beállítása;
- Telepítési leírók kezelése;
- Valódi telepítés kezelése;
- Működőképességi ellenőrzések végrehajtása telepítés közben;
- Környezeti változók beillesztése a podokba.
Ez a Deployer a Kubernetes API tetejére épült, és REST API-t biztosít a leírók és telepítések kezelésére, valamint Websocket API-t a telepítési folyamat során folyamatos naplókhoz.
A terheléselosztó konfigurációs adatait az etcd-be helyezi, így nem szükséges a "do-it-yourself" ha-proxy használata, könnyedén használhatja a saját terheléselosztó konfigurációs fájlját. Az Amdatu Deployer Go nyelven íródott, akárcsak maga a Kubernetes, és Apache licenc alatt áll.
A telepítőverzió használata előtt a következő telepítési leírást használtam, amelyben a számomra szükséges paraméterek vannak megadva.
A kód egyik fontos paramétere a 'useHealthCheck' zászló engedélyezése. Meg kell adni, hogy a telepítés során végezzen egészségellenőrzést. Ez a paraméter kikapcsolható, ha olyan harmadik fél által készített konténereket használunk a telepítés során, amelyeket nem szükséges ellenőrizni. E leírásban szerepel a replikák száma és a ha-proxy által szükséges frontend URL is. A végén szerepel a 'podspec' pod specifikációs zászló, amely a Kuberneteshez fordul a portoktól, képektől, stb. való konfigurációs információkért. Ez egy viszonylag egyszerű JSON-formátumú leírás.
Egy másik eszköz, amely része az open-source Amdatu projektnek, a Deploymentctl. Ez egy felhasználói felület UI-t biztosít a telepítés konfigurálásához, tárolja a telepítési előzményeket, és webhooks-t tartalmaz harmadik fél felhasználók és fejlesztők visszahívásaira. Nem muszáj használnia az UI-t, mivel maga az Amdatu Deployer REST API, de ez a felület sokkal megkönnyítheti a telepítést API igénybevétel nélkül. A Deploymentctl OSGi/Vertx és Angular 2 felhasználásával készült.
Most bemutatom a fent említetteket a képernyőn, előre rögzített felvétel segítségével, így nem kell várnia. Egy egyszerű Go alkalmazást fogunk telepíteni. Ne aggódjon, ha eddig nem találkozott a Go-val, ez egy nagyon egyszerű alkalmazás, így mindent könnyen érthetőnek kell lennie.
Itt egy HTTP szervert hozunk létre, amely csak a /health-ra válaszol, így ez az alkalmazás csak az egészségellenőrzést ellenőrzi, és semmi mást. Ha az ellenőrzés sikeres, akkor a lent látható JSON-struktúra aktiválódik. Ez tartalmazza a telepítő által telepítendő alkalmazás verzióját, a fájl tetején látható üzenetet, és egy logikai típusú boolean értéket – működik-e az alkalmazásunk vagy sem.
Az utolsó sorban kicsit ügyeskedtem, mert a fájl elejére egy rögzített boolean értéket tettem, amely később segít nekem abban, hogy még egy "nem egészséges" alkalmazást is telepíthessek. Később ezt is átbeszéljük.
Tehát kezdjük. Először ellenőrizzük, hogy vannak-e futó podok a ~ kubectl get pods paranccsal, és a frontend URL hiányában biztosak lehetünk benne, hogy jelenleg nincsenek telepítések.
A következő képernyőn látja az általam említett Deploymentctl felületet, ahol a telepítési paramétereket állítjuk be: névtér, alkalmazás neve, telepítési verzió, példányok száma, frontend URL, konténer neve, kép, erőforrás korlátok, a health check port száma stb. Az erőforrás korlátok nagyon fontosak, mivel lehetővé teszik a maximálisan elérhető „hardver” kihasználását. Itt megtekintheti a telepítési naplót is.
Ha most megismételjük a ~ kubectl get pods parancsot, látható, hogy a rendszer „megáll” 20 másodpercre, amely idő alatt a ha-proxy újrakonfigurálása történik. Ezt követően a pod elindul, és a replikánk a telepítési naplóban megjelenik.
Kivágtam a videóból a 20 másodperces várakozást, és most látja a képernyőn, hogy az alkalmazás első verziója telepítve van. Mindezt pusztán a UI segítségével valósítottuk meg.
Most próbáljuk ki a második verziót. Ehhez módosítom az alkalmazás üzenetét a „Hello, Kubernetes!”-ről „Hello, Deployer!”-re, a rendszer létrehozza ezt a képet és elhelyezi a Docker registry-ben, majd egyszerűen újra rákattintunk a „Deploy” gombra a Deploymentctl ablakban. Ezzel automatikusan elindul a telepítési napló, akárcsak az első verzió telepítésekor.
A ~ kubectl get pods parancs mutatja, hogy jelenleg 2 verzió fut az alkalmazásból, azonban a frontend azt mutatja, hogy még mindig az 1-es verzió működik.
A terheléselosztó vár, amíg a health check elvégzésre kerül, majd átirányítja a forgalmat az új verzióra. 20 másodperc múlva átváltunk a curl-re, és látjuk, hogy most a 2-es verzió van telepítve, míg az első már törölve lett.
Ez egy „egészséges” - healthy - alkalmazás telepítése volt. Nézzük meg, mi történik, ha az új verzióhoz a Healthy paraméter értékét true-ról false-ra változtatom, tehát megpróbálok egy unhealthy alkalmazást telepíteni, amely nem teljesítette a működési tesztet. Ez akkor történhet meg, ha a fejlesztés során az alkalmazásban valamilyen konfigurációs hiba történt, és ebben a formában került a termelésbe.
Ahogy látja, a telepítés mind a fent említett lépéseket teljesíti, és a ~ kubectl get pods mutatja, hogy mindkét pod fut. De az előző telepítéstől eltérően a napló időtúllépési állapotot jelez. Tehát mivel az egészségellenőrzés nem sikerült, az új verziót nem lehetett telepíteni. Ennek eredményeként látja, hogy a rendszer visszatért a régi verzió használatára, míg az új verziót egyszerűen eltávolították.
Ami jó ebben, hogy még ha rengeteg egyidejű kérés érkezik is az alkalmazásba, a felhasználók nem is észlelik a leállást a telepítési eljárás alatt. Ha ezt az alkalmazást a Gatling keretrendszer segítségével teszteljük, amely a lehető legnagyobb számú kérést küldi el, akkor egyetlen kérés sem fog elutasításra kerülni. Ez azt jelenti, hogy a felhasználók még az új verziók valós idejű frissítését sem vehetik észre. Ha a frissítés nem sikerül, a rendszer a régi verzión folytatja a működést, ha sikerül – a felhasználók az új verzióra váltanak.
Csak egy dolog okozhat kudarcot – ha az egészségellenőrzés sikeres, de az alkalmazás összeomlik, amint terhelést kap, a kollapszus csak a telepítés befejezése után következik be. Ebben az esetben manuálisan vissza kell térnie a régi verzióra. Tehát megvizsgáltuk, hogyan használhatja a Kubernetest a számára kialakított nyílt forráskódú eszközökkel. A telepítési eljárás sokkal zökkenőmentesebbé válik, ha ezeket az eszközöket beépíti a Build/Deploy pipeline-okba. A telepítés elindításához használhatja a felhasználói felületet, vagy teljesen automatizálhatja a folyamatot, például a commit to master alkalmazásával.
Építési szerverünk, a Build Server létrehozza a Docker képet, feltölti a Docker Hub-ra vagy bármely más használt registry-be. A Docker Hub webhookot támogat, így a Deployer-en keresztül távoli telepítést indíthatunk az előbb bemutatott módon. Így az alkalmazás telepítése teljesen automatizálható a potenciális produkciós környezetbe.
Folytassuk a következő téma, a Kubernetes klaszter skálázásának áttekintésével. Megjegyzem, hogy a kubectl parancs a skálázás parancsa. Ezen keresztül könnyedén növelhetjük a replikák számát a meglévő klaszterünkben. A gyakorlatban azonban általában a podok számának növelése helyett a node-ok számát szeretnénk növelni.
Ez azt jelenti, hogy munkaidőben szükség lehet a növelésre, míg éjszaka, az Amazon költségeinek csökkentése érdekében, az alkalmazás futó példányainak számát csökkenteni kell. Ez nem jelenti azt, hogy elegendő csupán a podok számát skálázni, mert még ha egy node üresen áll, akkor is fizetnünk kell érte az Amazonnak. Tehát a podok skálázása mellett a használt gépek számát is skálázni kell.
Ez problémákat okozhat, mert függetlenül attól, hogy az Amazont vagy egy másik felhőszolgáltatót használunk, a Kubernetes nem tud a használt gépek számáról. Nincs eszköz, amely lehetővé tenné a rendszer skálázását a node-ok szintjén.
Tehát gondoskodnunk kell a node-okról és a podokról is. Az AWS API segítségével könnyen skálázhatjuk új node-ok indítását, valamint a Kubernetes munkacsoport főcsoportjának beállítását a munkáscsomópontok számának konfigurálására. A cloud-init vagy hasonló szkript is használható a node-ok regisztrálására a Kubernetes klaszterében.
Az új gép elindul a Scaling group-ban, csomópontként kezeli magát, bejegyződik a mesterek nyilvántartásába és elkezdi a működést. Ezt követően növelhető a replikák száma, hogy kihasználják a kialakult csomópontokat. A méretezés csökkentése nagyobb erőfeszítést igényel, mivel biztosítani kell, hogy ez a lépés ne vezessen a már működő alkalmazások megszüntetéséhez a "felesleges" gépek kikapcsolása után. Ennek a forgatókönyvnek a megelőzéséhez a csomópontokat "unschedulable" státuszra kell állítani. Ez azt jelenti, hogy az alapértelmezett ütemező a DaemonSet podok ütemezésekor figyelmen kívül hagyja ezeket a csomópontokat. Az ütemező nem töröl semmit ezekről a szerverekről, de új konténereket sem indít el ott. A következő lépés a csomópont kiürítése, vagyis a működő podok átkonfigurálása egy másik gépre, vagy más csomópontokra, amelyek elegendő kapacitással rendelkeznek ehhez. Miután megbizonyosodtunk arról, hogy ezeken a csomópontokon többé nincs konténer, eltávolíthatjuk őket a Kubernetes-ből. Ezt követően már csak nem léteznek a Kubernetes számára. A következőkben az AWS API-t kell használni a felesleges csomópontok, vagy gépek kikapcsolásához.
Használhatja az Amdatu Scalerd-et – egy másik open-source eszközt a skálázáshoz, hasonlóan az AWS API-hoz. CLI-t biztosít a csomópontok hozzáadásához vagy eltávolításához a klaszterben. Érdekes jellemzője, hogy lehetőséget ad az ütemező konfigurálására a következő json-fájl segítségével.
A bemutatott kód felére csökkenti a klaszter kapacitását a nappali időszakban. Be van állítva mind a meglévő replikák száma, mind az Amazon klaszter kívánt kapacitása. Ennek az ütemezőnek a használata automatikusan csökkenti a csomópontok számát éjszaka, és reggel növeli azokat, lehetővé téve a költségek megtakarítását egy ilyen felhőszolgáltatás, mint az Amazon csomópontjainak használatában. Ez a funkció nem beépített a Kubernetes-be, de a Scalerd használata lehetővé teszi a platform tetszés szerinti skálázását.
Szeretném felhívni a figyelmet arra, hogy sokan azt mondják nekem: „Mindez jól hangzik, de mi a helyzet az én adatbázisommal, amely rendszerint statikus állapotban van?” Hogyan lehetne valami ilyesmit elindítani egy dinamikus környezetben, mint a Kubernetes? Véleményem szerint ezt nem szabadna megpróbálni, nem szabadna adatbázisokat futtatni a Kubernetes-ben. Technikailag lehetséges, és az interneten vannak útmutatók erre vonatkozóan, de ez komolyan megnehezíti az életét.
Igen, a Kubernetes-ben létezik a tartós tárolók fogalma, és megpróbálhatja futtatni az olyan adatbázisokat, mint a Mongo vagy a MySQL, de ez elég munkaigényes feladat. Ennek az az oka, hogy az adatbázisok nem támogatják teljes mértékben a dinamikus környezettel való interakciót. A legtöbb adatbázis jelentős beállítást igényel, beleértve a klaszter kézi konfigurálását, és nem kedvelik az automatikus skálázást és hasonló dolgokat.
Ezért ne bonyolítsa az életét azzal, hogy adatbázist próbál futtatni Kubernetes-ben. Szervezze meg a működésüket a hagyományos módon, a megszokott szolgáltatások használatával, és egyszerűen engedje, hogy a Kubernetes hozzáférjen hozzájuk.
A téma végén szeretném bemutatni a Kubernetes alapú Cloud RTI platformot, amelyen a csapatom dolgozik. Ez központosított naplózást, alkalmazások és klaszterek monitorozását biztosít, és számos más hasznos funkcióval rendelkezik, amelyeket hasznosnak találhat. Különböző open-source eszközöket használ, mint például a Grafana a monitorozás megjelenítésére.
Felmerült a kérdés, miért használjunk ha-proxy terheléselosztót a Kubernetes-szel. Jó kérdés, mivel jelenleg két szintű terheléselosztás létezik. A Kubernetes szolgáltatások még mindig virtuális IP-címeken alapulnak. Nem használhatók külső gépek portjaihoz, mivel ha az Amazon túlterheli felhőszerverét, a cím megváltozik. Ezért helyezzük a ha-proxy-t a szolgáltatások elé, hogy statikusabb struktúrát hozzunk létre a forgalom folyamatos interakciójához a Kubernetes-szel.
Egy másik jó kérdés – hogyan lehet gondoskodni az adatbázis-séma módosításáról a blue/green telepítés során? A helyzet az, hogy függetlenül attól, hogy Kubernetes-t használ, az adatbázis-séma módosítása bonyolult feladat. Gondoskodnia kell a régi és az új séma kompatibilitásáról, majd frissítheti az adatbázist, és ezután az alkalmazásokat. Végezheti el az adatbázis „forró csere” (hot swapping) folyamatát, majd frissítheti az alkalmazásokat. Ismerek embereket, akik teljesen új adatbázis-kiszerelőt állítottak fel új sémával, ami opció, ha van schemeless típusú adatbázisuk, mint például a Mongo, de mindenesetre nem könnyű feladat. Ha nincs több kérdés, köszönöm a figyelmet!
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
