Ma arról fogok beszélni, hogyan írhat pályázatokat, és milyen követelményeknek kell megfelelnie ahhoz, hogy az alkalmazás jól működjön a Kubernetesben. Annak érdekében, hogy ne okozzon fejfájást az alkalmazás, hogy ne kelljen kitalálnia és semmiféle „repedést” építeni köré - és minden úgy működjön, ahogy maga a Kubernetes tervezte.
Ez az előadás része a "" Az Esti Iskola nyílt elméleti előadásait tekinthetik meg . Azok számára, akik a szöveget részesítik előnyben a videó helyett, elkészítettük ezt a cikket.
A nevem Pavel Selivanov, jelenleg én vagyok a Mail.ru Cloud Solutions vezető DevOps mérnöke, mi készítünk felhőket, készítünk felügyeleti kuberneteseket és így tovább. Feladataim közé tartozik most a fejlesztésben való segítségnyújtás, ezeknek a felhőknek a kiépítése, az általunk írt alkalmazások kiépítése és a felhasználók számára biztosított eszközök közvetlen fejlesztése.
DevOps-ot csinálok, azt hiszem, az elmúlt, valószínűleg három éve. De elvileg nagyjából öt éve azt csinálom, amit a DevOps. Előtte főleg adminisztrációs dolgokkal foglalkoztam. Nagyon régen kezdtem el dolgozni a Kubernetes-szel – valószínűleg körülbelül négy év telt el azóta, hogy elkezdtem vele dolgozni.
Általában akkor kezdtem, amikor a Kubernetes 1.3-as verziója volt, valószínűleg, és talán 1.2 - amikor még gyerekcipőben járt. Most már nem gyerekcipőben jár – és nyilvánvaló, hogy a piacon óriási kereslet van olyan mérnökök iránt, akik szeretnének Kubernetes-t csinálni. A cégeknek pedig nagyon nagy az igénye az ilyen emberekre. Ezért voltaképpen ez az előadás jelent meg.
Ha a terv szerint beszélünk arról, amiről beszélni fogok, akkor ez így néz ki, zárójelben az van írva (TL;DR) - „túl hosszú; ne olvass." Mai előadásom végtelen listákból áll majd.
Valójában én magam sem szeretem az ilyen prezentációkat, amikor készülnek, de ez olyan téma, hogy amikor ezt a prezentációt készítettem, egyszerűen nem igazán jöttem rá, hogyan lehet ezt az információt másképp rendszerezni.
Mert ezek az információk általában „ctrl+c, ctrl+v”, többek között a Wikink DevOps részében találhatók, ahol a fejlesztők számára írtunk követelményeket: „Srácok, indítsuk el az alkalmazást Kubernetes, ennek így kell lennie."
Ezért lett a prezentáció olyan nagy listává. Sajnálom. Igyekszem minél többet elmondani, hogy lehetőleg ne legyen unalmas.
Amit most megnézünk:
- ezek egyrészt naplók (alkalmazásnaplók?), mit kell velük csinálni a Kubernetesben, mit kell velük csinálni, milyenek legyenek;
- mi a teendő a Kubernetes konfigurációival, mi a legjobb és a legrosszabb mód a Kubernetes alkalmazás konfigurálására;
- Beszéljünk arról, hogy általában mik az akadálymentesítési ellenőrzések, hogyan nézzenek ki;
- beszéljünk arról, hogy mi a kecses leállás;
- beszéljünk újra az erőforrásokról;
- Érintse meg még egyszer az adattárolás témakörét;
- és a végén elmondom, mi a kifejezés ez a titokzatos felhőalapú alkalmazás. Cloudnativeness, mint e kifejezés mellékneve.
Naplók
Azt javaslom, hogy kezdje a rönkökkel – azzal, hogy hova kell ezeket a rönköket tolni Kubernetesben. Most elindított egy alkalmazást a Kubernetesben. A klasszikusok szerint az alkalmazások korábban mindig naplókat írtak valahova egy fájlba. A rossz alkalmazások naplókat írtak egy fájlba az alkalmazást elindító fejlesztő saját könyvtárában. A jó alkalmazások naplókat írtak egy fájlba valahol /var/log.
Ennek megfelelően a jó adminisztrátorok infrastruktúrájában beállítottak néhány dolgot, amit ezek a naplók elforgathattak - ugyanaz az rsyslog, amely megnézi ezeket a naplókat, és ha valami történik velük, akkor sok van belőlük, biztonsági másolatokat készít, naplókat tesz oda. , törli a régi fájlokat, több mint egy hét, hat hónap és még néhány. Elméletileg rendelkeznünk kellene olyan rendelkezésekkel, hogy pusztán azért, mert az alkalmazás naplókat ír, ne fogyjon el a hely az éles szervereken (harci szervereken?). És ennek megfelelően az egész gyártás nem állt le a rönkök miatt.
Amikor áttérünk a Kubernetes világába, és ott ugyanazt futtatjuk, az első dolog, amire figyelni lehet, az az, hogy az emberek, ahogy naplókat írnak egy fájlba, továbbra is írják azokat.
Kiderült, hogy ha Kubernetesről beszélünk, akkor a megfelelő hely a naplók írására valahova egy docker konténerből egyszerűen az, ha az alkalmazásból az úgynevezett Stdout/Stderr-be írjuk, vagyis az operációs rendszer szabványos kimeneti folyamaiba, standard hiba Kimenet . Ez a leghelyesebb, legegyszerűbb és leglogikusabb módja annak, hogy elvileg naplókat helyezzünk el a Dockerben és különösen a Kubernetisben. Mert ha az alkalmazás naplókat ír a Stdout/Stderr-be, akkor a Dockeren és a Kubernetes-kiegészítőn múlik, hogy mi legyen ezekkel a naplókkal. A Docker alapértelmezés szerint JSON formátumban készíti el a speciális fájljait.
Felmerül itt a kérdés, mit fogsz ezután kezdeni ezekkel a rönkökkel? A legegyszerűbb út egyértelmű, megvan a lehetőségünk rá kubectl logs és nézd meg ezeknek a „hüvelyeknek” ezeket a rönköket. De valószínűleg ez nem túl jó lehetőség - valami mást kell tenni a rönkökkel.
Egyelőre beszéljünk egyszerre, mivel érintettük a rönk témát, arról, hogy a rönknek milyennek kell lennie. Vagyis ez nem vonatkozik közvetlenül a Kubernetesre, de amikor elkezdünk azon gondolkodni, hogy mit kezdjünk a rönkökkel, akkor ezen is jó lenne elgondolkodni.
Szükségünk van valamiféle eszközre, békés úton, amely átveszi ezeket a naplókat, amelyeket a dokkolónk a fájljaiba helyez, és elküldi valahova. Általában véve a Kubernetesen belül általában elindítunk valamilyen ügynököt egy DaemonSet - egy naplógyűjtő - formájában, amely egyszerűen megmondja, hogy a Docker által gyűjtött naplók hol találhatók. Ez a begyűjtő ügynök pedig egyszerűen elviszi, esetleg valahogyan elemzi is, esetleg további metainformációkkal gazdagítja, és végül elküldi valahova tárolásra. Ott már lehetségesek a variációk. A legelterjedtebb talán az Elasticsearch, ahol naplókat tárolhatunk, és onnan kényelmesen elő lehet gyűjteni. Ezután egy kérés segítségével, például a Kibana segítségével grafikonokat építsünk ezek alapján, riasztásokat készítsünk ezek alapján stb.
A legfontosabb gondolat, szeretném megismételni, az, hogy a Dockeren belül, különösen a Kubernetesen belül, a naplók fájlban való tárolása nagyon rossz ötlet.
Mert először is nehéz a naplókat a tárolóban fájlba helyezni. Először be kell menni a konténerbe, ott végrehajtani, majd megnézni a naplókat. A következő pont az, hogy ha egy fájlban naplók vannak, akkor a konténerek általában minimalista környezettel rendelkeznek, és nincsenek olyan segédprogramok, amelyek általában szükségesek a naplókkal végzett normál munkához. Temesd el, nézd meg, nyissa meg őket egy szövegszerkesztőben. A következő pillanat az, amikor egy tárolóban lévő fájlban naplók vannak, és ha ez a tároló törlődik, akkor a naplók vele együtt elhalnak. Ennek megfelelően a tároló újraindítása azt jelenti, hogy nincs több napló. Ismét egy rossz lehetőség.
És az utolsó pont az, hogy általában a konténerekben van az alkalmazás, és ennyi – általában ez az egyetlen folyamat, amely fut. Egyáltalán nincs szó olyan folyamatról, amely elforgatná a fájlokat a naplókkal. Amint a naplók egy fájlba íródnak, ez azt jelenti, hogy elnézést kérünk, elkezdjük elveszíteni az éles szervert. Mert először is nehéz őket megtalálni, senki sem követi nyomon, ráadásul senki sem vezérli őket - ennek megfelelően a fájl végtelenül növekszik, amíg egyszerűen el nem fogy a hely a szerveren. Ezért ismét azt mondom, hogy rossz ötlet a Dockerben, különösen a Kubernetesben, egy fájlba bejelentkezni.
A következő pont, itt ismét erről szeretnék beszélni - mivel a rönk témát érintjük, jó lenne beszélni arról, hogyan nézzenek ki a rönkök, hogy kényelmes legyen velük dolgozni. Mint mondtam, a téma nem kapcsolódik közvetlenül a Kuberneteshez, de nagyon jól kapcsolódik a DevOps témájához. A fejlesztési kultúra és a két különböző részleg – a Dev és az Ops – közötti barátság témájában, hogy mindenki jól érezze magát.
Ez azt jelenti, hogy ideális esetben ma a naplókat JSON formátumban kell írni. Ha van valami érthetetlen saját alkalmazása, ami érthetetlen formátumban ír naplókat, mert beszúrsz valami printet vagy ilyesmit, akkor itt az ideje, hogy a google-ban keress valami keretrendszert, valamilyen wrappert, ami lehetővé teszi a normál naplózás megvalósítását; ott engedélyezze a naplózási paramétereket a JSON-ban, mert a JSON egyszerű formátum, az elemzése egyszerű.
Ha a JSON nem működik bizonyos feltételek szerint, senki sem tudja, mi, akkor legalább írjon naplókat olyan formátumban, amely értelmezhető. Itt inkább arra érdemes gondolni, hogy ha például egy csomó konténert vagy csak folyamatokat futtatsz az nginx-szel, és mindegyiknek megvannak a saját naplózási beállításai, akkor valószínűleg úgy tűnik, hogy nagyon kényelmetlen lesz elemezni őket. Mert minden új nginx példányhoz meg kell írni a saját értelmezőt, mert azok máshogy írnak naplókat. Ismét érdemes volt elgondolkodni azon, hogy megbizonyosodjon arról, hogy ezeknek az nginx-példányoknak ugyanaz a naplózási konfigurációja, és minden naplóját teljesen egységesen írta-e. Ugyanez vonatkozik abszolút minden alkalmazásra.
A végén olajat is szeretnék önteni a tűzre, hogy ideális esetben kerülni kell a többsoros formátumú naplókat. Itt van a helyzet, ha valaha is dolgozott rönkgyűjtőkkel, akkor valószínűleg látta, hogy mit ígérnek neked, hogy tudnak többsoros rönkökkel dolgozni, tudják, hogyan kell begyűjteni őket, és így tovább. Valójában véleményem szerint ma már egyetlen gyűjtő sem tud normálisan, teljesen és hibamentesen gyűjteni a többsoros naplókat. Emberi módon úgy, hogy kényelmes és hibamentes legyen.
De a verem nyomkövetése mindig többsoros naplók, és hogyan lehet elkerülni őket. A kérdés itt az, hogy a napló egy esemény rekordja, és a stactrace valójában nem napló. Ha összegyűjtjük a naplókat és elhelyezzük valahol az Elasticsearch-ben, majd grafikonokat rajzolunk belőlük, jelentéseket készítünk a felhasználói tevékenységről az Ön webhelyén, akkor amikor veremnyomot kap, az azt jelenti, hogy valami váratlan történik. Egy kezeletlen helyzet az alkalmazásban. És van értelme automatikusan feltölteni egy veremnyomot valahova egy olyan rendszerbe, amely képes követni őket.
Ez egy olyan szoftver (ugyanaz a Sentry), amely kifejezetten a verem nyomkövetésével működik. Azonnal létrehozhat automatizált feladatokat, hozzárendelheti őket valakihez, figyelmeztethet, ha stacttraces fordul elő, csoportosíthatja ezeket a stacttrace-okat egy típus szerint, és így tovább. Elvileg nincs sok értelme stactraces-ről beszélni, amikor naplókról beszélünk, mert ezek végül is különböző dolgok, más-más céllal.
Configuration
Ezután a Kubernetes konfigurációjáról beszélünk: mit kell tenni vele, és hogyan kell konfigurálni a Kubernetesen belüli alkalmazásokat. Általában azt szoktam mondani, hogy a Docker nem a konténerekről szól. Mindenki tudja, hogy a Docker a konténerekről szól, még azok is, akik nem sokat dolgoztak a Dockerrel. Ismétlem, a Docker nem a konténerekről szól.
A Docker véleményem szerint a szabványokról szól. És gyakorlatilag mindenre vannak szabványok: szabványok az alkalmazás felépítésére, szabványok az alkalmazás telepítésére.
És ezt a dolgot - korábban is használtuk, csak a konténerek megjelenésével vált különösen népszerűvé - ezt a dolgot ENV (environment) változóknak hívják, vagyis környezeti változóknak, amelyek az operációs rendszerben vannak. Ez általában ideális módja az alkalmazás konfigurálásának, mert ha JAVA, Python, Go, Perl nyelvű alkalmazásai vannak, ne adj isten, és ezek mind be tudják olvasni az adatbázis gazdagépét, az adatbázis felhasználóját, az adatbázis jelszavait, akkor ez az ideális. Az adatbázistervben ugyanúgy négy különböző nyelvű alkalmazásai vannak konfigurálva. Nincs több különböző konfiguráció.
Minden konfigurálható az ENV változókkal. Amikor a Kubernetesről beszélünk, nagyszerű módja van az ENV-változók deklarálásának közvetlenül a telepítésen belül. Ennek megfelelően, ha titkos adatokról beszélünk, akkor az ENV-változók titkos adatait (adatbázisok jelszavai, stb.) azonnal titkosíthatjuk egy titokba, létrehozhatunk egy titkos klasztert és jelezhetjük az ENV leírásában a Telepítésben, hogy nem közvetlenül deklarálunk. ennek a változónak az értéke és ennek az adatbázisjelszó változónak az értéke lesz kiolvasva a titkosból. Ez a Kubernetes szabványos viselkedése. És ez a legideálisabb lehetőség az alkalmazások konfigurálására. Csak a kód szintjén, ez ismét a fejlesztőkre vonatkozik. Ha Ön DevOps, kérdezheti: „Srácok, kérem, tanítsa meg alkalmazását környezeti változók olvasására. És mindannyian boldogok leszünk.”
Ha a vállalatnál mindenki ugyanazt a nevű környezeti változót olvassa, akkor az nagyszerű. Nehogy megtörténjen, hogy egyesek a postgres adatbázisra, mások az adatbázis nevére, mások valami másra, mások valamiféle dbn-re várnak, hogy ennek megfelelően egységes legyen.
A probléma akkor jelentkezik, ha annyi környezeti változója van, hogy csak megnyitja a Deployment alkalmazást – és a környezeti változók ötszáz sora van. Ebben az esetben egyszerűen túlnőttél a környezeti változókon – és többé nem kell kínoznod magad. Ebben az esetben érdemes elkezdeni a konfigurációkat. Vagyis tanítsa be az alkalmazást a konfigurációk használatára.
A kérdés csak az, hogy a konfigurációk nem olyanok, mint amilyennek gondolod. A Config.pi nem egy kényelmesen használható konfiguráció. Vagy valamilyen konfig a saját formátumodban, vagy ajándékba – szintén nem erre gondolok.
Amiről beszélek, az az elfogadható formátumú konfiguráció, vagyis messze a legnépszerűbb szabvány a .yaml szabvány. Világos, hogyan kell olvasni, ember által olvasható, világos, hogyan kell kiolvasni az alkalmazásból.
Ennek megfelelően a YAML mellett használhatod például a JSON-t is, az elemzés körülbelül olyan kényelmes, mint a YAML abból a szempontból, hogy onnan olvassa be az alkalmazás konfigurációját. Érezhetően kényelmetlenebb az olvasás az emberek számára. Kipróbálhatod a formátumot, a la ini. Emberi szempontból elég kényelmes az olvasása, de lehet, hogy kényelmetlen az automatikus feldolgozás, abban az értelemben, hogy ha valaha is saját konfigurációkat akarunk generálni, akkor az ini formátumot már kényelmetlen lehet előállítani.
De mindenesetre bármilyen formátumot választasz, a lényeg, hogy Kubernetes szempontból nagyon kényelmes. A teljes konfigurációt elhelyezheti a Kubernetesben, a ConfigMapben. Ezután vegyük ezt a konfigurációs térképet, és kérjük, hogy illesszük be a podba egy bizonyos könyvtárba, ahol az alkalmazás úgy olvassa be a konfigurációt ebből a konfigurációs térképből, mintha csak egy fájl lenne. Valójában ez az, amit jó megtenni, ha sok konfigurációs lehetőség van az alkalmazásban. Vagy ez csak valamiféle összetett szerkezet, van fészkelés.
Ha rendelkezik konfigurációs térképpel, akkor nagyon jól megtaníthatja az alkalmazást például arra, hogy automatikusan kövesse a változásokat a fájlban, ahol a konfigurációs térkép fel van szerelve, és automatikusan újratölti az alkalmazást, amikor a konfigurációk megváltoznak. Általában ez lenne az ideális választás.
Már megint beszéltem erről - a titkos információ nincs a konfigurációs térképen, a titkos információ nincs változóban, a titkos információ nincs a titkokban. Innentől kezdve kapcsolja össze ezt a titkos információt a diplomáciával. Általában a Kubernetes objektumok, telepítések, konfigurációs térképek és szolgáltatások összes leírását a git-ben tároljuk. Ennek megfelelően az adatbázis jelszavát a git-ben elhelyezni, még akkor is, ha az a saját git-je, amely a cégen belül van, rossz ötlet. Mert a git legalább mindenre emlékszik, és egyszerűen eltávolítani onnan a jelszavakat nem olyan egyszerű.
Állapotfelmérés
A következő pont az állapotfelmérés. Általánosságban elmondható, hogy az állapotfelmérés egyszerűen azt ellenőrzi, hogy az alkalmazás működik-e. Ugyanakkor leggyakrabban bizonyos webes alkalmazásokról beszélünk, amelyeknél ennek megfelelően állapotfelmérés szempontjából (jobb, ha nem fordítjuk ide és tovább) ez valami speciális URL lesz, amit úgy dolgoznak fel. szabvány, általában megteszik /health.
Ennek az URL-nek az elérésekor ennek megfelelően az alkalmazásunk azt mondja, hogy „igen, oké, minden rendben velem, 200”, vagy „nem, nincs rendben velem minden, kb 500”. Ennek megfelelően, ha az alkalmazásunk nem http, nem webalkalmazás, akkor most valami démonról beszélünk, kitalálhatjuk, hogyan kell elvégezni az állapotvizsgálatokat. Vagyis nem szükséges, ha az alkalmazás nem http, akkor minden működik állapotfelmérés nélkül, és ezt semmiképpen nem lehet megtenni. Időnként frissíthet néhány információt a fájlban, kitalálhat valamilyen speciális parancsot a démonhoz, mint pl. daemon status, amely azt fogja mondani, hogy "igen, minden rendben, a démon működik, életben van."
Mire való? Az első és legnyilvánvalóbb dolog valószínűleg az, hogy miért van szükség állapotfelmérésre – annak megértéséhez, hogy az alkalmazás működik. Úgy értem, ez hülyeség, amikor most felkerül, úgy tűnik, hogy működik, így biztos lehetsz benne, hogy működik. És kiderül, hogy az alkalmazás fut, a konténer fut, a példány működik, minden rendben - és akkor a felhasználók már levágták az összes telefonszámot a technikai támogatásról, és azt mondják, hogy "mi vagy te..., te elaludtam, semmi sem működik."
Az állapotfelmérés csak egy módja annak, hogy a felhasználó szemszögéből lássa, hogy működik. Az egyik módszer. Fogalmazzunk így. A Kubernetes szemszögéből ez is egy módja annak, hogy megértsük, mikor indul az alkalmazás, mert megértjük, hogy van különbség aközött, hogy mikor indult a konténer, mikor jött létre és indult el, illetve mikor indult el közvetlenül ebben a tárolóban az alkalmazás. Mert ha veszünk egy átlagos java alkalmazást, és megpróbáljuk elindítani a dokkban, akkor negyven másodpercre, de akár egy percre, de akár tízre is, jól beindul. Ilyenkor legalább a portjaira lehet kopogtatni, ott nem fog válaszolni, vagyis még nem áll készen a forgalom fogadására.
Ismét egy állapotfelmérés segítségével és annak segítségével, hogy itt fordulunk, megérthetjük Kubernetesben, hogy nem csak a konténer emelkedett fel az alkalmazásban, hanem maga az alkalmazás is elindult, már reagál a állapotfelmérés, ami azt jelenti, hogy oda tudjuk küldeni a forgalmat.
Amiről most beszélek, az az úgynevezett Readiness/Liveness tesztek a Kubernetesen belül; ennek megfelelően a készenléti tesztjeink felelősek az alkalmazás elérhetőségéért a kiegyensúlyozásban. Vagyis ha készenléti teszteket végeznek az alkalmazásban, akkor minden rendben van, a kliensforgalom az alkalmazásba megy. Ha nem történik készenléti teszt, akkor az alkalmazás egyszerűen nem vesz részt, az adott példány nem vesz részt a kiegyenlítésben, kikerül a kiegyenlítésből, az ügyfélforgalom nem folyik. Ennek megfelelően Liveness tesztekre van szükség a Kubernetesen belül, hogy ha az alkalmazás elakadna, újra lehessen indítani. Ha az élességteszt nem működik a Kubernetesben deklarált alkalmazásnál, akkor az alkalmazást nem csak eltávolítják a kiegyenlítésből, hanem újraindítják.
És itt van egy fontos szempont, amit szeretnék megemlíteni: gyakorlati szempontból általában gyakrabban használják a készültségi próbát, és gyakrabban van rá szükség, mint az életképességi tesztre. Vagyis egyszerűen meggondolatlanul deklarálni mind a készenléti, mind az életképességi tesztet, mert a Kubernetes képes erre, és használjunk ki mindent, amit tud, nem túl jó ötlet. Elmagyarázom miért. Mert a tesztelés második pontja az, hogy jó ötlet lenne ellenőrizni a mögöttes szolgáltatást az állapotfelmérés során. Ez azt jelenti, hogy ha van egy webalkalmazása, amely kiad néhány információt, amit viszont természetesen el kell vennie valahonnan. Például adatbázisban. Nos, a REST API-ba érkező információkat ugyanabba az adatbázisba menti. Ezután ennek megfelelően, ha az állapotellenőrzés egyszerűen úgy válaszol, mint a contacted slashhealth, akkor az alkalmazás azt mondja, hogy „200, oké, minden rendben”, ugyanakkor az alkalmazás adatbázisa nem érhető el, és a Healthcheck alkalmazás azt mondja, hogy „200, oké, minden rendben ” - Ez egy rossz állapotfelmérés. Ennek nem így kellene működnie.
Vagyis a jelentkezését, amikor arra kérés érkezik /health, nem csak azt válaszolja, hogy „200, ok”, először bemegy pl. adatbázist, és lekérdezheti az adatbázist. Ha mindez sikeres volt, akkor a válasz „200, ok”. Ha nem sikerül, akkor azt írja, hogy hiba van, az adatbázis nem elérhető.
Ezért ebben a vonatkozásban ismét visszatérek a Készenléti/Életképességi tesztekhez - miért van nagy valószínűséggel szükséged készültségi tesztre, de az életképességi teszt kérdéses. Mert ha pontosan úgy írod le az állapotfelméréseket, ahogy az imént mondtam, akkor kiderül, hogy a példányrészben nem elérhetőв или со всех instancepéldául egy adatbázisban. Amikor kijelentette a készenléti tesztet, az állapotfelmérésünk elkezdett kudarcot vallani, és ennek megfelelően minden olyan alkalmazás, amelyből az adatbázis nem érhető el, egyszerűen ki van kapcsolva a kiegyensúlyozásból, és valójában csak elhanyagolt állapotban „lefagy”, és megvárja, amíg az adatbázisa fel nem fér. munka.
Ha bejelentettünk egy életerőtesztet, akkor képzeld el, az adatbázisunk elromlott, és a Kubernetesedben mindennek a fele újraindul, mert az életességteszt meghiúsul. Ez azt jelenti, hogy újra kell indítania. Ez egyáltalán nem az, amit akarsz, még személyes tapasztalatom is volt a gyakorlatban. Volt egy csevegőalkalmazásunk, amelyet JS-ben írtak, és betápláltunk egy Mongo adatbázisba. A probléma pedig az volt, hogy a Kubernetes-es munkám elején leírtuk a tesztek készségét, életszerűségét azon az elven, hogy a Kubernetes meg tudja csinálni, úgyhogy használni fogjuk. Ennek megfelelően egy bizonyos ponton Mongo kissé „tompává” vált, és a minta kezdett kudarcot vallani. Ennek megfelelően az esőpróba szerint a hüvelyek elkezdtek „ölni”.
Amint érti, amikor „megölik” őket, ez egy chat, vagyis rengeteg kliens kapcsolat lóg rajta. Őket is "megölik" - nem, nem ügyfelek, csak kapcsolatok - nem egyszerre, és mivel nem egy időben, hol korábban, hol később, nem egyszerre kezdik idő. Ráadásul a standard véletlenszerűen nem tudjuk ezredmásodperces pontossággal megjósolni az alkalmazás indulási idejét minden alkalommal, ezért ezt egy-egy példányban teszik meg. Egy infospot felemelkedik, bekerül a kiegyenlítésbe, oda jön az összes ügyfél, nem bír el ekkora terhelést, mert egyedül van, és durván szólva tucatnyian dolgoznak ott, és leesik. A következő felemelkedik, rajta van az egész teher, ő is esik. Nos, ezek a zuhanások folyamatosan zuhognak. Végül, hogyan sikerült ezt megoldani - csak szigorúan le kellett állítani a felhasználói forgalmat ehhez az alkalmazáshoz, hagyni, hogy minden példány emelkedjen, majd egyszerre elindítsuk az összes felhasználói forgalmat, hogy az már el legyen oszlik mind a tíz példány között.
Ha nem jelentették volna be ezt az élességtesztet, amely az egészet újraindításra kényszerítené, az alkalmazás jól kezelte volna. De nálunk a kiegyenlítéstől kezdve minden le van tiltva, mert az adatbázisokhoz nem lehet hozzáférni, és minden felhasználó „leesett”. Aztán amikor ez az adatbázis elérhetővé válik, minden benne van a kiegyenlítésben, de az alkalmazásoknak nem kell újraindulniuk, és nem kell erre időt és erőforrást pazarolni. Már mind itt vannak, készen állnak a forgalomra, így a forgalom csak megnyílik, minden rendben - az alkalmazás a helyén van, minden működik tovább.
Ezért a felkészültségi és az életképességi tesztek különbözőek, sőt, elméletileg különböző egészségi állapotfelméréseket lehet végezni, például egy típusú sugarat, egy típusú élt, és különböző dolgokat. A készenléti tesztek során ellenőrizze a háttérrendszereket. És például az élőségteszten nem abból a szempontból ellenőrzik, hogy az élőségteszt általában csak egy alkalmazás válaszol, ha egyáltalán tud válaszolni.
Mert az életerő-teszt általában az, amikor „elakadtunk”. Elindult egy végtelen hurok, vagy valami más – és nem dolgoznak fel több kérést. Ezért van értelme akár szétválasztani őket – és más logikát alkalmazni bennük.
Arra vonatkozóan, hogy mit kell válaszolnia, amikor vizsgálaton vagy egészségügyi ellenőrzésen vesz részt. Ez csak igazán fájdalom. Aki ismeri ezt, az valószínűleg nevetni fog – de komolyan, életemben láttam olyan szolgáltatásokat, amelyek az esetek 200%-ában „XNUMX”-ra válaszolnak. Vagyis ki a sikeres. De ugyanakkor a válasz törzsébe azt írják, hogy „ilyen és ilyen hiba”.
Vagyis a válasz állapota Önhöz érkezik - minden sikeres. De ugyanakkor elemezni kell a testet, mert a test azt mondja, hogy "bocs, a kérés hibával ért véget", és ez csak a valóság. Ezt a való életben láttam.
És hogy egyesek ne találják viccesnek, mások pedig nagyon fájdalmasnak, még mindig érdemes betartani egy egyszerű szabályt. Az állapotfelmérés során, és elvileg a webes alkalmazásokkal való munka során.
Ha minden jól ment, akkor válaszoljon a kétszázados válasszal. Elvileg bármelyik kétszázados válasz megfelel. Ha nagyon jól olvassa a ragsy nyelvet, és tudja, hogy egyes válaszstátuszok eltérnek másoktól, válaszoljon a megfelelő státuszokkal: 204, 5, 10, 15, bármi. Ha nem túl jó, akkor csak „két nulla nulla”. Ha minden rosszul megy, és az állapotfelmérés nem válaszol, akkor bármelyik ötszázaddal válaszoljon. Ismét, ha megérti, hogyan kell válaszolni, miben térnek el a különböző válaszállapotok egymástól. Ha nem érti, akkor az 502-es az Ön lehetősége, hogy válaszoljon az állapotellenőrzésekre, ha valami baj van.
Ez egy másik pont, szeretnék egy kicsit visszatérni az alapul szolgáló szolgáltatások ellenőrzésére. Ha például elkezdi ellenőrizni az alkalmazás mögött álló összes mögöttes szolgáltatást – általában mindent. A mikroszolgáltatási architektúra szemszögéből kapunk egy olyan fogalmat, mint „alacsony csatolás”, vagyis amikor szolgáltatásai minimálisan függenek egymástól. Ha egyikük meghibásodik, az összes többi e funkció nélkül egyszerűen tovább működik. Egyes funkciók egyszerűen nem működnek. Ennek megfelelően, ha az összes egészségügyi ellenőrzést egymáshoz kötitek, akkor egy dolog kiesik az infrastruktúrában, és mivel ez leesett, az összes szolgáltatás összes egészségügyi ellenőrzése is kudarcot vallana - és általában több infrastruktúra áll rendelkezésre a teljes mikroszolgáltatás architektúra sz. Ott minden elsötétült.
Ezért szeretném még egyszer megismételni, hogy ellenőrizni kell a mögöttes szolgáltatásokat, azokat, amelyek nélkül az Ön pályázata az esetek száz százalékában nem tudja ellátni a dolgát. Azaz logikus, hogy ha van REST API-ja, amelyen keresztül a felhasználó az adatbázisba ment, vagy az adatbázisból visszakeres, akkor adatbázis hiányában nem tudja garantálni a munkát a felhasználóival.
De ha a felhasználói, amikor kiveszi őket az adatbázisból, további metaadatokkal gazdagodnak, egy másik háttérből, amelyeket megad, mielőtt választ küldene a frontendnek – és ez a háttér nem érhető el, ez azt jelenti, hogy megadja a válaszoljon a metaadatok bármely része nélkül.
Következő, az alkalmazások indításakor az egyik fájdalmas problémánk van.
Valójában ez nem csak a Kubernetesre vonatkozik nagy vonalakban, csak úgy történt, hogy a Kubernetessel nagyjából egy időben kezdett elterjedni valamiféle tömeges fejlesztés kultúrája és különösen a DevOps. Ezért nagyjából kiderül, hogy kecsesen le kell zárnia az alkalmazást a Kubernetes nélkül. Már a Kubernetes előtt is ezt csinálták az emberek, de a Kubernetes megjelenésével tömegesen kezdtünk beszélni róla.
Kecses leállítás
Általában mi az a Graceful Shutdown, és miért van rá szükség? Ez arról szól, amikor az alkalmazás valamilyen okból összeomlik, ezt meg kell tennie app stop - vagy például jelzést kap az operációs rendszertől, az alkalmazásnak meg kell értenie, és tennie kell ellene. A legrosszabb forgatókönyv természetesen az, amikor az alkalmazásod SIGTERM-et kap, és így szól: "SIGTERM, várjunk, dolgozzunk, ne csináljunk semmit." Ez egy kifejezetten rossz lehetőség.
Szinte ugyanilyen rossz lehetőség az is, amikor az alkalmazásod SIGTERM-et kap, és a következőképpen néz ki: „azt mondták, hogy segterm, ez azt jelenti, hogy véget érünk, nem láttam, nem ismerek felhasználói kéréseket, nem tudom, milyen A kérések, amelyeken jelenleg dolgozom, azt mondták, hogy SIGTERM, ez azt jelenti, hogy véget érünk Ez is egy rossz lehetőség.
Melyik opció a jó? Az első pont a műveletek befejezésének figyelembevétele. Jó megoldás, ha a szerver továbbra is figyelembe veszi, mit csinál, ha SIGTERM-et kap.
A SIGTERM egy soft shutdown, speciálisan kidolgozott, kódszinten lefogható, feldolgozható, mondjuk most várjunk, előbb befejezzük a munkát, ami van, aztán kilépünk.
Kubernetes szemszögéből ez így néz ki. Amikor azt mondjuk a Kubernetes-fürtben futó podnak, hogy „állj meg, menj el”, vagy újraindulunk, vagy frissítés történik, amikor a Kubernetes újra létrehozza a podokat, a Kubernetes ugyanazt a SIGTERM üzenetet küldi a podnak, és vár egy kis idő, és , ez az az idő, amikor vár, ez is be van állítva, van egy ilyen speciális paraméter a diplomákban, és ez a Graceful ShutdownTimeout. Mint érti, nem hiába hívják így, és nem hiába beszélünk most róla.
Itt konkrétan megmondhatjuk, hogy mennyit kell várnunk a SIGTERM alkalmazásnak való elküldése és amikor megértjük, hogy az alkalmazás úgy tűnik, valamiért megőrült, vagy „elakadt”, és nem fog véget érni – és meg kell küldje el SIGKILL-t, azaz keményen fejezze be a munkáját. Vagyis ennek megfelelően valami démonunk fut, ez dolgozza fel a műveleteket. Megértjük, hogy a démon által végzett műveleteink átlagosan nem tartanak 30 másodpercnél tovább egyszerre. Ennek megfelelően, amikor a SIGTERM megérkezik, megértjük, hogy a démonunk legfeljebb 30 másodperccel a SIGTERM után végezhet. Írunk rá például 45 másodpercet minden esetre, és azt mondjuk, hogy SIGTERM. Ezután várunk 45 másodpercet. Elméletileg ez idő alatt a démonnak be kellett volna fejeznie a munkáját és véget kellett volna vetnie önmagának. De ha hirtelen nem sikerül, az azt jelenti, hogy nagy valószínűséggel elakadt – már nem a szokásos módon dolgozza fel a kéréseinket. És 45 másodperc alatt biztonságosan leszögezheti.
És itt tulajdonképpen akár 2 szempont is figyelembe vehető. Először is, értse meg, hogy ha kapott egy kérést, akkor valahogy elkezdett dolgozni vele, és nem adott választ a felhasználónak, de például megkapta a SIGTERM-et. Érdemes finomítani és választ adni a felhasználónak. Ez az első számú pont ebből a szempontból. A második pont itt az, hogy ha saját alkalmazást írsz, akkor általában úgy építed fel az architektúrát, hogy kapsz egy kérést az alkalmazásodra, majd elkezdesz dolgozni, elkezded letölteni a fájlokat valahonnan, letölteni egy adatbázist, és miegymás. Hogy. Általában a felhasználó, az Ön kérése fél óráig lefagy, és várja, hogy válaszoljon neki - akkor valószínűleg dolgoznia kell az architektúrán. Vagyis vegye figyelembe még a józan észt is, hogy ha a műveletei rövidek, akkor érdemes figyelmen kívül hagyni a SIGTERM-et és módosítani. Ha a műveletei hosszúak, akkor ebben az esetben nincs értelme figyelmen kívül hagyni a SIGTERM-et. Az ilyen hosszú műveletek elkerülése érdekében érdemes újratervezni az architektúrát. Hogy a felhasználók ne csak ácsorogjanak és várjanak. Nem tudom, csinálj oda valami websocket-et, csinálj reverse hook-okat, amiket a szervered már küld a kliensnek, bármi mást, de ne kényszerítsd a felhasználót, hogy fél órát lógjon, és várj egy session-t, amíg te válaszolj neki. Mert megjósolhatatlan, hogy hol törhet el.
Amikor az alkalmazás lejár, meg kell adnia a megfelelő kilépési kódot. Azaz, ha az alkalmazásod bezárásra, leállításra szólt, és normálisan le tudta állítani magát, akkor nem kell visszaadnod valamiféle 1,5,255 kilépési kódot és így tovább. Minden, ami nem nulla kód, legalábbis a Linux rendszerekben, ebben biztos vagyok, sikertelennek minősül. Ez azt jelenti, hogy ebben az esetben a kérelme hibával zárult. Ennek megfelelően békés úton, ha a jelentkezésed hiba nélkül fejeződött be, a kimeneten 0-t mondasz. Ha az alkalmazás valamilyen oknál fogva meghiúsul, akkor a kimenetben nem 0-t ír. És ezekkel az információkkal dolgozhat.
És az utolsó lehetőség. Rossz, ha a felhasználó elküld egy kérést, és fél órát lefagy, amíg feldolgozza. De általánosságban azt is szeretném elmondani, hogy az ügyfél oldaláról általában mi éri meg. Nem számít, hogy van mobilalkalmazásod, front-ended stb. Figyelembe kell venni, hogy általában a felhasználó munkamenete megszakítható, bármi megtörténhet. Előfordulhat például, hogy kérelmet küldenek, és nem kapnak választ. A frontendnek vagy a mobilalkalmazásnak – általában minden frontendnek, fogalmazzunk úgy – ezt figyelembe kell vennie. Ha websocketekkel dolgozik, általában ez a legrosszabb fájdalom, amit valaha tapasztaltam.
Amikor néhány szokásos chat fejlesztője ezt nem tudja, kiderül, hogy a websocket eltörhet. Számukra, ha valami történik a proxynál, csak megváltoztatjuk a konfigurációt, és az újratölti. Természetesen ebben az esetben minden hosszú életű ülés megszakad. A fejlesztők odarohannak hozzánk, és azt mondják: „Srácok, mit csináltok, a chat minden ügyfelünknél megszakadt!” Azt mondjuk nekik: „Mit csinálsz? Ügyfelei nem tudnak újra csatlakozni? Azt mondják: "Nem, szükségünk van arra, hogy az ülések ne szakadjanak szét." Röviden, ez valójában nonszensz. Figyelembe kell venni az ügyféloldalt. Főleg, ahogy mondom, a hosszú élettartamú munkameneteknél, például a websocketeknél, eltörhet, és a felhasználó észrevétlenül újra kell tudni telepíteni az ilyen munkameneteket. És akkor minden tökéletes.
Ресурсы
Valójában itt csak egy egyenes történetet mondok el. Megint a való életből. A legbetegebb dolog, amit valaha hallottam az erőforrásokról.
Erőforrások ebben az esetben, úgy értem, valamiféle kérések, korlátok, amelyeket a Kubernetes-fürtökben helyezhet el. A legviccesebb, amit egy fejlesztőtől hallottam... Az egyik fejlesztőtársam egy korábbi munkahelyén egyszer azt mondta: „Az alkalmazásom nem indul el a fürtben.” Néztem, hogy nem indul el, de vagy nem fért bele a forrásokba, vagy nagyon kicsi korlátokat szabtak. Röviden, az alkalmazás nem indul el az erőforrások miatt. Azt mondom: "Nem az erőforrások miatt indul el, te döntöd el, mennyi kell, és állíts be egy megfelelő értéket." Azt mondja: "Miféle források?" Elkezdtem neki magyarázni, hogy Kubernetes, a kérések határait és bla, bla, bla kell állítani. A férfi öt percig hallgatott, bólintott, és azt mondta: „Fejlesztőként jöttem ide, nem akarok tudni semmit semmilyen erőforrásról. Azért jöttem ide, hogy kódot írjak, és ennyi." Szomorú. Ez egy nagyon szomorú koncepció a fejlesztő szemszögéből. Főleg a modern világban, hogy úgy mondjam, a progresszív devopok világában.
Miért van szükség egyáltalán forrásokra? A Kubernetesben kétféle erőforrás létezik. Néhányat kérésnek, másokat limiteknek neveznek. A források alapján megértjük, hogy alapvetően mindig csak két alapvető korlátozás létezik. Vagyis CPU-időkorlátok és RAM-korlátok egy Kubernetes-ben futó tárolóhoz.
A korlát felső határt szab arra vonatkozóan, hogy egy erőforrás hogyan használható fel az alkalmazásban. Vagyis ennek megfelelően, ha 1 GB RAM-ot mondasz a korlátok között, akkor az alkalmazásod nem tud 1 GB-nál többet használni. És ha hirtelen ezt akarja és megpróbálja megtenni, akkor az oom killer nevű folyamat, elfogyott a memóriája, azaz jön, és megöli az alkalmazását - vagyis egyszerűen újraindul. Az alkalmazások nem indulnak újra a CPU alapján. Ami a CPU-t illeti, ha egy alkalmazás sokat, többet próbál használni, mint amennyit a korlátok határoznak meg, akkor a CPU-t egyszerűen szigorúan kiválasztják. Ez nem vezet újraindításhoz. Ez a határ – ez a felső határ.
És van egy kérés. A kérés az, hogy a Kubernetes hogyan tudja megérteni, hogy a Kubernetes-fürt csomópontjai hogyan vannak feltöltve alkalmazásokkal. Ez azt jelenti, hogy a kérés egyfajta kötelezettségvállalása az alkalmazásának. Azt írja, hogy mit szeretnék használni: „Szeretném, ha ennyi CPU-t és ennyi memóriát foglalna le nekem.” Ilyen egyszerű analógia. Mi van, ha van egy csomópontunk, amiben, nem tudom, összesen 8 CPU van. És oda érkezik egy pod, aminek a kérései szerint 1 CPU, ami azt jelenti, hogy a csomópontnak 7 CPU maradt. Ez azt jelenti, hogy amint 8 pod érkezik ehhez a csomóponthoz, amelyek mindegyikének 1 CPU van a kéréseiben, a csomópontnak, mintha a Kubernetes szempontjából elfogyott volna a CPU, és nem lehet több kérést tartalmazó pod. ezen a csomóponton elindítva. Ha az összes csomópontból kifogy a CPU, a Kubernetes azt fogja mondani, hogy a fürtben nincsenek megfelelő csomópontok a pod-ok futtatásához, mert a CPU lemerült.
Miért van szükség kérésekre és miért kérések nélkül, szerintem nem kell semmit elindítani a Kubernetesben? Képzeljünk el egy hipotetikus helyzetet. Kérések nélkül elindítod az alkalmazásodat, a Kubernetes nem tudja, hogy mennyi van abból, ami van, milyen csomópontokra tolhatod. Nos, lökdösi, lökdösi, rányomja a csomópontokat. Egy bizonyos ponton elkezdődik a forgalom az alkalmazás felé. És az egyik alkalmazás hirtelen elkezdi felhasználni az erőforrásokat a korlátok szerint rendelkezésre álló korlátokig. Kiderült, hogy van egy másik alkalmazás a közelben, és ehhez is kell erőforrás. A csomópont ténylegesen kezd fizikailag kifogyni az erőforrásokból, például az OP-ból. A csomópont fizikailag kezd kifogyni az erőforrásaiból, például a véletlen elérésű memóriából (RAM). Ha egy csomópont lemerül, először a docker nem válaszol, majd a kocka, majd az operációs rendszer. Egyszerűen eszméletlenné válnak, és biztosan MINDEN nem fog működni az Ön számára. Ez azt jelenti, hogy a csomópont elakad, és újra kell indítania. Röviden, a helyzet nem túl jó.
És ha vannak kérései, a korlátok nem nagyon különböznek egymástól, legalábbis nem sokszor nagyobbak, mint a korlátok vagy kérések, akkor ilyen normális, racionálisan töltheti fel az alkalmazásokat a Kubernetes-fürtök csomópontjain keresztül. Ugyanakkor a Kubernetes hozzávetőlegesen tisztában van azzal, hogy miből mennyit tesz hova, miből mennyit hol használnak. Vagyis ez csak egy ilyen pillanat. Fontos megérteni. És fontos ellenőrizni, hogy ez jelezve legyen.
Adattárolás
Következő pontunk az adattárolásról szól. Mi a teendő velük, és általában mit kezdjünk a Kubernetesben való kitartással?
Azt hiszem, ismét a miénkben , Kubernetesben volt téma az adatbázisról. És nekem úgy tűnik, hogy nagyjából tudom, mit mondtak a kollégái, amikor megkérdezték: „Lehetséges adatbázist futtatni a Kubernetesben?” Valamiért úgy tűnik számomra, hogy a kollégáinak azt kellett volna mondaniuk, hogy ha azt a kérdést teszi fel, hogy lehetséges-e adatbázist futtatni Kubernetesben, akkor az lehetetlen.
A logika itt egyszerű. Minden esetre elmagyarázom mégegyszer, ha te egy nagyon jó srác vagy, aki meg tud építeni egy meglehetősen hibatűrő rendszert az elosztott hálózati tárolókból, akkor megértse, hogyan lehet ebbe az esetbe illeszteni egy adatbázist, hogyan kell működnie a konténerekben lévő felhő natívnak. adatbázisban általában. Valószínűleg nincs kérdése, hogyan kell futtatni. Ha van egy ilyen kérdése, és meg akar bizonyosodni arról, hogy mindez kibontakozik és halálra áll a gyártás során, és soha nem esik le, akkor ez nem történik meg. Ezzel a megközelítéssel garantáltan lábon lőd magad. Szóval jobb, ha nem.
Mit tegyünk azokkal az adatokkal, amelyeket az alkalmazásunk tárolni szeretne, néhány képpel, amit a felhasználók feltöltenek, néhány dologgal, amit az alkalmazásunk működése során generál, például indításkor? Mit lehet velük csinálni Kubernetesben?
Általában ideális esetben igen, természetesen a Kubernetes nagyon jól megtervezett, és általában eredetileg állapot nélküli alkalmazásokhoz készült. Vagyis azokra az alkalmazásokra, amelyek egyáltalán nem tárolnak információkat. Ez ideális.
De természetesen az ideális lehetőség nem mindig létezik. És akkor mi van? Az első és legegyszerűbb pont az, hogy vegyünk valami S3-at, csak nem házi készítésűt, aminek a működése is tisztázatlan, hanem valamilyen szolgáltatótól. Egy jó, normális szolgáltató – és tanítsd meg az alkalmazásodat az S3 használatára. Ez azt jelenti, hogy amikor a felhasználó fel akar tölteni egy fájlt, mondja azt, hogy „tessék, kérem, töltse fel az S3-ba”. Amikor meg akarja kapni, mondja ki: „Itt van egy link az S3-hoz, és vigye el innen.” Ez ideális.
Ha hirtelen valamilyen oknál fogva ez az ideális lehetőség nem megfelelő, van egy olyan alkalmazásod, amit nem írtál, nem fejlesztesz, vagy az valami szörnyű örökség, nem tudja használni az S3 protokollt, hanem működnie kell a helyi könyvtárakkal. helyi mappák. Vegyünk valami többé-kevésbé egyszerűt, telepítsük a Kuberneteset. Vagyis Ceph-t azonnal elkeríteni néhány minimális feladatra, szerintem rossz ötlet. Mert a Ceph persze jó és divatos. De ha nem igazán érted, hogy mit csinálsz, akkor ha egyszer felraksz valamit a Ceph-re, akkor nagyon könnyen és egyszerűen soha többé nem tudod kiszedni onnan. Mert, mint tudod, a Ceph bináris formában tárolja az adatokat a fürtjében, nem pedig egyszerű fájlok formájában. Ezért, ha a Ceph-fürt hirtelen meghibásodik, akkor teljes és nagy a valószínűsége annak, hogy soha többé nem kapja meg az adatait onnan.
Lesz egy tanfolyamunk Cephről, megteheted .
Ezért jobb, ha valami egyszerűt csinál, például egy NFS-kiszolgálót. A Kubernetes tud velük dolgozni, felcsatolhat egy könyvtárat egy NFS-kiszolgáló alá - az alkalmazás olyan, mint egy helyi könyvtár. Ugyanakkor természetesen meg kell értenie, hogy ismét tennie kell valamit az NFS-szel, meg kell értenie, hogy néha elérhetetlenné válhat, és meg kell fontolnia a kérdést, hogy mit fog tenni ebben az esetben. Talán valahol egy külön gépen kellene biztonsági másolatot készíteni.
A következő pont, amiről beszéltem, az, hogy mi a teendő, ha az alkalmazás működés közben néhány fájlt generál. Például amikor elindul, statikus fájlt generál, amely olyan információkon alapul, amelyeket az alkalmazás csak az indításkor kap meg. Micsoda pillanat. Ha nincs sok ilyen adat, akkor egyáltalán nem kell vesződnie, csak telepítse magának ezt az alkalmazást, és dolgozzon. A kérdés csak az, hogy mit, nézd. Nagyon gyakran mindenféle régebbi rendszer, mint például a WordPress és így tovább, főleg valamiféle okos bővítményekkel, okos PHP fejlesztőkkel, gyakran tudják, hogyan kell úgy csinálni, hogy valamilyen fájlt generáljanak maguknak. Ennek megfelelően az egyik létrehoz egy fájlt, a második pedig egy második fájlt. Különbözőek. Az egyensúlyozás az ügyfelek Kubernetes klaszterében egyszerűen véletlenül történik. Ennek megfelelően kiderül, hogy például nem tudják, hogyan működjenek együtt. Az egyik információt ad, a másik másikat ad a felhasználónak. Ezt érdemes kerülni. Vagyis a Kubernetesben minden, amit elindítasz, garantáltan több példányban is működhet. Mert a Kubernetes egy mozgalmas dolog. Ennek megfelelően bármit megmozgat, amikor csak akar, anélkül, hogy bárkit megkérdezne. Ezért számolnia kell ezzel. Minden, ami egy példányban elindult, előbb-utóbb meghiúsul. Minél több foglalásod van, annál jobb. De még egyszer mondom, ha van néhány ilyen fájlod, akkor közvetlenül magad alá helyezheted őket, kis súlyúak. Ha egy kicsit több van belőlük, valószínűleg nem szabad a tartályba tolni.
Azt tanácsolom, hogy van egy ilyen csodálatos dolog a Kubernetesben, használhatja a hangerőt. Különösen van egy üres dir típusú kötet. Vagyis csak arról van szó, hogy a Kubernetes automatikusan létrehoz egy könyvtárat a szolgáltatási könyvtáraiban azon a kiszolgálón, ahol elkezdte. És megadja neked, hogy használd. Csak egy fontos pont van. Ez azt jelenti, hogy adatai nem a tárolóban lesznek tárolva, hanem azon a gazdagépen, amelyen fut. Ezen túlmenően, a Kubernetes normál konfiguráció mellett képes szabályozni az ilyen üres mappákat, és képes szabályozni a maximális méretüket, és nem engedi túllépni azt. Csak az a lényeg, hogy amit üres könyvtárba írtál, az ne vesszen el a pod újraindításkor. Vagyis ha a pod tévedésből leesik és újra felemelkedik, az üres könyvtárban lévő információ nem megy sehova. Újra használhatja az új kezdeteknél – és ez jó. Ha a pod elmegy valahonnan, akkor természetesen adatok nélkül távozik. Ez azt jelenti, hogy amint eltűnik a pod abból a csomópontból, ahol üres dir-rel indították, az üres dir törlődik.
Mi a jó még az üres dirben? Például gyorsítótárként használható. Képzeljük el, hogy az alkalmazásunk menet közben generál valamit, megadja a felhasználóknak, és hosszú ideig csinálja. Ezért az alkalmazás például legenerálja és megadja a felhasználóknak, és egyben el is tárolja valahol, hogy ha legközelebb ugyanazért jön a felhasználó, gyorsabban lehessen azonnal generálva adni. Az üres dir megkérhető a Kubernetes-hez, hogy hozza létre a memóriában. Így a gyorsítótárak általában villámgyorsan működhetnek – ami a lemezelérési sebességet illeti. Vagyis van egy üres könyvtár a memóriában, az operációs rendszerben a memóriában van tárolva, de neked, a podban lévő felhasználónak, ez csak egy helyi könyvtárnak tűnik. Nincs szüksége az alkalmazásra a varázslat tanításához. Csak közvetlenül veszi és helyezi el a fájlt egy könyvtárba, de valójában az operációs rendszer memóriájába. Ez is nagyon kényelmes funkció a Kubernetes szempontjából.
Milyen problémái vannak a Miniónak? A Minióval az a fő probléma, hogy ahhoz, hogy ez a dolog működjön, valahol futnia kell, és kell lennie valamilyen fájlrendszernek, vagyis tárhelynek. És itt ugyanazokkal a problémákkal találkozunk, mint Ceph. Vagyis a Mininek valahol tárolnia kell a fájljait. Ez egyszerűen egy HTTP-interfész a fájlokhoz. Ráadásul a funkcionalitás egyértelműen gyengébb, mint az Amazon S3-é. Korábban nem tudta megfelelően engedélyezni a felhasználót. Most, amennyire én tudom, már tud különböző jogosultságokkal rendelkező vödröket létrehozni, de nekem megint úgy tűnik, hogy a fő probléma, hogy úgy mondjam, minimum a mögöttes tárolórendszer.
Hogyan befolyásolja az Empty dir a memóriában a limiteket? Semmilyen módon nem befolyásolja a korlátokat. A gazdagép memóriájában rejlik, és nem a konténer memóriájában. Ez azt jelenti, hogy a konténer nem látja a memóriában lévő üres könyvtárat a foglalt memória részeként. A házigazda ezt látja. Ennek megfelelően igen, a kubernetes szemszögéből, amikor elkezdi ezt használni, jó lenne megérteni, hogy emlékezetének egy részét az üres dir-nek szenteli. És ennek megfelelően értse meg, hogy a memória nem csak az alkalmazások miatt fogyhat el, hanem azért is, mert valaki ír ezekre az üres mappákra.
Felhősség
Az utolsó altéma pedig az, hogy mi a Cloudnative. Miért van rá szükség? Cloudnativeness és így tovább.
Vagyis azok az alkalmazások, amelyek alkalmasak és megírtak egy modern felhő infrastruktúrában való működésre. Valójában azonban a Cloudnative-nek van egy másik ilyen vonatkozása is. Hogy ez nem csak egy olyan alkalmazás, amely figyelembe veszi a modern felhő infrastruktúra minden követelményét, hanem tudja, hogyan kell dolgozni ezzel a modern felhő infrastruktúrával, kihasználja annak előnyeit és hátrányait, hogy ezekben a felhőkben működik. Ne essen túlzásokba és ne dolgozzon a felhőben, hanem használja ki a felhőben végzett munka előnyeit.
Vegyük például a Kubernetes-t. Alkalmazása Kubernetesben fut. Alkalmazása, vagy inkább az alkalmazás rendszergazdái bármikor létrehozhatnak szolgáltatási fiókot. Vagyis egy fiók az engedélyezéshez magában a Kubernetesben a szerverén. Adjunk hozzá néhány jogot, amire szükségünk van. A Kubernetes pedig az alkalmazáson belül is elérhető. Mit tehetsz így? Például az alkalmazástól kaphat adatokat arról, hogy hol található a többi alkalmazása, más hasonló példányok, és ha szükség van rá, valamilyen módon csoportosuljon a Kubernetes tetején.
Ismét szó szerint volt egy esetünk a közelmúltban. Van egy vezérlőnk, aki figyeli a sort. És amikor néhány új feladat jelenik meg ebben a sorban, akkor a Kuberneteshez kerül – és a Kubernetesen belül létrehoz egy új pod. Valamilyen új feladatot ad ennek a podnak, és ennek a podnak a keretein belül a pod elvégzi a feladatot, választ küld magának a vezérlőnek, majd a vezérlő csinál valamit ezzel az információval. Például összead egy adatbázist. Vagyis ez ismét egy plusz annak a ténynek, hogy alkalmazásunk Kubernetesben fut. Magát a beépített Kubernetes funkcionalitást is használhatjuk annak érdekében, hogy valamiképpen bővítsük és kényelmesebbé tegyük alkalmazásunk funkcionalitását. Vagyis ne rejtsenek el valami varázslatot azzal kapcsolatban, hogyan kell elindítani egy alkalmazást, hogyan kell elindítani egy dolgozót. A Kubernetesben egyszerűen elküld egy kérést az alkalmazásban, ha az alkalmazás Python nyelven íródott.
Ugyanez vonatkozik, ha túllépünk a Kubernetesen. Valahol fut a Kubernetesünk – jó, ha valamilyen felhőben van. Ismét használhatjuk, sőt, úgy gondolom, ki is kell használnunk magának a felhőnek a képességeit, ahol éppen futunk. Azokból az elemi dolgokból, amelyeket a felhő nyújt számunkra. Balancing, azaz felhőkiegyenlítőket készíthetünk és használhatjuk őket. Ez közvetlen előnye annak, amit felhasználhatunk. Mert a felhőegyensúlyozás egyrészt egyszerűen csak ostoba módon eltávolítja rólunk a felelősséget azért, hogy hogyan működik, hogyan van beállítva. Ráadásul nagyon kényelmes, mert a szokásos Kubernetes integrálható a felhőkkel.
Ugyanez vonatkozik a méretezésre is. A szokásos Kubernetes integrálható a felhőszolgáltatókkal. Tudja, hogyan kell megérteni, hogy ha a fürtből kifogynak a csomópontok, vagyis a csomóponti hely elfogy, akkor hozzá kell adnia - maga a Kubernetes új csomópontokat ad hozzá a fürthöz, és elkezdi elindítani rajtuk a podokat. Vagyis amikor megérkezik a terhelés, a kandallók száma növekedni kezd. Amikor a fürt csomópontjai elfogynak ezekhez a podokhoz, a Kubernetes új csomópontokat indít el, és ennek megfelelően a podok száma még növekedhet. És nagyon kényelmes. Ez egy közvetlen lehetőség a klaszter menet közbeni méretezésére. Nem túl gyors, abban az értelemben, hogy ez nem egy másodperc, inkább egy perc az új csomópontok hozzáadásához.
De tapasztalataim szerint ismét ez a legmenőbb dolog, amit valaha láttam. Amikor a Cloudnative-fürt a napszak alapján méreteződött. Ez egy háttérszolgáltatás volt, amelyet a háttérirodában dolgozók használtak. Vagyis reggel 9-kor jönnek dolgozni, elkezdenek bejelentkezni a rendszerbe, és ennek megfelelően a Cloudnative-fürt, ahol az egész fut, duzzadni kezd, új podokat indítva el, hogy mindenki, aki dolgozni jön, dolgozhasson az alkalmazással. Amikor este 8-kor vagy 6-kor távoznak a munkahelyükről, a Kubernetes-fürtök észreveszik, hogy már senki sem használja az alkalmazást, és csökkenni kezdenek. Akár 30 százalékos megtakarítás is garantált. Akkoriban az Amazonban működött, Oroszországban akkoriban nem volt senki, aki ilyen jól tudta volna csinálni.
Megmondom egyenesen, a megtakarítás 30 százalékos pusztán azért, mert Kubernetes-et használunk, és kihasználjuk a felhő adta lehetőségeket. Ezt most Oroszországban is meg lehet tenni. Természetesen senkinek nem fogok hirdetni, de mondjuk, hogy vannak szolgáltatók, akik ezt megtehetik, egy gombbal azonnal biztosítják a dobozból.
Még egy utolsó szempont, amelyre szintén szeretném felhívni a figyelmet. Ahhoz, hogy alkalmazása, infrastruktúrája Cloudnatív legyen, érdemes végre elkezdeni adaptálni az Infrastructure as a Code nevű megközelítést, vagyis ez azt jelenti, hogy az alkalmazásodra, vagy inkább az infrastruktúrádra pontosan ugyanúgy szükség van, mint a kód Írja le az alkalmazását, az üzleti logikáját kód formájában. És dolgozz vele kódként, azaz teszteld, gördítsd ki, tárold gitben, alkalmazd rá a CICD-t.
És pontosan ez az, ami lehetővé teszi, hogy először is mindig kézben tartsa infrastruktúráját, hogy mindig megértse, milyen állapotban van. Másodszor, kerülje a hibákat okozó kézi műveleteket. Harmadszor, kerülje el egyszerűen az úgynevezett forgást, amikor folyamatosan ugyanazokat a manuális feladatokat kell végrehajtania. Negyedszer, meghibásodás esetén sokkal gyorsabban felépülhet. Oroszországban minden alkalommal, amikor erről beszélek, mindig rengeteg ember azt mondja: „Igen, ez egyértelmű, de vannak megközelítései, egyszóval nem kell javítani semmit.” De igaz. Ha valami elromlott az infrastruktúrájában, akkor a Cloudnative megközelítés és az Infrastruktúra mint kód szempontjából egyszerűbb, mint megjavítani, elmenni a szerverre, kitalálni, hogy mi a hibás és kijavítani. a szerver törléséhez és újbóli létrehozásához. És mindezt helyreállítom.
Mindezeket a kérdéseket részletesebben a címen tárgyaljuk . A linkre kattintva megismerkedhet a programmal és a feltételekkel. A kényelmes dolog az, hogy elsajátíthatja a Kubernetes-et napi 1-2 órás otthoni tanulással vagy munkával.
Forrás: will.com