Dnes mám v pláne hovoriť o tom, ako písať aplikácie a aké sú požiadavky na to, aby vaša aplikácia dobre fungovala v Kubernetes. Aby s aplikáciou neboli žiadne bolesti hlavy, aby ste okolo nej nemuseli vymýšľať a budovať žiadne „škrabance“ – a všetko funguje tak, ako to zamýšľa samotný Kubernetes.
Táto prednáška je súčasťou "" Môžete si pozrieť otvorené teoretické prednášky Večernej školy . Pre tých, ktorí majú radšej text ako video, sme pripravili tento článok.
Volám sa Pavel Selivanov, momentálne som vedúci DevOps inžinier v Mail.ru Cloud Solutions, robíme cloudy, robíme manažérske kubernetes a tak ďalej. Moje úlohy teraz zahŕňajú pomoc pri vývoji, zavádzanie týchto cloudov, zavádzanie aplikácií, ktoré píšeme, a priamy vývoj nástrojov, ktoré poskytujeme našim používateľom.
DevOps robím, myslím, posledné, pravdepodobne tri roky. Ale v zásade robím to, čo DevOps, už asi päť rokov. Predtým som sa zaoberal hlavne administratívnymi vecami. S Kubernetes som začal pracovať už dávno - pravdepodobne ubehli asi štyri roky, odkedy som s ním začal pracovať.
Vo všeobecnosti som začal, keď bol Kubernetes pravdepodobne vo verzii 1.3 a možno 1.2 - keď bol ešte v plienkach. Teraz to už nie je v plienkach – a je zrejmé, že na trhu je obrovský dopyt po inžinieroch, ktorí by chceli robiť Kubernetes. A firmy majú po takýchto ľuďoch veľmi vysoký dopyt. Preto sa v skutočnosti objavila táto prednáška.
Ak hovoríme podľa plánu, o čom budem hovoriť, vyzerá to takto, v zátvorkách je napísané (TL;DR) - „príliš dlho; nečítaj“. Moja dnešná prezentácia bude pozostávať z nekonečných zoznamov.
Popravde, ja sám nemám rád takéto prezentácie, keď sa robia, ale toto je taká téma, že keď som túto prezentáciu pripravoval, jednoducho som veľmi neprišiel na to, ako tieto informácie inak usporiadať.
Pretože vo všeobecnosti sú tieto informácie „ctrl+c, ctrl+v“, okrem iného z našej Wiki v sekcii DevOps, kde máme napísané požiadavky pre vývojárov: „chalani, aby sme vašu aplikáciu spustili v Kubernetes, malo by to byť takto."
Preto sa prezentácia ukázala ako taký veľký zoznam. Prepáč. Pokúsim sa povedať čo najviac, aby to podľa možností nebolo nudné.
Na čo sa teraz pozrieme:
- toto sú po prvé protokoly (protokoly aplikácií?), čo s nimi v Kubernetes robiť, čo s nimi robiť, aké by mali byť;
- čo robiť s konfiguráciami v Kubernetes, aké sú najlepšie a najhoršie spôsoby konfigurácie aplikácie pre Kubernetes;
- Poďme si povedať, čo sú kontroly prístupnosti vo všeobecnosti, ako by mali vyzerať;
- povedzme si, čo je to elegantné vypnutie;
- hovorme opäť o zdrojoch;
- Dotknime sa ešte raz témy ukladania dát;
- a na záver vám prezradím, aký je pojem táto záhadná cloud-native aplikácia. Cloudnativeness, ako prídavné meno tohto pojmu.
Denníky
Navrhujem začať s protokolmi - s tým, kde je potrebné tieto protokoly vložiť do Kubernetes. Teraz ste spustili aplikáciu v Kubernetes. Podľa klasikov predtým aplikácie vždy zapisovali logy niekde do súboru. Zlé aplikácie zapisovali protokoly do súboru v domovskom adresári vývojára, ktorý aplikáciu spustil. Dobré aplikácie zapisovali protokoly do súboru niekde in /var/log.
V súlade s tým mali dobrí správcovia vo svojich infraštruktúrach nakonfigurované niektoré veci, aby sa tieto denníky mohli otáčať – ten istý rsyslog, ktorý sa na tieto denníky pozerá a keď sa im niečo stane, je ich veľa, vytvára záložné kópie, dáva tam denníky , odstráni staré súbory, viac ako týždeň, šesť mesiacov a niektoré ďalšie. Teoreticky by sme mali mať opatrenia, aby sa jednoducho preto, že aplikácia zapisuje protokoly, nevyčerpal priestor na produkčných serveroch (bojových serveroch?). A preto sa celá výroba nezastavila kvôli polenám.
Keď sa presunieme do sveta Kubernetes a spustíme tam to isté, prvá vec, ktorú môžete venovať pozornosť, je skutočnosť, že ľudia, ako písali protokoly do súboru, ich naďalej píšu.
Ukazuje sa, že ak hovoríme o Kubernetes, tým správnym miestom na zapisovanie protokolov niekde z kontajnera docker je jednoducho ich zapisovanie z aplikácie do takzvaného Stdout/Stderr, teda štandardných výstupných prúdov operačného systému, štandardná chyba výkon . Toto je najsprávnejší, najjednoduchší a najlogickejší spôsob, ako vložiť protokoly v princípe do Dockera a konkrétne do Kubernetis. Pretože ak vaša aplikácia zapisuje protokoly do Stdout/Stderr, potom je na Dockerovi a doplnku Kubernetes, aby sa rozhodli, čo s týmito protokolmi urobiť. Docker štandardne vytvorí svoje špeciálne súbory vo formáte JSON.
Tu vyvstáva otázka, čo budete ďalej robiť s týmito logami? Najjednoduchší spôsob je jasný, máme schopnosť urobiť kubectl logs a pozrite sa na tieto záznamy týchto „strukov“. Ale pravdepodobne to nie je veľmi dobrá možnosť - s protokolmi je potrebné urobiť niečo iné.
Zatiaľ sa bavme súčasne, keďže sme sa dotkli témy guľatiny, o takej veci, ako by guľatina mala vyzerať. To znamená, že to neplatí priamo pre Kubernetes, ale keď začneme premýšľať o tom, čo robiť s protokolmi, bolo by dobré myslieť aj na toto.
Potrebujeme nejaký druh nástroja, priateľským spôsobom, ktorý vezme tieto protokoly, ktoré náš docker vloží do svojich súborov, a pošle ich niekam. Vo všeobecnosti zvyčajne spúšťame nejaký druh agenta v Kubernetes vo forme DaemonSet - zberateľa protokolov, ktorému sa jednoducho povie, kde sa nachádzajú protokoly, ktoré Docker zhromažďuje. A tento zberateľ si ich jednoducho vezme, možno ich aj nejakým spôsobom po ceste rozoberie, možno obohatí o nejaké ďalšie metainformácie a nakoniec ich niekam pošle na uskladnenie. Už tam sú možné variácie. Najbežnejší je asi Elasticsearch, kde si môžete uložiť logy a odtiaľ ich pohodlne načítať. Potom pomocou požiadavky, napríklad pomocou Kibana, zostavte na základe nich grafy, na základe nich vytvorte upozornenia atď.
Najdôležitejšou myšlienkou, chcem to znova zopakovať, je, že vo vnútri Dockera, najmä v Kubernetes, je ukladanie vašich protokolov do súboru veľmi zlý nápad.
Pretože po prvé, je ťažké dostať protokoly do kontajnera v súbore. Najprv musíte vstúpiť do kontajnera, spustiť ho a potom sa pozrieť na protokoly. Ďalším bodom je, že ak máte logy v súbore, tak kontajnery majú väčšinou minimalistické prostredie a nie sú tam žiadne utility, ktoré sú zvyčajne potrebné na bežnú prácu s logami. Pochovať ich, pozrieť si ich, otvoriť v textovom editore. Ďalším momentom je, keď máme protokoly v súbore v kontajneri, ak je tento kontajner vymazaný, rozumiete, protokoly zomrú spolu s ním. Akékoľvek reštartovanie kontajnera teda znamená, že už neexistujú žiadne záznamy. Opäť zlá možnosť.
A posledný bod je, že vo vnútri kontajnerov máte zvyčajne svoju aplikáciu a to je všetko - zvyčajne je to jediný spustený proces. Vôbec sa nehovorí o nejakom procese, ktorý by rotoval súbory s vašimi logami. Hneď ako sa protokoly začnú zapisovať do súboru, znamená to, že prepáčte, začneme strácať produkčný server. Pretože, po prvé, je ťažké ich nájsť, nikto ich nesleduje a navyše ich nikto nekontroluje - súbor teda nekonečne rastie, až kým sa miesto na serveri jednoducho minie. Preto znova hovorím, že prihlásenie do Dockera, najmä v Kubernetes, do súboru je zlý nápad.
Ďalší bod, tu chcem opäť hovoriť o tomto - keďže sa dotýkame témy protokolov, bolo by dobré porozprávať sa o tom, ako by mali protokoly vyzerať, aby sa s nimi pohodlne pracovalo. Ako som povedal, téma priamo nesúvisí s Kubernetes, ale veľmi dobre súvisí s témou DevOps. Na tému kultúry rozvoja a priateľstva medzi týmito dvoma rôznymi oddeleniami - Dev a Ops, aby sa všetci cítili pohodlne.
To znamená, že v ideálnom prípade by sa dnes denníky mali zapisovať vo formáte JSON. Ak máte nejakú vlastnú nezrozumiteľnú aplikáciu, ktorá zapisuje protokoly v nezrozumiteľných formátoch, pretože vložíte nejaký druh tlače alebo niečo podobné, potom je čas vygoogliť si nejaký framework, nejaký obal, ktorý vám umožní implementovať normálne logovanie; povoľte tam parametre protokolovania v JSON, pretože JSON je jednoduchý formát, jeho analýza je jednoduchá.
Ak váš JSON nefunguje podľa nejakých kritérií, nikto nevie čo, tak aspoň píšte protokoly vo formáte, ktorý sa dá analyzovať. Tu skôr stojí za to zamyslieť sa nad tým, že ak napríklad prevádzkujete veľa kontajnerov alebo len procesov s nginx a každý má svoje vlastné nastavenia protokolovania, potom sa pravdepodobne zdá, že pre vás bude veľmi nepohodlné analyzovať ich. Pretože pre každú novú inštanciu nginx musíte napísať svoj vlastný syntaktický analyzátor, pretože píšu protokoly inak. Opäť sa pravdepodobne oplatilo premýšľať o tom, či sa uistiť, že všetky tieto inštancie nginx mali rovnakú konfiguráciu protokolovania a zapisovali všetky svoje protokoly absolútne jednotne. To isté platí pre úplne všetky aplikácie.
Na záver chcem tiež priliať olej do ohňa, že v ideálnom prípade by sa malo vyhnúť viacriadkovým formátom protokolov. Tu je vec, ak ste niekedy pracovali so zberačmi guľatiny, potom ste s najväčšou pravdepodobnosťou videli, čo vám sľubujú, že vedia pracovať s viacriadkovými guľatinami, vedia ich zbierať atď. V skutočnosti podľa mňa ani jeden zberač dnes nevie zbierať viacriadkové polená normálne, plnohodnotne a bez chýb. Ľudsky tak, aby to bolo pohodlné a bez chýb.
Ale sledovanie zásobníka je vždy viacriadkové protokoly a ako sa im vyhnúť. Otázkou je, že protokol je záznamom udalosti a stactrace v skutočnosti protokolom nie je. Ak zhromažďujeme protokoly a vložíme ich niekam do Elasticsearch a potom z nich vykreslíme grafy, vytvoríme nejaké správy o aktivite používateľov na vašom webe, potom keď získate stopu zásobníka, znamená to, že sa deje niečo neočakávané. Neošetrená situácia vo vašej aplikácii. A má zmysel automaticky nahrať stopu zásobníka niekam do systému, ktorý ich dokáže sledovať.
Toto je softvér (rovnaký Sentry), ktorý je vyrobený špeciálne na prácu so sledovaním zásobníka. Dokáže okamžite vytvárať automatizované úlohy, priraďovať ich niekomu, upozorňovať na výskyt stacttraces, zoskupovať tieto stacttraces podľa jedného typu atď. V zásade nemá veľký zmysel hovoriť o stactraces, keď hovoríme o protokoloch, pretože to sú koniec koncov rôzne veci s rôznym účelom.
konfigurácia
Ďalej hovoríme o konfigurácii v Kubernetes: čo s tým robiť a ako by mali byť nakonfigurované aplikácie v Kubernetes. Vo všeobecnosti zvyčajne hovorím, že Docker nie je o kontajneroch. Každý vie, že Docker je o kontajneroch, dokonca aj tí, ktorí s Dockerom veľa nepracovali. Opakujem, Docker nie je o kontajneroch.
Docker je podľa mňa o štandardoch. A existujú štandardy prakticky na všetko: štandardy pre zostavenie vašej aplikácie, štandardy pre inštaláciu vašej aplikácie.
A táto vec – používali sme ju už predtým, práve sa stala populárnou najmä s príchodom kontajnerov – táto vec sa nazýva ENV (environment) premenné, teda premenné prostredia, ktoré sú vo vašom operačnom systéme. Toto je vo všeobecnosti ideálny spôsob, ako nakonfigurovať vašu aplikáciu, pretože ak máte aplikácie v jazykoch JAVA, Python, Go, Perl, nedajbože, a všetky dokážu čítať premenné hostiteľa databázy, používateľa databázy, heslá databázy, potom je to ideálne. V databázovom pláne máte rovnakým spôsobom nakonfigurované aplikácie v štyroch rôznych jazykoch. Neexistujú žiadne ďalšie rôzne konfigurácie.
Všetko je možné konfigurovať pomocou ENV premenných. Keď hovoríme o Kubernetes, existuje skvelý spôsob, ako deklarovať premenné ENV priamo v rámci Deployment. V súlade s tým, ak hovoríme o tajných údajoch, potom môžeme okamžite vtlačiť tajné údaje z premenných ENV (heslá do databáz atď.) do tajomstva, vytvoriť tajný klaster a v popise ENV v Nasadení uviesť, že priamo nedeklarujeme hodnota tejto premennej a hodnota tejto premennej hesla databázy sa načíta z tajomstva. Toto je štandardné správanie Kubernetes. A to je najideálnejšia možnosť na konfiguráciu vašich aplikácií. Len na úrovni kódu to opäť platí pre vývojárov. Ak ste DevOps, môžete sa opýtať: „Chlapci, naučte vašu aplikáciu čítať premenné prostredia. A všetci budeme šťastní."
Ak každý v spoločnosti číta rovnako pomenované premenné prostredia, potom je to skvelé. Aby sa nestalo, že niektorí čakajú na postgres databázu, iní na názov databázy, iní na niečo iné, iní na dbn akéhosi druhu, aby teda bola jednotnosť.
Problém nastáva, keď máte toľko premenných prostredia, že stačí otvoriť Deployment – a existuje päťsto riadkov premenných prostredia. V tomto prípade ste jednoducho prerástli premenné prostredia – a už sa nemusíte mučiť. V tomto prípade by malo zmysel začať používať konfigurácie. To znamená, že natrénujte svoju aplikáciu na používanie konfigurácií.
Jedinou otázkou je, že konfigurácie nie sú to, čo si myslíte. Config.pi nie je konfigurácia, ktorá sa pohodlne používa. Alebo nejaká konfigurácia vo vašom vlastnom formáte, prípadne nadaná - to tiež nie je konfigurácia, ktorú mám na mysli.
Hovorím o konfigurácii v prijateľných formátoch, to znamená, že zďaleka najpopulárnejším štandardom je štandard .yaml. Je jasné, ako sa to číta, je to ľudsky čitateľné, z aplikácie je jasné, ako sa to číta.
Podľa toho môžete okrem YAML použiť napríklad aj JSON, parsovanie je z hľadiska čítania konfigurácie aplikácie odtiaľ asi rovnako pohodlné ako YAML. Pre ľudí je čítanie výrazne nepohodlnejšie. Môžete vyskúšať formát a la ini. Z ľudského hľadiska je to celkom pohodlné čítanie, ale môže byť nepohodlné ho spracovať automaticky v tom zmysle, že ak by ste niekedy chceli generovať svoje vlastné konfigurácie, generovať formát ini už môže byť nepohodlné.
Ale v každom prípade, nech už si vyberiete akýkoľvek formát, ide o to, že z pohľadu Kubernetes je to veľmi pohodlné. Celú svoju konfiguráciu môžete vložiť do Kubernetes v ConfigMap. A potom vezmite túto konfiguračnú mapu a požiadajte, aby bola pripojená do vášho podu v nejakom špecifickom adresári, kde vaša aplikácia načíta konfiguráciu z tejto konfiguračnej mapy, ako keby to bol iba súbor. To je v skutočnosti to, čo je dobré urobiť, keď máte vo svojej aplikácii veľa možností konfigurácie. Alebo je to len nejaký druh komplexnej štruktúry, existuje hniezdenie.
Ak máte konfiguračnú mapu, môžete svoju aplikáciu veľmi dobre naučiť napríklad automaticky sledovať zmeny v súbore, kde je konfiguračná mapa pripojená, a tiež automaticky znova načítať vašu aplikáciu pri zmene konfigurácií. Vo všeobecnosti by to bola ideálna možnosť.
Opäť som o tom hovoril - tajné informácie nie sú v konfiguračnej mape, tajné informácie nie sú v premenných, tajné informácie nie sú v tajomstvách. Odtiaľ spojte tieto tajné informácie s diplomaciou. Zvyčajne ukladáme všetky popisy objektov Kubernetes, nasadenia, konfiguračné mapy, služby v git. Preto je vloženie hesla do databázy v git, aj keď je to váš git, ktorý máte interne v spoločnosti, zlý nápad. Pretože minimálne si git pamätá všetko a jednoduché odstránenie hesiel odtiaľ nie je také jednoduché.
Kontrola zdravia
Ďalším bodom je táto vec s názvom Kontrola stavu. Vo všeobecnosti kontrola stavu jednoducho kontroluje, či vaša aplikácia funguje. Zároveň sa najčastejšie bavíme o určitých webových aplikáciách, pre ktoré teda z pohľadu zdravotnej kontroly (tu a ďalej radšej neprekladať) pôjde o nejakú špeciálnu URL, ktorú spracúvajú ako štandard, zvyčajne robia /health.
Pri prístupe na túto adresu URL preto naša aplikácia hovorí buď „áno, dobre, so mnou je všetko v poriadku, 200“ alebo „nie, so mnou nie je všetko v poriadku, asi 500“. V súlade s tým, ak naša aplikácia nie je http, nie webová aplikácia, teraz hovoríme o nejakom druhu démona, môžeme zistiť, ako vykonávať zdravotné kontroly. To znamená, že to nie je potrebné, ak aplikácia nie je http, tak všetko funguje bez kontroly stavu a to sa nedá nijako urobiť. Môžete pravidelne aktualizovať niektoré informácie v súbore, môžete prísť s nejakým špeciálnym príkazom pre svojho démona, ako napr. daemon status, ktorý povie „áno, všetko je v poriadku, démon funguje, je nažive“.
Načo to je? Prvá a najzrejmejšia vec je pravdepodobne dôvod, prečo je potrebná kontrola stavu - aby ste pochopili, že aplikácia funguje. Teda, je to len hlúposť, keď je teraz hore, vyzerá to, že to funguje, takže si môžete byť istý, že to funguje. A ukázalo sa, že aplikácia je spustená, kontajner je spustený, inštancia funguje, všetko je v poriadku - a potom používatelia už odstrihli všetky telefónne čísla od technickej podpory a povedali „čo si..., ty zaspal, nič nefunguje."
Kontrola stavu je len taký spôsob, ako zistiť z pohľadu používateľa, že funguje. Jedna z metód. Povedzme to takto. Z pohľadu Kubernetes je to aj spôsob, ako pochopiť, kedy sa aplikácia spúšťa, pretože chápeme, že je rozdiel medzi tým, kedy bol kontajner spustený, vytvorený a spustený a kedy bola aplikácia spustená priamo v tomto kontajneri. Pretože ak si vezmeme nejakú priemernú java aplikáciu a pokúsime sa ju spustiť v doku, tak na štyridsať sekúnd, či dokonca minútu, či dokonca desať, môže začať v pohode. V tomto prípade môžete aspoň zaklopať na jeho porty, nebude tam odpovedať, to znamená, že ešte nie je pripravený na príjem prevádzky.
Opäť pomocou kontroly stavu a pomocou toho, že sa tu obraciame, môžeme v Kubernetes pochopiť, že v aplikácii nevzrástol len kontajner, ale spustila sa aj samotná aplikácia, ktorá už reaguje na zdravotnú kontrolu, čo znamená, že tam môžeme posielať premávku.
To, o čom teraz hovorím, sa nazýva testy pripravenosti/životnosti v rámci Kubernetes; podľa toho sú naše testy pripravenosti zodpovedné za dostupnosť aplikácie pri vyvažovaní. To znamená, že ak sa v aplikácii vykonajú testy pripravenosti, tak je všetko v poriadku, návštevnosť klientov smeruje do aplikácie. Ak sa nevykonajú testy pripravenosti, potom sa aplikácia jednoducho nezúčastňuje, táto konkrétna inštancia sa nezúčastňuje na vyvažovaní, je odstránená z vyvažovania a klientsky prenos netečie. V súlade s tým sú potrebné testy Liveness v rámci Kubernetes, takže ak sa aplikácia zasekne, môže sa reštartovať. Ak test životnosti nefunguje pre aplikáciu, ktorá je deklarovaná v Kubernetes, potom sa aplikácia nielen odstráni z vyváženia, ale reštartuje sa.
A tu je dôležitý bod, ktorý by som rád spomenul: z praktického hľadiska sa test pripravenosti zvyčajne používa častejšie a je častejšie potrebný ako test živosti. To znamená, že jednoducho bezmyšlienkovite deklarovať testy pripravenosti aj životnosti, pretože Kubernetes to dokáže a poďme využiť všetko, čo dokáže, nie je veľmi dobrý nápad. Vysvetlím prečo. Pretože bod číslo dva v testovaní je, že by bolo dobré skontrolovať základnú službu vo vašich zdravotných kontrolách. To znamená, že ak máte webovú aplikáciu, ktorá poskytuje nejaké informácie, ktoré zase, prirodzene, musí odniekiaľ brať. Napríklad v databáze. No, ukladá informácie, ktoré prichádzajú do tohto REST API, do rovnakej databázy. Potom, ak váš healthcheck odpovie jednoducho ako kontaktovaný slashhealth, aplikácia povie „200, dobre, všetko je v poriadku“ a zároveň databáza vašej aplikácie je neprístupná a aplikácia healthcheck povie „200, dobre, všetko je v poriadku. “ - Toto je zlá kontrola stavu. Takto by to fungovať nemalo.
Teda vaša žiadosť, keď k nej príde žiadosť /health, neodpovedá len „200, ok“, najskôr prejde napríklad do databázy, pokúsi sa k nej pripojiť, urobí tam niečo úplne základné, napríklad vybrať jednu, len skontroluje, či je pripojenie v databázy a môžete sa dotazovať na databázu. Ak to všetko bolo úspešné, odpoveď je "200, ok." Ak sa nepodarí, vypíše, že došlo k chybe, databáza je nedostupná.
Preto sa v tejto súvislosti opäť vraciam k testom pripravenosti/životnosti - prečo s najväčšou pravdepodobnosťou potrebujete test pripravenosti, ale test životaschopnosti je otázny. Pretože ak opíšete zdravotné kontroly presne tak, ako som práve povedal, potom sa ukáže, že v inštancii nie je k dispozíciiв или со всех instancenapríklad v databáze. Keď ste vyhlásili test pripravenosti, naše zdravotné kontroly začali zlyhávať a podľa toho všetky aplikácie, z ktorých nie je databáza prístupná, sú jednoducho vypnuté z balansovania a v podstate „visia“ len v zanedbanom stave a čakajú, kým ich databázy práca.
Ak sme vyhlásili test životnosti, tak si predstavte, naša databáza sa pokazila a vo vašom Kubernetes sa polovica všetkého začne reštartovať, pretože test životnosti zlyhá. To znamená, že musíte reštartovať. To vôbec nie je to, čo chceš, dokonca som mal osobnú skúsenosť z praxe. Mali sme chatovaciu aplikáciu, ktorá bola napísaná v JS a vložená do databázy Mongo. A problém bol v tom, že to bolo na začiatku mojej práce s Kubernetes, popísali sme pripravenosť, živosť testov na princípe, že Kubernetes to dokáže, tak to využijeme. V súlade s tým sa v určitom bode Mongo stal trochu „tupým“ a vzorka začala zlyhávať. V súlade s tým, podľa testu dažďa, struky začali „zabíjať“.
Ako viete, keď sú „zabití“, ide o chat, to znamená, že na ňom visí veľa spojení od klientov. Sú tiež „zabití“ - nie, nie klienti, iba spojenia - nie všetci naraz, a pretože nie sú zabití v rovnakom čase, niektorí skôr, niektorí neskôr, nezačnú v rovnakom čase čas. Navyše, štandardne náhodne, nemôžeme predpovedať s presnosťou na milisekundy zakaždým čas spustenia aplikácie, takže to robia jeden prípad za druhým. Jeden infospot stúpa, pridáva sa k bilancovaniu, prídu tam všetci klienti, nevydrží takú záťaž, lebo je sám, a zhruba povedané, pracuje ich tam tucet a klesá. Ďalší stúpa, celý náklad je na ňom, aj padá. No, tieto pády len pokračujú v kaskáde. Nakoniec, ako sa to vyriešilo - museli sme striktne zastaviť návštevnosť používateľov tejto aplikácie, nechať všetky inštancie stúpnuť a potom spustiť všetku návštevnosť používateľov naraz, aby sa už rozdelila medzi všetkých desať inštancií.
Ak by nebol ohlásený tento test živosti, ktorý by to všetko prinútil reštartovať, aplikácia by to zvládla v pohode. Ale všetko z bilancovania je pre nás zakázané, pretože databázy sú nedostupné a všetci používatelia „odpadli“. Potom, keď bude táto databáza k dispozícii, všetko je zahrnuté do vyváženia, ale aplikácie sa nemusia znova spúšťať a nie je potrebné strácať čas a zdroje. Všetci sú už tu, sú pripravení na premávku, takže premávka sa len otvára, všetko je v poriadku - aplikácia je na mieste, všetko funguje ďalej.
Testy pripravenosti a živosti sú teda rôzne, ba čo viac, teoreticky môžete robiť rôzne zdravotné kontroly, napríklad jeden typ rádiusov, jeden typ živej a kontrolovať rôzne veci. Počas testov pripravenosti skontrolujte svoje backendy. A napríklad pri teste životnosti nekontrolujete z toho hľadiska, že test životnosti je vo všeobecnosti iba reagujúcou aplikáciou, ak je vôbec schopná reagovať.
Pretože skúška živosti je vo všeobecnosti vtedy, keď sme „uviazli“. Začala sa nekonečná slučka alebo niečo iné – a žiadne ďalšie požiadavky sa nespracúvajú. Preto má zmysel ich dokonca oddeliť – a implementovať do nich inú logiku.
Čo sa týka toho, čo potrebujete odpovedať, keď máte test, keď robíte zdravotné kontroly. Je to naozaj bolesť. Tí, ktorí to poznajú, sa asi zasmejú – ale vážne, v živote som videl služby, ktoré v 200 % prípadov odpovedajú „XNUMX“. Teda kto je úspešný. Ale zároveň v tele odpovede píšu „taká a taká chyba“.
To znamená, že k vám príde stav odpovede - všetko je úspešné. Zároveň však musíte telo analyzovať, pretože telo hovorí „prepáčte, žiadosť skončila chybou“ a toto je len realita. Videl som to v reálnom živote.
A aby to niektorým ľuďom neprišlo vtipné a iným to veľmi bolestivé, stále sa oplatí dodržiavať jednoduché pravidlo. Pri zdravotných kontrolách a zásadne pri práci s webovými aplikáciami.
Ak všetko prebehlo dobre, odpovedzte odpoveďou dvesto. V zásade vám bude vyhovovať akákoľvek dvestotinová odpoveď. Ak veľmi dobre čítate ragsy a viete, že niektoré stavy odpovedí sa líšia od ostatných, odpovedzte vhodnými: 204, 5, 10, 15, čokoľvek. Ak to nie je veľmi dobré, potom len „dva nula nula“. Ak ide všetko zle a kontrola zdravotného stavu nereaguje, odpovedzte ľubovoľnou päťstotinou. Opäť, ak rozumiete tomu, ako reagovať, ako sa rôzne stavy odpovedí navzájom líšia. Ak nerozumiete, potom 502 je vaša možnosť reagovať na zdravotné kontroly, ak sa niečo pokazí.
Toto je ďalší bod, chcem sa vrátiť trochu o kontrole základných služieb. Ak napríklad začnete kontrolovať všetky základné služby, ktoré stoja za vašou aplikáciou – všetko vo všeobecnosti. Čo získame z pohľadu architektúry mikroslužieb, máme taký koncept ako „low coupling“ – teda keď sú vaše služby na sebe minimálne závislé. Ak jeden z nich zlyhá, všetky ostatné bez tejto funkcie budú jednoducho fungovať ďalej. Niektoré funkcie jednoducho nefungujú. Ak teda spojíte všetky zdravotné kontroly na seba, skončíte s tým, že jedna vec v infraštruktúre zlyhá, a keďže táto padla, začnú zlyhávať aj všetky zdravotné kontroly všetkých služieb – a vo všeobecnosti existuje viac infraštruktúry pre celá architektúra mikroslužieb č. Všetko tam zotmelo.
Preto to chcem ešte raz zopakovať, že si treba skontrolovať podkladové služby, tie, bez ktorých vaša aplikácia v sto percentách prípadov nedokáže robiť svoju prácu. To znamená, že je logické, že ak máte REST API, cez ktoré používateľ ukladá do databázy alebo získava z databázy, tak pri absencii databázy nemôžete zaručiť prácu s vašimi používateľmi.
Ale ak sú vaši používatelia, keď ich vytiahnete z databázy, dodatočne obohatení o nejaké ďalšie metadáta, z iného backendu, ktoré zadáte pred odoslaním odpovede na frontend – a tento backend nie je dostupný, znamená to, že dáte svoje odpoveď bez akejkoľvek časti metadát.
Ďalej tu máme jeden z bolestivých problémov pri spúšťaní aplikácií.
V skutočnosti to neplatí len pre Kubernetes a vo všeobecnosti, stalo sa, že kultúra nejakého masového vývoja a najmä DevOps sa začali šíriť približne v rovnakom čase ako Kubernetes. Celkovo sa preto ukazuje, že musíte svoju aplikáciu elegantne vypnúť bez Kubernetes. Aj pred Kubernetes to ľudia robili, ale s príchodom Kubernetes sme sa o tom začali masovo rozprávať.
Pôvabné vypnutie
Vo všeobecnosti, čo je to Graceful Shutdown a prečo je to potrebné? To je o tom, keď vaša aplikácia z nejakého dôvodu zlyhá, musíte to urobiť app stop - alebo prijmete napríklad signál z operačného systému, vaša aplikácia mu musí rozumieť a niečo s tým urobiť. Najhorším prípadom je, samozrejme, keď vaša aplikácia dostane SIGTERM a znie ako „SIGTERM, vydržme, pracujme, nerobme nič“. Toto je vyslovene zlá možnosť.
Takmer rovnako zlá možnosť je, keď vaša aplikácia dostane SIGTERM a je ako „povedali segterm, to znamená, že končíme, nevidel som, nepoznám žiadne požiadavky používateľov, neviem aký druh žiadosti, na ktorých práve pracujem, povedali SIGTERM, to znamená, že končíme “ Toto je tiež zlá možnosť.
Ktorá možnosť je dobrá? Prvým bodom je brať do úvahy dokončenie operácií. Dobrou možnosťou je, aby váš server stále bral do úvahy, čo urobí, ak prijme SIGTERM.
SIGTERM je mäkké vypnutie, je špeciálne navrhnuté, dá sa zachytiť na úrovni kódu, dá sa spracovať, povedzme, že teraz, počkajte, najprv dokončíme prácu, ktorú máme, potom skončíme.
Z pohľadu Kubernetes to vyzerá takto. Keď povieme podu, ktorý je spustený v klastri Kubernetes, „zastav sa, choď preč“, alebo sme reštartovaní, alebo dôjde k aktualizácii, keď Kubernetes znova vytvorí moduly, Kubernetes odošle do podu rovnakú správu SIGTERM, čaká na nejaký čas a , to je čas, ktorý čaká, je tiež nakonfigurovaný, v diplomoch je taký špeciálny parameter a volá sa Graceful ShutdownTimeout. Ako viete, nenazýva sa to tak nadarmo a nie nadarmo o tom teraz hovoríme.
Tam môžeme konkrétne povedať, ako dlho musíme čakať medzi odoslaním SIGTERM do aplikácie a keď pochopíme, že sa zdá, že sa aplikácia pre niečo zbláznila alebo sa „zasekla“ a nechystá sa skončiť – a my musíme pošlite to SIGKILL, to znamená, že tvrdo dokončite svoju prácu. To znamená, že máme spustený nejaký druh démona, ktorý spracováva operácie. Chápeme, že v priemere naše operácie, na ktorých démon pracuje, netrvajú naraz dlhšie ako 30 sekúnd. V súlade s tým, keď príde SIGTERM, chápeme, že náš démon môže skončiť maximálne 30 sekúnd po SIGTERM. Napíšeme to napríklad 45 sekúnd pre každý prípad a povieme, že SIGTERM. Potom počkáme 45 sekúnd. Teoreticky by počas tejto doby mal démon dokončiť svoju prácu a skončiť sám. Ale ak to zrazu nejde, znamená to, že sa to s najväčšou pravdepodobnosťou zaseklo – naše požiadavky už nespracováva normálne. A za 45 sekúnd ho môžete bezpečne pribiť.
A tu vlastne možno brať do úvahy dokonca 2 aspekty. Po prvé, pochopte, že ak ste dostali požiadavku, začali ste s ňou nejako pracovať a nedali ste používateľovi odpoveď, ale dostali ste napríklad SIGTERM. Má zmysel ho spresniť a dať používateľovi odpoveď. V tomto smere ide o bod číslo jeden. Bod číslo dva tu je, že ak napíšete svoju vlastnú aplikáciu, vo všeobecnosti postavíte architektúru tak, že dostanete požiadavku na vašu aplikáciu, potom začnete s nejakou prácou, začnete odniekiaľ sťahovať súbory, sťahovať databázu a podobne. - To. Vo všeobecnosti váš používateľ, vaša požiadavka visí pol hodiny a čaká, kým mu odpoviete - potom s najväčšou pravdepodobnosťou musíte pracovať na architektúre. To znamená, že berte do úvahy aj zdravý rozum, že ak sú vaše operácie krátke, potom má zmysel ignorovať SIGTERM a upraviť ho. Ak sú vaše operácie dlhé, potom v tomto prípade nemá zmysel ignorovať SIGTERM. Má zmysel prepracovať architektúru, aby sa predišlo takýmto dlhým operáciám. Aby sa používatelia len tak nezdržiavali a nečakali. Neviem, urobte tam nejaký websocket, urobte reverzné háky, ktoré váš server už pošle klientovi, čokoľvek iné, ale nenúťte používateľa, aby visel pol hodiny a počkajte na reláciu, kým sa odpovedz mu. Pretože je nepredvídateľné, kde sa môže zlomiť.
Keď sa vaša aplikácia ukončí, mali by ste poskytnúť nejaký vhodný ukončovací kód. To znamená, že ak bola vaša aplikácia požiadaná o zatvorenie, zastavenie a dokázala sa normálne zastaviť, nemusíte vracať nejaký výstupný kód 1,5,255 atď. Čokoľvek, čo nie je nulový kód, aspoň v systémoch Linux, o tom som si istý, sa považuje za neúspešné. To znamená, že sa má za to, že vaša žiadosť v tomto prípade skončila chybou. V súlade s tým, priateľským spôsobom, ak je vaša žiadosť dokončená bez chyby, na výstupe poviete 0. Ak vaša aplikácia z nejakého dôvodu zlyhá, vo výstupe poviete, že nie je 0. A s týmito informáciami môžete pracovať.
A posledná možnosť. Je zlé, keď váš používateľ odošle požiadavku a zasekne sa na pol hodiny, kým ju spracujete. Ale vo všeobecnosti by som tiež rád povedal o tom, čo sa vo všeobecnosti oplatí zo strany klienta. Nezáleží na tom, či máte mobilnú aplikáciu, front-end atď. Je potrebné vziať do úvahy, že vo všeobecnosti môže byť relácia používateľa ukončená, môže sa stať čokoľvek. Žiadosť môže byť odoslaná, napríklad nedostatočne spracovaná a nevráti sa žiadna odpoveď. Váš frontend alebo vaša mobilná aplikácia – povedzme si to všeobecne akékoľvek frontend – by to mali brať do úvahy. Ak pracujete s websockets, je to vo všeobecnosti najhoršia bolesť, akú som kedy mal.
Keď to vývojári niektorých bežných chatov nevedia, ukázalo sa, že websocket sa môže zlomiť. Pre nich, keď sa niečo stane na serveri proxy, jednoducho zmeníme konfiguráciu a vykoná sa opätovné načítanie. Prirodzene, všetky dlhotrvajúce relácie sú v tomto prípade roztrhané. Pribehnú k nám vývojári a hovoria: „Chalani, čo to robíte, chat sa pokazil všetkým našim klientom!“ Hovoríme im: „Čo to robíte? Nemôžu sa vaši klienti znova pripojiť? Hovoria: "Nie, potrebujeme, aby sa relácie neroztrhali." To je skrátka vlastne nezmysel. Je potrebné vziať do úvahy stranu klienta. Najmä, ako hovorím, pri dlhotrvajúcich reláciách, ako sú webové zásuvky, sa to môže zlomiť a bez povšimnutia používateľa musíte mať možnosť preinštalovať takéto relácie. A potom je všetko dokonalé.
zdroje
V skutočnosti vám tu poviem jeden priamy príbeh. Opäť z reálneho života. Najhoršia vec, akú som kedy počul o zdrojoch.
Zdroje v tomto prípade mám na mysli nejaké požiadavky, limity, ktoré môžete umiestniť na moduly vo svojich klastroch Kubernetes. Najzábavnejšia vec, ktorú som počul od vývojára... Jeden z mojich kolegov vývojárov na predchádzajúcom pracovisku raz povedal: „Moja aplikácia sa nespustí v klastri.“ Pozrel som sa, aby som zistil, že sa to nespúšťa, ale buď sa to nezmestilo do zdrojov, alebo nastavili veľmi malé limity. Aplikácia sa skrátka nedá spustiť kvôli zdrojom. Hovorím: „Nezačne sa to kvôli zdrojom, vy sa rozhodnete, koľko potrebujete, a nastavíte primeranú hodnotu.“ Hovorí: "Aké zdroje?" Začal som mu vysvetľovať, že treba nastaviť Kubernetes, limity na požiadavky a bla, bla, bla. Muž počúval päť minút, prikývol a povedal: „Prišiel som sem pracovať ako vývojár, nechcem vedieť nič o žiadnych zdrojoch. Prišiel som sem napísať kód a to je všetko." Je to smutné. To je z pohľadu vývojára veľmi smutný koncept. Najmä v modernom svete, takpovediac, progresívnych devops.
Prečo sú vôbec potrebné zdroje? V Kubernetes sú 2 typy zdrojov. Niektoré sa nazývajú požiadavky, iné sa nazývajú limity. Pod prostriedkami pochopíme, že v podstate vždy existujú len dve základné obmedzenia. To znamená časové limity CPU a limity RAM pre kontajner spustený v Kubernetes.
Limit stanovuje horný limit toho, ako možno zdroj použiť vo vašej aplikácii. To znamená, že ak v limitoch poviete 1 GB RAM, vaša aplikácia nebude môcť použiť viac ako 1 GB RAM. A ak to zrazu bude chcieť a pokúsi sa to urobiť, potom príde proces nazývaný oom killer, ktorý nemá pamäť, to znamená, že vašu aplikáciu zabije – to znamená, že sa jednoducho reštartuje. Aplikácie sa nereštartujú na základe CPU. Pokiaľ ide o CPU, ak sa aplikácia snaží používať veľa, viac ako je uvedené v limitoch, CPU bude jednoducho prísne vybrané. To nevedie k reštartom. Toto je hranica – toto je horná hranica.
A je tu prosba. Požiadavka je spôsob, akým Kubernetes chápe, ako sú uzly vo vašom klastri Kubernetes vyplnené aplikáciami. To znamená, že žiadosť je akýmsi potvrdením vašej aplikácie. Hovorí to, čo chcem použiť: „Chcel by som, aby ste mi rezervovali toľko CPU a toľko pamäte.“ Taká jednoduchá analógia. Čo ak máme uzol, ktorý má, neviem, celkom 8 CPU. A tam príde modul, ktorého požiadavky hovoria o 1 CPU, čo znamená, že uzlu zostáva 7 CPU. To znamená, že akonáhle do tohto uzla dorazí 8 modulov, z ktorých každý má vo svojich požiadavkách 1 CPU, uzol, ako keby z pohľadu Kubernetes, došiel CPU a ďalšie moduly s požiadavkami sa nedajú dostať. spustený na tomto uzle. Ak sa všetkým uzlom minie CPU, tak Kubernetes začne tvrdiť, že v klastri nie sú žiadne vhodné uzly na spustenie vašich modulov, pretože CPU sa minul.
Prečo sú potrebné žiadosti a prečo bez žiadostí si myslím, že v Kubernetes nie je potrebné nič spúšťať? Predstavme si hypotetickú situáciu. Svoju aplikáciu spustíte bez požiadaviek, Kubernetes nevie, koľko z toho máte, na aké uzly to môžete natlačiť. No tlačí, tlačí, tlačí na uzly. V určitom okamihu začnete získavať návštevnosť vašej aplikácie. A jedna z aplikácií zrazu začne využívať zdroje až do limitov, ktoré má podľa limitov. Ukazuje sa, že v blízkosti je ďalšia aplikácia a tiež potrebuje zdroje. Uzol skutočne začne fyzicky dochádzať zdroje, napríklad OP. Uzol v skutočnosti začne fyzicky dochádzať zdroje, napríklad pamäť s náhodným prístupom (RAM). Keď sa uzlu vybije energia, najskôr prestane reagovať docker, potom cubelet a potom OS. Jednoducho upadnú do bezvedomia a VŠETKO vám definitívne prestane fungovať. To znamená, že to povedie k zaseknutiu vášho uzla a budete ho musieť reštartovať. Situácia skrátka nie je veľmi dobrá.
A keď máte požiadavky, limity sa veľmi nelíšia, aspoň nie mnohonásobne viac ako limity alebo požiadavky, potom môžete mať také normálne, racionálne napĺňanie aplikácií naprieč uzlami klastrov Kubernetes. Zároveň si Kubernetes približne uvedomuje, koľko z toho, čo kam dáva, koľko z toho sa kde používa. To znamená, že je to len taká chvíľa. Je dôležité tomu rozumieť. A je dôležité kontrolovať, či je to uvedené.
Ukladanie údajov
Náš ďalší bod je o ukladaní údajov. Čo s nimi robiť a vo všeobecnosti, čo robiť s vytrvalosťou v Kubernetes?
Myslím, že opäť v rámci nášho , bola tu téma o databáze v Kubernetes. A zdá sa mi, že dokonca zhruba viem, čo vám povedali vaši kolegovia na otázku: „Je možné spustiť databázu v Kubernetes?“ Z nejakého dôvodu sa mi zdá, že vám vaši kolegovia mali povedať, že ak sa pýtate, či je možné spustiť databázu v Kubernetes, tak je to nemožné.
Logika je tu jednoduchá. Len pre prípad, vysvetlím to ešte raz, ak ste naozaj skvelý človek, ktorý dokáže vybudovať systém distribuovaného sieťového úložiska, ktorý je pomerne odolný voči chybám, pochopte, ako do tohto prípadu vložiť databázu, ako by mal fungovať cloud natívny v kontajneroch v databáze všeobecne. S najväčšou pravdepodobnosťou nemáte žiadne otázky o tom, ako ho spustiť. Ak máte takúto otázku a chcete sa uistiť, že sa to všetko rozvinie a zostane vo výrobe až do smrti a nikdy nespadne, potom sa to nestane. S týmto prístupom si zaručene vystrelíte do nohy. Takže radšej nie.
Čo máme robiť s dátami, ktoré by si naša aplikácia chcela uložiť, s niektorými obrázkami, ktoré používatelia nahrávajú, s niektorými vecami, ktoré naša aplikácia generuje počas prevádzky, napríklad pri spustení? Čo s nimi robiť v Kubernetes?
Vo všeobecnosti, v ideálnom prípade, áno, samozrejme, Kubernetes je veľmi dobre navrhnutý a vo všeobecnosti bol pôvodne koncipovaný pre aplikácie bez stavu. Teda pre tie aplikácie, ktoré vôbec neukladajú informácie. Toto je ideálne.
Ale, samozrejme, nie vždy existuje ideálna možnosť. No a čo? Prvým a najjednoduchším bodom je vziať si nejaký druh S3, len nie podomácky vyrobený, o ktorom je tiež nejasné, ako to funguje, ale od nejakého poskytovateľa. Dobrý, normálny poskytovateľ – a naučte svoju aplikáciu používať S3. To znamená, že keď chce váš používateľ nahrať súbor, povedzte „tu, prosím, nahrajte ho do S3“. Keď ho bude chcieť prijať, povedzte: „Tu je odkaz na S3 späť a vezmite si ho odtiaľto.“ Toto je ideálne.
Ak zrazu z nejakého dôvodu táto ideálna možnosť nevyhovuje, máte aplikáciu, ktorú ste nenapísali, nevyvíjate, alebo je to nejaké hrozné dedičstvo, nemôže používať protokol S3, ale musí pracovať s lokálnymi adresármi v lokálne priečinky. Vezmite niečo viac-menej jednoduché, nasaďte Kubernetes. To znamená, že okamžite šermovať Cepha kvôli nejakým minimálnym úlohám, zdá sa mi, je zlý nápad. Pretože Ceph je, samozrejme, dobrý a módny. Ale ak naozaj nerozumiete tomu, čo robíte, potom akonáhle niečo nasadíte na Ceph, veľmi ľahko a jednoducho to odtiaľ už nikdy nedostanete. Pretože, ako viete, Ceph ukladá údaje vo svojom klastri v binárnej forme a nie vo forme jednoduchých súborov. Preto, ak sa náhle zhluk Ceph pokazí, potom je úplná a vysoká pravdepodobnosť, že odtiaľ svoje údaje už nikdy nedostanete.
Budeme mať kurz o Cephovi, môžeš .
Preto je lepšie urobiť niečo jednoduché, ako je server NFS. Kubernetes s nimi vie pracovať, môžete si pripojiť adresár pod NFS server – vaša aplikácia je ako lokálny adresár. Zároveň, prirodzene, musíte pochopiť, že opäť musíte niečo urobiť so svojím NFS, musíte pochopiť, že niekedy sa môže stať nedostupným a zvážiť otázku, čo budete robiť v tomto prípade. Možno by to malo byť zálohované niekde na samostatnom počítači.
Ďalším bodom, o ktorom som hovoril, je, čo robiť, ak vaša aplikácia počas prevádzky generuje nejaké súbory. Napríklad pri spustení vygeneruje nejaký statický súbor, ktorý je založený na nejakých informáciách, ktoré aplikácia dostane až v čase spustenia. Aký moment. Ak takýchto údajov nie je veľa, nemusíte sa vôbec obťažovať, stačí si nainštalovať túto aplikáciu a pracovať. Jediná otázka je čo, pozri. Veľmi často všemožné staršie systémy, ako je WordPress a tak ďalej, najmä s upravenými nejakými šikovnými pluginmi, šikovnými PHP vývojármi, často vedia, ako to urobiť tak, že si vygenerujú nejaký súbor pre seba. Podľa toho jeden generuje jeden súbor, druhý generuje druhý súbor. Sú rôzne. Vyvažovanie prebieha v klastri Kubernetes klientov jednoducho náhodou. V súlade s tým sa ukazuje, že napríklad nevedia, ako spolupracovať. Jedna poskytuje jednu informáciu, druhá dáva používateľovi ďalšiu informáciu. To je niečo, čomu by ste sa mali vyhnúť. To znamená, že v Kubernetes je zaručené, že všetko, čo spustíte, bude fungovať vo viacerých inštanciách. Pretože Kubernetes je pohyblivá vec. V súlade s tým môže pohybovať čímkoľvek, kedykoľvek chce, bez toho, aby sa kohokoľvek pýtal. Preto s tým treba rátať. Všetko spustené v jednom prípade skôr či neskôr zlyhá. Čím viac rezervácií máte, tým lepšie. Ale opäť hovorím, ak máte niekoľko takýchto súborov, môžete ich dať priamo pod seba, vážia malé množstvo. Ak je ich trochu viac, pravdepodobne by ste ich nemali tlačiť do nádoby.
Poradil by som, že v Kubernetes je taká úžasná vec, môžete použiť hlasitosť. Ide najmä o zväzok typu prázdny riad. To znamená, že Kubernetes automaticky vytvorí adresár vo svojich adresároch služieb na serveri, kde ste začali. A dá vám ho, aby ste ho mohli použiť. Je tu len jeden dôležitý bod. To znamená, že vaše údaje nebudú uložené vo vnútri kontajnera, ale skôr na hostiteľovi, na ktorom používate. Kubernetes navyše dokáže takéto prázdne priečinky ovládať pri normálnej konfigurácii a je schopný kontrolovať ich maximálnu veľkosť a nedovoliť jej prekročenie. Jediným bodom je, že to, čo ste napísali do prázdneho adresára, sa počas reštartovania modulu nestratí. To znamená, že ak váš modul omylom spadne a znova sa zdvihne, informácie v prázdnom adresári nikam nejdú. Môže ho použiť znova na novom začiatku – a to je dobre. Ak váš modul niekde odíde, prirodzene odíde bez údajov. To znamená, že akonáhle zmizne modul z uzla, kde bol spustený s prázdnym adresárom, prázdny adresár sa vymaže.
Čo je ešte dobré na prázdnom adresári? Môže sa napríklad použiť ako vyrovnávacia pamäť. Predstavme si, že naša aplikácia niečo generuje za chodu, dáva to používateľom a robí to dlho. Aplikácia ho preto napríklad generuje a dáva používateľom a zároveň ho niekam ukladá, aby nabudúce, keď si používateľ príde pre to isté, bolo rýchlejšie dať to hneď vygenerované. Kubernetes môže požiadať o vytvorenie prázdneho adresára v pamäti. Vaše vyrovnávacie pamäte teda môžu vo všeobecnosti pracovať rýchlosťou blesku – pokiaľ ide o rýchlosť prístupu na disk. To znamená, že máte v pamäti prázdny adresár, v OS je uložený v pamäti, ale pre vás, pre používateľa vo vnútri modulu, to vyzerá len ako lokálny adresár. Nepotrebujete aplikáciu, aby ste konkrétne učili nejakú mágiu. Stačí priamo vziať a vložiť súbor do adresára, ale v skutočnosti do pamäte operačného systému. Toto je tiež veľmi pohodlná funkcia, pokiaľ ide o Kubernetes.
Aké problémy má Minio? Hlavným problémom Minia je, že na to, aby táto vec fungovala, musí niekde bežať a musí tam byť nejaký súborový systém, teda úložisko. A tu sa stretávame s rovnakými problémami, aké má Ceph. To znamená, že Minio musí niekde ukladať svoje súbory. Je to jednoducho HTTP rozhranie pre vaše súbory. Okrem toho je funkčnosť jednoznačne horšia ako u Amazon S3. Predtým nebol schopný správne autorizovať používateľa. Teraz, pokiaľ viem, už dokáže vytvárať vedrá s rôznymi oprávneniami, ale opäť sa mi zdá, že hlavným problémom je takpovediac minimálne základný úložný systém.
Ako Empty dir v pamäti ovplyvňuje limity? Nijakým spôsobom neovplyvňuje limity. Leží v pamäti hostiteľa a nie v pamäti vášho kontajnera. To znamená, že váš kontajner nevidí prázdny adresár v pamäti ako súčasť svojej obsadenej pamäte. Hostiteľ to vidí. V súlade s tým áno, z pohľadu kubernetes, keď to začnete používať, bolo by dobré pochopiť, že časť svojej pamäte venujete prázdnemu adresáru. A podľa toho pochopte, že pamäť sa môže minúť nielen kvôli aplikáciám, ale aj kvôli tomu, že niekto píše do týchto prázdnych adresárov.
Oblačnosť
A posledná podtéma je to, čo je Cloudnative. Prečo je to potrebné? Oblačnosť a pod.
Teda tie aplikácie, ktoré sú schopné a napísané tak, aby fungovali v modernej cloudovej infraštruktúre. Ale v skutočnosti má Cloudnative ešte jeden takýto aspekt. Že nejde len o aplikáciu, ktorá zohľadňuje všetky požiadavky modernej cloudovej infraštruktúry, ale vie s touto modernou cloudovou infraštruktúrou aj pracovať, využite výhody a nevýhody toho, že v týchto cloudoch funguje. Nepracujte len cez palubu a nepracujte v cloude, ale využite výhody práce v cloude.
Zoberme si Kubernetes ako príklad. Vaša aplikácia beží v Kubernetes. Vaša aplikácia môže vždy, alebo skôr správcovia vašej aplikácie, vždy vytvoriť servisný účet. To znamená, že účet na autorizáciu v samotnom Kubernetes na jeho serveri. Pridajte tam nejaké práva, ktoré potrebujeme. A môžete pristupovať ku Kubernetes z vašej aplikácie. Čo môžete takto urobiť? Napríklad z aplikácie získajte údaje o tom, kde sa nachádzajú vaše ďalšie aplikácie, iné podobné inštancie, a spolu sa nejakým spôsobom zoskupte na Kubernetes, ak je to potrebné.
Opäť sme mali nedávno doslova prípad. Máme jedného kontrolóra, ktorý sleduje front. A keď sa v tomto fronte objavia nejaké nové úlohy, prejde do Kubernetes – a vo vnútri Kubernetes vytvorí nový modul. Dá tomuto podu nejakú novú úlohu av rámci tohto podu vykoná úlohu, odošle odpoveď samotnému ovládaču a ovládač potom s touto informáciou niečo urobí. Napríklad sčíta databázu. To je opäť plus toho, že naša aplikácia beží v Kubernetes. Samotnú vstavanú funkcionalitu Kubernetes môžeme využiť na to, aby sme nejako rozšírili a spríjemnili funkčnosť našej aplikácie. To znamená, neskrývajte nejaké kúzlo o tom, ako spustiť aplikáciu, ako spustiť pracovníka. V Kubernetes jednoducho odošlete žiadosť v aplikácii, ak je aplikácia napísaná v Pythone.
To isté platí, ak prekročíme Kubernetes. Niekde nám bežia naše Kubernetes – je dobré, ak sú v nejakom cloude. Opäť môžeme využiť a dokonca by sme podľa mňa mali využívať možnosti samotného cloudu, kde bežíme. Od elementárnych vecí, ktoré nám cloud poskytuje. Balancing, to znamená, že môžeme vytvárať cloud balancery a používať ich. To je priama výhoda toho, čo môžeme využiť. Pretože cloud balancing nás po prvé jednoducho hlúpo zbavuje zodpovednosti za to, ako to funguje, ako je to nakonfigurované. Navyše je to veľmi pohodlné, pretože bežné Kubernetes sa dajú integrovať s cloudmi.
To isté platí pre škálovanie. Bežné Kubernetes sa môžu integrovať s poskytovateľmi cloudu. Vie, ako pochopiť, že ak sa klastri vyčerpajú uzly, to znamená, že sa vyčerpal priestor uzlov, musíte pridať - Kubernetes sám pridá nové uzly do vášho klastra a začne na nich spúšťať moduly. To znamená, že keď príde vaša záťaž, počet ohnísk sa začne zvyšovať. Keď sa uzly v klastri pre tieto moduly minú, Kubernetes spustí nové uzly, a preto sa počet modulov môže stále zvyšovať. A je to veľmi pohodlné. Toto je priama príležitosť na škálovanie klastra za chodu. Nie veľmi rýchlo, v tom zmysle, že to nie je sekunda, je to skôr minúta na pridanie nových uzlov.
Ale z mojej skúsenosti je to opäť tá najúžasnejšia vec, akú som kedy videl. Keď sa klaster Cloudnative zmenil na základe denného času. Išlo o backendovú službu, ktorú využívali ľudia v back office. To znamená, že prídu do práce o 9:8, začnú sa prihlasovať do systému a podľa toho sa klaster Cloudnative, kde to všetko beží, začne zväčšovať a spúšťať nové moduly, aby s aplikáciou mohol pracovať každý, kto príde do práce. Keď odídu z práce o 6:30 alebo XNUMX:XNUMX, klastre Kubernetes si všimnú, že nikto už aplikáciu nepoužíva a začnú sa zmenšovať. Garantovaná je úspora až XNUMX percent. V Amazone to v tom čase fungovalo, v Rusku vtedy nebol nikto, kto by to dokázal tak dobre.
Poviem vám rovno, úspory sú 30 percent jednoducho preto, že používame Kubernetes a využívame možnosti cloudu. Teraz sa to dá urobiť v Rusku. Samozrejme, nebudem nikomu robiť reklamu, ale povedzme, že existujú poskytovatelia, ktorí to dokážu a poskytnú to hneď po vybalení pomocou tlačidla.
Je tu ešte jeden posledný bod, na ktorý by som vás chcel upozorniť. Aby vaša aplikácia, vaša infraštruktúra bola Cloudnative, má zmysel konečne začať prispôsobovať prístup nazývaný Infrastructure as a Code.To znamená, že vaša aplikácia, respektíve vaša infraštruktúra potrebuje presne to isté ako kód Popíšte svoj vašej obchodnej logiky vo forme kódu. A pracujte s ním ako s kódom, teda otestujte ho, rozviňte, uložte do git, aplikujte naň CICD.
A to je presne to, čo vám po prvé umožňuje mať vždy kontrolu nad vašou infraštruktúrou, aby ste vždy pochopili, v akom stave sa nachádza. Po druhé, vyhnite sa manuálnym operáciám, ktoré spôsobujú chyby. Po tretie, jednoducho sa vyhnite tomu, čo sa nazýva fluktuácia, keď neustále potrebujete vykonávať rovnaké manuálne úlohy. Po štvrté, umožňuje vám to oveľa rýchlejšie obnoviť v prípade poruchy. V Rusku vždy, keď o tom hovorím, je vždy veľké množstvo ľudí, ktorí hovoria: „Áno, je to jasné, ale máte prístupy, skrátka nie je potrebné nič opravovať. Ale je to pravda. Ak sa vo vašej infraštruktúre niečo pokazí, potom z pohľadu Cloudnative prístupu a z pohľadu Infraštruktúry ako kódexu je to jednoduchšie, než to opraviť, ísť na server, zistiť, čo je pokazené a opraviť to. na odstránenie servera a jeho opätovné vytvorenie. A toto všetko nechám obnoviť.
Všetky tieto otázky sú podrobnejšie diskutované na . Kliknutím na odkaz sa môžete oboznámiť s programom a podmienkami. Pohodlné je, že Kubernetes môžete zvládnuť štúdiom z domu alebo prácou 1-2 hodiny denne.
Zdroj: hab.com