Kocka a kockán, metaklaszterek, méhsejt, erőforrás-elosztás

Rizs. 1. Kubernetes ökoszisztéma az Alibaba Cloudon

2015 óta az Alibaba Cloud Container Service for Kubernetes (ACK) az egyik leggyorsabban növekvő felhőszolgáltatás az Alibaba Cloudban. Számos ügyfelet szolgál ki, és támogatja az Alibaba belső infrastruktúráját és a vállalat egyéb felhőszolgáltatásait is.

A világszínvonalú felhőszolgáltatók hasonló konténerszolgáltatásaihoz hasonlóan nálunk is a megbízhatóság és a rendelkezésre állás a legfontosabb. Ezért egy méretezhető és globálisan elérhető platformot hoztak létre több tízezer Kubernetes-fürt számára.

Ebben a cikkben megosztjuk tapasztalatainkat nagyszámú Kubernetes-fürt felhőinfrastruktúrán történő kezelésével, valamint az alapul szolgáló platform architektúrájával kapcsolatban.

Belépés

A Kubernetes de facto szabványává vált a felhőben található különféle munkaterhelések számára. ábrán látható módon. A fenti 1. ábra szerint egyre több Alibaba Cloud alkalmazás fut Kubernetes-fürtökön: állapottartó és állapot nélküli alkalmazások, valamint alkalmazáskezelők. A Kubernetes menedzsment mindig is érdekes és komoly vitatéma volt az infrastruktúrát építő és karbantartó mérnökök számára. Amikor olyan felhőszolgáltatókról van szó, mint az Alibaba Cloud, a méretezés kérdése kerül előtérbe. Hogyan lehet ilyen léptékű Kubernetes-fürtöket kezelni? Már foglalkoztunk a hatalmas, 10 000 csomópontból álló Kubernetes-fürtök kezelésének bevált módszereivel. Természetesen ez egy érdekes méretezési probléma. De van egy másik skála: a mennyiség maguk a klaszterek.

Sok ACK felhasználóval megvitattuk ezt a témát. Legtöbbjük több tucat, ha nem több száz kis vagy közepes méretű Kubernetes-fürt futtatását választja. Ennek jó okai vannak: a potenciális károk korlátozása, a fürtök szétválasztása a különböző csapatok számára, virtuális fürtök létrehozása tesztelésre. Ha az ACK globális közönséget kíván kiszolgálni ezzel a használati modellel, akkor nagyszámú klasztert kell megbízhatóan és hatékonyan kezelnie több mint 20 régióban.

Rizs. 2. Nagyszámú Kubernetes klaszter kezelésének problémái

Melyek a klaszterek kezelésének fő kihívásai ebben a léptékben? Amint az ábrán látható, négy problémával kell foglalkozni:

• Heterogenitás

Az ACK-nek különféle típusú fürtöket kell támogatnia, beleértve a szabványos, kiszolgáló nélküli, Edge-t, Windows-t és még sok mást. A különböző fürtök különböző opciókat, összetevőket és hosting modelleket igényelnek. Egyes ügyfeleknek segítségre van szükségük az egyedi esetekhez való testreszabáshoz.

• Különféle méretű klaszterek

A klaszterek mérete változó: néhány csomóponttól több hüvelyes csomópontig több tízezer csomópontig több ezer hüvely. Az erőforrásigények is nagyon eltérőek. A nem megfelelő erőforrás-elosztás befolyásolhatja a teljesítményt, vagy akár meghibásodást is okozhat.

• Különböző verziók

A Kubernetes nagyon gyorsan fejlődik. Az új verziók néhány havonta jelennek meg. Az ügyfelek mindig szívesen kipróbálnak új funkciókat. Tehát a tesztterhelést a Kubernetes új verzióira, a gyártási terhelést pedig a stabilokra akarják helyezni. Ennek a követelménynek a teljesítése érdekében az ACK-nak folyamatosan a Kubernetes új verzióit kell szállítania az ügyfeleknek, miközben a stabil verziókat fenntartja.

• Biztonsági megfelelőség

A klaszterek különböző régiókban vannak elosztva. Ennek megfelelően különféle biztonsági követelményeknek és hatósági előírásoknak kell megfelelniük. Például egy európai klaszternek GDPR-kompatibilisnek kell lennie, míg a kínai pénzügyi felhőnek további védelmi rétegekkel kell rendelkeznie. Ezek a követelmények kötelezőek, és elfogadhatatlan figyelmen kívül hagyni őket, mivel ez óriási kockázatokat jelent a felhőplatform ügyfelei számára.

Az ACK platformot a legtöbb fenti probléma megoldására tervezték. Jelenleg több mint 10 ezer Kubernetes klasztert kezel megbízhatóan és stabilan szerte a világon. Nézzük meg, hogyan sikerült ezt elérni, többek között számos kulcsfontosságú tervezési/építészeti elv alapján.

Tervezés

Kocka-kockára és méhsejt

A központosított hierarchiától eltérően a cellaalapú architektúrát jellemzően egy platform egyetlen adatközponton túli méretezésére vagy a katasztrófa utáni helyreállítás hatókörének kiterjesztésére használják.

Az Alibaba Cloud minden régiója több zónából (AZ) áll, és általában egy adott adatközpontnak felel meg. Egy nagy régióban (pl. Huangzhou) gyakran több ezer Kubernetes-kliens-fürt fut ACK-t.

Az ACK ezeket a Kubernetes-fürtöket maga a Kubernetes használatával kezeli, ami azt jelenti, hogy fut egy Kubernetes-metafürt az ügyfél-kubernetes-fürtök kezelésére. Ezt az architektúrát „kube-on-kube”-nak (KoK) is nevezik. A KoK architektúra leegyszerűsíti az ügyfélfürtök kezelését, mivel a fürttelepítés egyszerű és determinisztikus. Ennél is fontosabb, hogy újra felhasználhatjuk a natív Kubernetes-szolgáltatásokat. Például API-kiszolgálók kezelése telepítésen keresztül, az etcd operátor használata több etcd kezeléséhez. Az ilyen rekurzió mindig különleges örömet okoz.

Az ügyfelek számától függően egy régióban több Kubernetes metacluster kerül telepítésre. Ezeket a metaklasztereket sejteknek nevezzük. A teljes zóna meghibásodása elleni védelem érdekében az ACK egyetlen régióban támogatja a több aktív telepítést: a metafürt a Kubernetes kliensfürt főkomponenseit több zónára osztja el, és egyidejűleg, azaz több aktív módban futtatja. A mester megbízhatóságának és hatékonyságának biztosítása érdekében az ACK optimalizálja az összetevők elhelyezését, és biztosítja, hogy az API szerver és az etcd közel legyenek egymáshoz.

Ez a modell lehetővé teszi a Kubernetes hatékony, rugalmas és megbízható kezelését.

Metacluster erőforrás tervezés

Mint már említettük, az egyes régiókban lévő metaklaszterek száma az ügyfelek számától függ. De mikor kell új metaklasztert hozzáadni? Ez egy tipikus erőforrás-tervezési probléma. Általában akkor szokás újat létrehozni, amikor a meglévő metaklaszterek minden erőforrásukat kimerítették.

Vegyük például a hálózati erőforrásokat. A KoK-architektúrában az ügyfélfürtökből származó Kubernetes-összetevők pod-ként vannak üzembe helyezve egy metafürtben. Használjuk Terway (3. ábra) egy nagy teljesítményű bővítmény, amelyet az Alibaba Cloud fejlesztett ki a konténerhálózat kezeléséhez. Biztonsági szabályzatok gazdag készletét kínálja, és lehetővé teszi az ügyfelek virtuális privát felhőihez (VPC) való csatlakozást az Alibaba Cloud Elastic Networking Interface (ENI) segítségével. Ahhoz, hogy a hálózati erőforrásokat hatékonyan eloszthassuk a csomópontok, pod-ok és szolgáltatások között egy metafürtben, gondosan figyelnünk kell használatukat a virtuális privát felhők metafürtjében. Amikor a hálózati erőforrások véget érnek, egy új cella jön létre.

Az egyes metaklaszterekben lévő kliens klaszterek optimális számának meghatározásához figyelembe vesszük a költségeinket, a sűrűségigényeinket, az erőforráskvótánkat, a megbízhatósági követelményeket és a statisztikákat is. Mindezen információk alapján születik meg a döntés egy új metaklaszter létrehozásáról. Felhívjuk figyelmét, hogy a kis klaszterek nagymértékben bővülhetnek a jövőben, így az erőforrás-felhasználás akkor is nő, ha a klaszterek száma változatlan marad. Általában elegendő szabad helyet hagyunk az egyes fürtök növekedéséhez.

Rizs. 3. Terway hálózati architektúra

A varázsló összetevőinek skálázása az ügyfélfürtök között

A varázsló összetevőinek különböző erőforrásigényük van. Ezek a fürtben lévő csomópontok és podok számától, valamint az APIServerrel együttműködő nem szabványos vezérlők/operátorok számától függenek.

Az ACK-ben az egyes Kubernetes-ügyfélfürtök mérete és futásidejű követelményei eltérőek. Nincs univerzális konfiguráció a varázsló összetevőinek elhelyezésére. Ha tévedésből alacsony erőforráskorlátot állítunk be egy nagy klienshez, akkor a fürtje nem lesz képes megbirkózni a terheléssel. Ha konzervatívan magas korlátot állít be az összes fürt számára, az erőforrások pazarolni fognak.

A megbízhatóság és a költség közötti finom kompromisszum megtalálásához az ACK típusrendszert használ. A klaszterek három típusát határozzuk meg: kicsi, közepes és nagy. Minden típusnak külön erőforrás-allokációs profilja van. A típust a varázsló összetevőinek terhelése, a csomópontok száma és egyéb tényezők határozzák meg. A fürt típusa idővel változhat. Az ACK folyamatosan figyeli ezeket a tényezőket, és ennek megfelelően tud fel/le gépelni. A fürt típusának módosítása után az erőforrás-allokáció automatikusan frissül minimális felhasználói beavatkozással.

Azon dolgozunk, hogy finomabb méretezéssel és precízebb típusfrissítéssel javítsuk ezt a rendszert, hogy ezek a változtatások gördülékenyebben és gazdaságosabbak legyenek.

Rizs. 4. Intelligens többfokozatú típusváltás

Ügyfélklaszterek evolúciója léptékben

Az előző szakaszok a nagyszámú Kubernetes-fürt kezelésének néhány szempontját ismertették. Van azonban egy másik probléma is, amelyet meg kell oldani: a klaszterek evolúciója.

A Kubernetes a felhővilág „Linuxja”. Folyamatosan frissítik, és egyre modulárisabbá válik. Folyamatosan új verziókat kell szállítanunk ügyfeleinknek, ki kell javítanunk a sebezhetőségeket és frissítenünk kell a meglévő fürtöket, valamint nagyszámú kapcsolódó komponenst (CSI, CNI, Device Plugin, Scheduler Plugin és még sok más) kell kezelnünk.

Vegyük például a Kubernetes komponenskezelést. Kezdetben kifejlesztettünk egy központi rendszert az összes kapcsolódó komponens regisztrálására és kezelésére.

Rizs. 5. Rugalmas és csatlakoztatható alkatrészek

Mielőtt továbblépne, meg kell győződnie arról, hogy a frissítés sikeres volt. Ennek érdekében kidolgoztunk egy rendszert az alkatrészek működőképességének ellenőrzésére. Az ellenőrzés a frissítés előtt és után történik.

Rizs. 6. A klaszter összetevőinek előzetes ellenőrzése

Az összetevők gyors és megbízható frissítése érdekében a folyamatos üzembe helyezési rendszer támogatja a részleges továbbfejlesztést (szürkeárnyalatos), a szüneteket és egyéb funkciókat. A szabványos Kubernetes vezérlők nem alkalmasak erre a felhasználási esetre. Ezért a fürtkomponensek kezeléséhez speciális vezérlőket fejlesztettünk ki, beleértve egy beépülő modult és egy kiegészítő vezérlőmodult (oldalkocsi-kezelés).

Például a BroadcastJob vezérlőt úgy tervezték, hogy frissítse az egyes dolgozói gépeken lévő összetevőket, vagy ellenőrizze a csomópontokat az egyes gépeken. A Broadcast job a fürt minden csomópontján egy pod-ot futtat, mint egy DaemonSet. A DaemonSet azonban mindig hosszú ideig futva tartja a pod-ot, míg a BroadcastJob összecsukja. A Broadcast vezérlő az újonnan csatlakoztatott csomópontokon is elindítja a podokat, és inicializálja a csomópontokat a szükséges összetevőkkel. 2019 júniusában megnyitottuk az OpenKruise automatizálási motor forráskódját, amelyet mi magunk használunk a cégen belül.

Rizs. 7. Az OpenKurise megszervezi a Broadcast feladat végrehajtását az összes csomóponton

Annak érdekében, hogy segítsük ügyfeleinket a megfelelő fürtkonfiguráció kiválasztásában, egy sor előre definiált profilt is biztosítunk, beleértve a Serverless, Edge, Windows és Bare Metal profilokat. A táj bővülésével és ügyfeleink igényeinek növekedésével további profilokat adunk hozzá, hogy leegyszerűsítsük az unalmas beállítási folyamatot.

Rizs. 8. Fejlett és rugalmas fürtprofilok különféle forgatókönyvekhez

Globális megfigyelhetőség az adatközpontokon keresztül

Ahogy az alábbi ábrán látható. 9, az Alibaba Cloud Container felhőszolgáltatást a világ húsz régiójában telepítették. Ebben a léptékben az ACK egyik legfontosabb célja a futó fürtök állapotának egyszerű nyomon követése, hogy ha egy kliensfürt problémába ütközik, gyorsan reagálhassunk a helyzetre. Más szóval, olyan megoldást kell kidolgoznia, amely lehetővé teszi, hogy hatékonyan és biztonságosan, valós időben gyűjtsön statisztikákat az ügyfélfürtökről minden régióban – és vizuálisan is megjelenítse az eredményeket.

Rizs. 9. Az Alibaba Cloud Container szolgáltatás globális bevezetése húsz régióban

Mint sok Kubernetes megfigyelőrendszer, mi is a Prometheust használjuk fő eszközként. A Prometheus ügynökei minden metaklaszterhez a következő mutatókat gyűjtik:

• Az operációs rendszer mérőszámai, például a gazdagép erőforrások (CPU, memória, lemez stb.) és a hálózati sávszélesség.
• A metafürt- és ügyfélfürt-kezelő rendszer mérőszámai, például a kube-apiserver, a kube-controller-manager és a kube-scheduler.
• A kubernetes-state-metrics és a cadvisor mérőszámai.
• etcd metrikák, mint például a lemez írási ideje, az adatbázis mérete, a csomópontok közötti kapcsolatok átviteli sebessége stb.

A globális statisztikák gyűjtése tipikus többrétegű aggregációs modell segítségével történik. Az egyes metafürtök megfigyelési adatait először az egyes régiókban összesítik, majd elküldik egy központi szerverre, amely az összképet mutatja. Minden a szövetségi mechanizmuson keresztül működik. Minden adatközpontban egy Prometheus-szerver gyűjti a mérőszámokat az adott adatközpontból, és a központi Prometheus-szerver felelős a megfigyelési adatok összesítéséért. Az AlertManager csatlakozik a központi Prometheushoz, és szükség szerint riasztásokat küld DingTalkon, e-mailben, SMS-ben stb. Vizualizáció - Grafana használatával.

A 10. ábrán a felügyeleti rendszer három szintre osztható:

• Határszint

A középponttól legtávolabbi réteg. A Prometheus Edge Server minden metafürtben fut, és mérőszámokat gyűjt az ugyanazon a hálózati tartományon belüli meta- és kliensfürtöktől.

• Kaszkád szint

A Prometheus kaszkádréteg funkciója, hogy több régióból gyűjtsön megfigyelési adatokat. Ezek a szerverek nagyobb földrajzi egységek szintjén működnek, mint például Kína, Ázsia, Európa és Amerika. A klaszterek növekedésével a régió felosztható, majd minden új nagy régióban megjelenik egy kaszkád szintű Prometheus szerver. Ezzel a stratégiával zökkenőmentesen méretezhet igény szerint.

• Központi szint

A központi Prometheus szerver csatlakozik az összes kaszkádszerverhez, és elvégzi a végső adataggregációt. A megbízhatóság érdekében két központi Prometheus-példány került felállításra különböző zónákban, ugyanazon kaszkádszerverekhez kapcsolva.

Rizs. 10. Globális többszintű monitorozási architektúra, amely a Prometheus összevonási mechanizmuson alapul

Összegzés

A Kubernetes-alapú felhőmegoldások továbbra is átalakítják iparágunkat. Az Alibaba Cloud konténerszolgáltatás biztonságos, megbízható és nagy teljesítményű tárhelyet biztosít – ez az egyik legjobb Kubernetes felhőtárhely. Az Alibaba Cloud csapata erősen hisz a nyílt forráskód és a nyílt forráskódú közösség elveiben. Minden bizonnyal továbbra is megosztjuk tudásunkat a felhőtechnológiák üzemeltetése és kezelése terén.

Forrás: will.com