Dnes mám v plánu mluvit o tom, jak psát aplikace a jaké jsou požadavky na to, aby vaše aplikace dobře fungovala v Kubernetes. Aby s aplikací nebyly žádné bolesti hlavy, abyste kolem ní nemuseli vymýšlet a budovat žádné „škrábance“ – a vše funguje tak, jak si sám Kubernetes zamýšlel.
Tato přednáška je součástí "" Můžete si prohlédnout otevřené teoretické přednášky Večerní školy . Pro ty, kteří mají raději text než video, jsme připravili tento článek.
Jmenuji se Pavel Selivanov, v současné době jsem vedoucí DevOps inženýr v Mail.ru Cloud Solutions, děláme cloudy, děláme management kubernetes a tak dále. Mezi mé úkoly nyní patří pomoc při vývoji, zavádění těchto cloudů, zavádění aplikací, které píšeme, a přímý vývoj nástrojů, které poskytujeme našim uživatelům.
Dělám DevOps, myslím, poslední, pravděpodobně tři roky. Ale v zásadě dělám to, co DevOps, už asi pět let. Předtím jsem se většinou zabýval adminskými věcmi. S Kubernetes jsem začal pracovat už dávno - pravděpodobně uplynuly asi čtyři roky od doby, kdy jsem s ním začal pracovat.
Obecně jsem začal, když byl Kubernetes verze 1.3, pravděpodobně a možná 1.2 - když byl ještě v plenkách. Nyní už to není v plenkách – a je zřejmé, že na trhu je obrovská poptávka po inženýrech, kteří by chtěli Kubernetes umět. A firmy mají po takových lidech velmi vysokou poptávku. Proto se ve skutečnosti tato přednáška objevila.
Pokud mluvíme o plánu toho, o čem budu mluvit, vypadá to takto, v závorce je napsáno (TL;DR) - „příliš dlouhé; nečíst“. Moje dnešní prezentace se bude skládat z nekonečných seznamů.
Já sám vlastně nemám rád takovéto prezentace, když se dělají, ale to je takové téma, že když jsem tuto prezentaci připravoval, tak jsem prostě moc nepřišel na to, jak tyto informace jinak uspořádat.
Protože vesměs tyto informace jsou „ctrl+c, ctrl+v“, mimo jiné z naší Wiki v sekci DevOps, kde máme sepsané požadavky na vývojáře: „kluci, abychom vaši aplikaci spustili v Kubernetes, mělo by to být takhle."
Proto se prezentace ukázala jako tak velký seznam. Promiňte. Pokusím se toho říct co nejvíc, aby to pokud možno nebyla nuda.
Na co se nyní podíváme:
- to jsou za prvé protokoly (logy aplikací?), co s nimi v Kubernetes dělat, co s nimi dělat, jaké by měly být;
- co dělat s konfiguracemi v Kubernetes, jaké jsou nejlepší a nejhorší způsoby konfigurace aplikace pro Kubernetes;
- Povíme si, co jsou kontroly přístupnosti obecně, jak by měly vypadat;
- promluvme si o tom, co je to ladné vypnutí;
- mluvme znovu o zdrojích;
- Ještě jednou se dotkneme tématu ukládání dat;
- a na konci vám řeknu, co je to za pojem tato tajemná cloud-nativní aplikace. Cloudnativeness, jako přídavné jméno tohoto termínu.
Protokoly
Navrhuji začít s protokoly - s tím, kam je třeba tyto protokoly v Kubernetes strčit. Nyní jste spustili aplikaci v Kubernetes. Dřívější aplikace podle klasiky zapisovaly logy vždy někam do souboru. Špatné aplikace zapisovaly protokoly do souboru v domovském adresáři vývojáře, který aplikaci spustil. Dobré aplikace zapisovaly protokoly do souboru někde v /var/log.
V souladu s tím měli dobří administrátoři ve svých infrastrukturách nakonfigurované některé věci, které by tyto protokoly mohly rotovat - stejný rsyslog, který se na tyto protokoly dívá, a když se s nimi něco stane, je jich hodně, vytváří záložní kopie, vkládá tam protokoly , odstraní staré soubory, více než týden, šest měsíců a některé další. Teoreticky bychom měli mít opatření, aby jednoduše proto, že aplikace zapisuje protokoly, nedošel prostor na produkčních serverech (bojových serverech?). A proto se celá výroba kvůli kládám nezastavila.
Když se přesuneme do světa Kubernetes a spustíme tam to samé, první věc, které můžete věnovat pozornost, je skutečnost, že lidé, jak napsali protokoly do souboru, je nadále píší.
Ukazuje se, že pokud mluvíme o Kubernetes, tím správným místem pro zápis logů někam z docker kontejneru je jednoduše je zapisovat z aplikace do tzv. Stdout/Stderr, tedy standardních výstupních proudů operačního systému, standardní chyba výstup . Toto je nejsprávnější, nejjednodušší a nejlogičtější způsob, jak vložit logy v principu do Dockeru a konkrétně do Kubernetis. Protože pokud vaše aplikace zapisuje protokoly do Stdout/Stderr, pak je na Dockeru a doplňku Kubernetes, aby se rozhodli, co s těmito protokoly udělat. Docker ve výchozím nastavení vytvoří své speciální soubory ve formátu JSON.
Zde se nabízí otázka, co s těmito logy budete dělat dál? Nejjednodušší cesta je jasná, máme schopnost to udělat kubectl logs a podívejte se na tyto záznamy těchto „lusků“. Ale pravděpodobně to není příliš dobrá volba - s protokoly je třeba udělat něco jiného.
Teď si povíme zároveň, protože jsme se dotkli tématu kulatiny, o něčem, jak by kulatiny měly vypadat. To znamená, že to neplatí přímo pro Kubernetes, ale když začneme přemýšlet, co s logy, bylo by dobré myslet i na toto.
Potřebujeme nějaký druh nástroje, přátelským způsobem, který vezme tyto protokoly, které náš docker vloží do svých souborů, a pošle je někam. Celkově vzato obvykle spouštíme nějaký druh agenta uvnitř Kubernetes ve formě DaemonSet - sběrače protokolů, kterému je jednoduše řečeno, kde se nacházejí protokoly, které Docker shromažďuje. A tento sběratel si je prostě vezme, možná je i nějak po cestě rozebere, možná obohatí o nějaké další metainformace a nakonec je pošle někam do úschovy. Tam už jsou možné variace. Nejrozšířenější je asi Elasticsearch, kam si logy uložíte a můžete je odtud pohodlně vyvolat. Poté pomocí požadavku, například pomocí Kibana, na základě nich sestavte grafy, sestavte na základě nich upozornění a tak dále.
Nejdůležitější myšlenkou, chci to znovu zopakovat, je, že uvnitř Dockeru, zejména uvnitř Kubernetes, je ukládání vašich protokolů do souboru velmi špatný nápad.
Protože za prvé je obtížné získat protokoly uvnitř kontejneru v souboru. Nejprve musíte vstoupit do kontejneru, spustit jej a poté se podívat na protokoly. Dalším bodem je, že pokud máte logy v souboru, pak mají kontejnery většinou minimalistické prostředí a nejsou tam žádné utility, které jsou obvykle potřeba pro běžnou práci s logy. Zahrabte je, podívejte se na ně, otevřete je v textovém editoru. Dalším okamžikem je, když máme protokoly v souboru uvnitř kontejneru, pokud je tento kontejner smazán, rozumíte, protokoly zemřou spolu s ním. V souladu s tím jakýkoli restart kontejneru znamená, že neexistují žádné další protokoly. Opět špatná varianta.
A poslední bod je, že uvnitř kontejnerů máte obvykle svou aplikaci a to je vše - obvykle je to jediný běžící proces. O nějakém procesu, který by rotoval soubory s vašimi logy, se vůbec nemluví. Jakmile se začnou zapisovat protokoly do souboru, znamená to, že promiňte, začneme ztrácet produkční server. Protože je zaprvé obtížné je najít, nikdo je nesleduje a navíc je nikdo nekontroluje – soubor tedy nekonečně roste, dokud místo na serveru jednoduše nedojde. Proto znovu říkám, že přihlášení do Dockeru, zejména v Kubernetes, do souboru je špatný nápad.
Dalším bodem, zde chci znovu mluvit o tomto - protože se dotýkáme tématu protokolů, bylo by dobré si promluvit o tom, jak by protokoly měly vypadat, aby se s nimi pohodlně pracovalo. Jak jsem řekl, téma přímo nesouvisí s Kubernetes, ale velmi dobře souvisí s tématem DevOps. Na téma kultury vývoje a přátelství mezi těmito dvěma různými odděleními - Dev a Ops, aby se všichni cítili pohodlně.
To znamená, že v ideálním případě by dnes měly být protokoly psány ve formátu JSON. Pokud máte nějakou vlastní nesrozumitelnou aplikaci, která zapisuje logy v nesrozumitelných formátech, protože vkládáte nějaký tisk nebo něco podobného, pak je na čase vygooglit nějaký framework, nějaký obal, který vám umožní implementovat normální logování; povolte tam parametry protokolování v JSON, protože JSON je jednoduchý formát, jeho analýza je jednoduchá.
Pokud váš JSON nefunguje podle nějakých kritérií, nikdo neví podle čeho, tak alespoň pište protokoly ve formátu, který lze analyzovat. Zde se spíše vyplatí zamyslet se nad tím, že pokud například provozujete hromadu kontejnerů nebo jen procesů s nginx a každý má své vlastní nastavení protokolování, pak se pravděpodobně zdá, že pro vás bude velmi nepohodlné analyzovat je. Protože pro každou novou instanci nginx musíte napsat svůj vlastní parser, protože píší protokoly jinak. Znovu, pravděpodobně stálo za to přemýšlet o tom, zda se ujistit, že všechny tyto instance nginx měly stejnou konfiguraci protokolování a zapisovaly všechny své protokoly naprosto jednotně. Totéž platí pro absolutně všechny aplikace.
Na závěr chci také přilít olej do ohně, že v ideálním případě je třeba se vyhnout protokolům ve víceřádkovém formátu. Tady jde o to, že pokud jste někdy pracovali se sběrači klád, pak jste s největší pravděpodobností viděli, co vám slibují, že umí pracovat s víceřádkovými kládami, vědí, jak je sbírat a tak dále. Vlastně ani jeden sběratel dnes podle mě neumí sbírat víceřádkové kulatiny normálně, plnohodnotně a bez chyb. Lidsky tak, aby to bylo pohodlné a bez chyb.
Ale trasování zásobníku je vždy víceřádkové protokoly a jak se jim vyhnout. Otázkou je, že protokol je záznamem události a stactrace ve skutečnosti protokolem není. Pokud shromažďujeme protokoly a ukládáme je někam do Elasticsearch a pak z nich kreslíme grafy, vytváříme nějaké zprávy o aktivitě uživatelů na vašem webu, pak když získáte trasování zásobníku, znamená to, že se děje něco neočekávaného. Neošetřená situace ve vaší aplikaci. A dává smysl automaticky nahrát trasování zásobníku někam do systému, který je dokáže sledovat.
Toto je software (stejný Sentry), který je vytvořen speciálně pro práci s trasováním zásobníku. Může okamžitě vytvářet automatizované úlohy, přidělovat je někomu, upozorňovat na výskyt stacttraces, seskupovat tyto stacttraces podle jednoho typu a tak dále. V zásadě nemá velký smysl mluvit o stactraces, když mluvíme o protokolech, protože to jsou koneckonců různé věci s různými účely.
Konfigurace
Dále si povíme o konfiguraci v Kubernetes: co s tím dělat a jak by se měly konfigurovat aplikace uvnitř Kubernetes. Obecně většinou říkám, že Docker není o kontejnerech. Každý ví, že Docker je o kontejnerech, dokonce i ti, kteří s Dockerem příliš nepracovali. Opakuji, Docker není o kontejnerech.
Docker je podle mě o standardech. A existují standardy prakticky pro všechno: standardy pro vytváření vaší aplikace, standardy pro instalaci vaší aplikace.
A tato věc – používali jsme ji dříve, právě se stala obzvláště populární s příchodem kontejnerů – tato věc se nazývá ENV (environment variables), tedy proměnné prostředí, které jsou ve vašem operačním systému. Toto je obecně ideální způsob, jak nakonfigurovat vaši aplikaci, protože pokud máte aplikace v JAVA, Pythonu, Go, Perlu, nedej bože a všechny umí číst databázového hostitele, uživatele databáze, heslo databáze, pak je to ideální. V databázovém plánu máte aplikace ve čtyřech různých jazycích nakonfigurované stejným způsobem. Neexistují žádné další různé konfigurace.
Vše lze konfigurovat pomocí ENV proměnných. Když mluvíme o Kubernetes, existuje skvělý způsob, jak deklarovat proměnné ENV přímo v Deploymentu. Pokud tedy mluvíme o tajných datech, pak můžeme tajná data z ENV proměnných (hesla do databází atd.) okamžitě vtlačit do tajného, vytvořit tajný shluk a v popisu ENV v Deploymentu uvést, že přímo nedeklarujeme hodnota této proměnné a hodnota této proměnné hesla databáze budou načteny z tajného klíče. Toto je standardní chování Kubernetes. A to je ta nejideálnější možnost konfigurace aplikací. Jen na úrovni kódu to opět platí pro vývojáře. Pokud jste DevOps, můžete se zeptat: „Kluci, naučte svou aplikaci číst proměnné prostředí. A všichni budeme šťastní."
Pokud všichni ve společnosti čtou stejně pojmenované proměnné prostředí, pak je to skvělé. Aby se nestalo, že jedni čekají na postgres databázi, druzí na název databáze, další na něco jiného, další na dbn jakéhosi druhu, aby podle toho byla uniformita.
Problém nastává, když máte tolik proměnných prostředí, že stačí otevřít Deployment – a tam je pět set řádků proměnných prostředí. V tomto případě jste prostě přerostli proměnné prostředí – a už se nemusíte mučit. V tomto případě by mělo smysl začít používat konfigurace. To znamená, že trénujte svou aplikaci, aby používala konfigurace.
Jedinou otázkou je, že konfigurace nejsou to, co si myslíte. Config.pi není konfigurace, kterou lze pohodlně používat. Nebo nějaká konfigurace ve vašem vlastním formátu, případně nadaná - to také není konfigurace, kterou mám na mysli.
Mluvím o konfiguraci v přijatelných formátech, to znamená, že zdaleka nejoblíbenějším standardem je standard .yaml. Je jasné, jak se to čte, je to čitelné pro člověka, z aplikace je jasné, jak to číst.
V souladu s tím můžete kromě YAML použít také například JSON, parsování je z hlediska čtení konfigurace aplikace odtud asi stejně pohodlné jako YAML. Pro lidi je to čtení znatelně nepohodlnější. Můžete zkusit formát a la ini. Z lidského hlediska je to docela pohodlné čtení, ale může být nepohodlné to zpracovávat automaticky v tom smyslu, že pokud někdy budete chtít generovat vlastní konfigurace, může být nepohodlné generovat formát ini.
Ale v každém případě, ať už zvolíte jakýkoli formát, jde o to, že z pohledu Kubernetes je to velmi pohodlné. Celou svou konfiguraci můžete vložit do Kubernetes v ConfigMap. A pak vezměte tuto konfigurační mapu a požádejte ji, aby byla připojena do vašeho podu v nějakém konkrétním adresáři, kde vaše aplikace načte konfiguraci z této konfigurační mapy, jako by to byl jen soubor. To je ve skutečnosti to, co je dobré udělat, když máte ve své aplikaci mnoho možností konfigurace. Nebo je to jen nějaký druh složité struktury, existuje hnízdění.
Pokud máte konfigurační mapu, můžete svou aplikaci velmi dobře naučit například automaticky sledovat změny v souboru, kde je připojena konfigurační mapa, a také automaticky znovu načíst aplikaci, když se změní konfigurace. To by byla obecně ideální možnost.
Znovu jsem o tom mluvil - tajná informace není v konfigurační mapě, tajná informace není v proměnných, tajná informace není v tajnosti. Odtud spojte tyto tajné informace s diplomacií. Obvykle ukládáme všechny popisy objektů Kubernetes, nasazení, konfigurační mapy, služby v git. Vkládat heslo do databáze do git, i když je to váš git, který máte interně ve společnosti, je tedy špatný nápad. Protože minimálně si git pamatuje všechno a jednoduše odtud odstranit hesla není tak snadné.
Zdravotní prohlídka
Dalším bodem je věc zvaná Kontrola stavu. Obecně platí, že kontrola stavu jednoduše kontroluje, zda vaše aplikace funguje. Nejčastěji se přitom bavíme o určitých webových aplikacích, u kterých se tedy z hlediska zdravotní kontroly (zde a dále raději nepřekládat) bude jednat o nějakou speciální URL, kterou zpracovávají jako standard, obvykle to dělají /health.
Při přístupu na tuto adresu URL tedy naše aplikace říká buď „ano, dobře, se mnou je všechno v pořádku, 200“ nebo „ne, se mnou není všechno v pořádku, asi 500“. Pokud tedy naše aplikace není http, není to webová aplikace, mluvíme nyní o nějakém druhu démona, můžeme přijít na to, jak provádět zdravotní kontroly. To znamená, není to nutné, pokud aplikace není http, tak vše funguje bez kontroly stavu a to nelze nijak provést. Můžete pravidelně aktualizovat některé informace v souboru, můžete přijít s nějakým speciálním příkazem pro svého démona, jako např. daemon status, který řekne "ano, vše je v pořádku, démon funguje, je naživu."
K čemu to je? První a nejzřejmější věcí je pravděpodobně důvod, proč je potřeba zdravotní kontrola – abyste pochopili, že aplikace funguje. Chci říct, je to prostě hloupé, když je to teď nahoře, vypadá to, že to funguje, takže si můžete být jisti, že to funguje. A ukázalo se, že aplikace běží, kontejner běží, instance funguje, vše je v pořádku - a pak už uživatelé odřízli všechna telefonní čísla od technické podpory a řekli „co jsi..., ty usnul, nic nefunguje."
Kontrola stavu je jen takový způsob, jak z pohledu uživatele zjistit, že funguje. Jedna z metod. Řekněme to takhle. Z pohledu Kubernetes je to také způsob, jak pochopit, kdy se aplikace spouští, protože chápeme, že je rozdíl mezi tím, kdy byl kontejner spuštěn, vytvořen a spuštěn, a kdy byla aplikace spuštěna přímo v tomto kontejneru. Protože když vezmeme nějakou průměrnou java aplikaci a zkusíme ji spustit v doku, tak na čtyřicet sekund, nebo dokonce minutu, nebo dokonce deset, to může začít v pohodě. V tomto případě můžete alespoň zaklepat na jeho porty, tam neodpoví, to znamená, že ještě není připraven přijímat provoz.
Opět pomocí kontroly stavu a pomocí toho, že se zde obracíme, můžeme v Kubernetes pochopit, že nejen kontejner v aplikaci stoupl, ale aplikace samotná se spustila, již reaguje na zdravotní kontrola, což znamená, že tam můžeme poslat provoz.
To, o čem teď mluvím, se nazývá testy připravenosti/živosti v rámci Kubernetes; naše testy připravenosti jsou tedy zodpovědné za dostupnost aplikace při vyvažování. To znamená, že pokud se v aplikaci provedou testy připravenosti, tak je vše ok, klientský provoz jde do aplikace. Pokud se neprovedou testy připravenosti, tak se aplikace prostě neúčastní, tato konkrétní instance se nepodílí na vyvažování, je z vyvažování odstraněna, klientský provoz neproudí. V souladu s tím jsou nutné testy Liveness v rámci Kubernetes, takže pokud se aplikace zasekne, může být restartována. Pokud test životnosti nefunguje pro aplikaci, která je deklarována v Kubernetes, pak se aplikace nejen odstraní z vyvažování, ale restartuje se.
A zde je důležitý bod, který bych rád zmínil: z praktického hlediska se test připravenosti obvykle používá častěji a je častěji potřeba než test živosti. Tedy jednoduše bezmyšlenkovitě deklarovat testy připravenosti i živosti, protože Kubernetes to umí a využijme vše, co umí, není moc dobrý nápad. Vysvětlím proč. Protože bod číslo dvě v testování je, že by bylo dobré zkontrolovat základní službu ve vašich zdravotních kontrolách. To znamená, že pokud máte webovou aplikaci, která poskytuje nějaké informace, které zase přirozeně musí odněkud brát. Například v databázi. No, ukládá informace, které přicházejí do tohoto REST API, do stejné databáze. Pokud tedy váš healthcheck odpoví jednoduše jako kontaktovaný slashhealth, aplikace řekne „200, dobře, všechno je v pořádku“ a zároveň databáze vaší aplikace je nepřístupná a aplikace healthcheck řekne „200, dobře, všechno je v pořádku. “ - Toto je špatná zdravotní kontrola. Takhle by to fungovat nemělo.
Tedy vaší žádosti, když k ní přijde žádost /health, nereaguje jen „200, ok“, nejprve přejde například do databáze, pokusí se k ní připojit, udělá tam něco úplně základního, třeba vybrat jednu, jen zkontroluje, zda je v databázi a můžete se do databáze dotazovat. Pokud to vše bylo úspěšné, pak odpověď zní "200, ok." Pokud není úspěšný, hlásí, že došlo k chybě, databáze je nedostupná.
Proto se v tomto ohledu opět vracím k testům připravenosti/živosti – proč s největší pravděpodobností potřebujete test připravenosti, ale o test živosti jde. Protože pokud popíšete zdravotní kontroly přesně tak, jak jsem právě řekl, ukáže se, že v části instance není k dispoziciв или со всех instancenapříklad v databázi. Když jste vyhlásili test připravenosti, naše zdravotní kontroly začaly selhávat a podle toho všechny aplikace, ze kterých databáze není přístupná, jsou prostě vypnuté z balancování a vlastně jen „visí“ v zanedbaném stavu a čekají, až se jejich databáze práce.
Pokud jsme deklarovali test životnosti, tak si představte, naše databáze se rozbila a ve vašem Kubernetes se polovina všeho začne restartovat, protože test životnosti selže. To znamená, že musíte restartovat. To není vůbec to, co chcete, dokonce jsem měl osobní zkušenost z praxe. Měli jsme chatovací aplikaci, která byla napsána v JS a vložena do databáze Mongo. A problém byl v tom, že to bylo na začátku mé práce s Kubernetesem, popsali jsme připravenost, živost testů na principu, že to Kubernetes umí, tak to využijeme. V souladu s tím se v určitém okamžiku Mongo stal trochu „tupým“ a vzorek začal selhávat. V souladu s tím podle testu deště začaly lusky „zabíjet“.
Jak chápete, když jsou „zabiti“, jedná se o chat, to znamená, že na něm visí spousta spojení od klientů. Jsou také „zabiti“ - ne, ne klienti, pouze připojení - ne všichni ve stejnou dobu, a vzhledem k tomu, že nejsou zabiti ve stejnou dobu, někteří dříve, někteří později, nezačínají ve stejnou dobu čas. Navíc standardně náhodně, nemůžeme s přesností na milisekundy předvídat čas spuštění aplikace pokaždé, takže to dělají jednu instanci v čase. Jeden infospot se zvedne, přidá se k vyrovnávání, přijdou tam všichni klienti, nevydrží takovou zátěž, protože je sám, a zhruba řečeno, pracuje jich tam desítka a klesá. Další se zvedá, celý náklad je na něm, on také padá. No, tyto pády pokračují v kaskádě. Nakonec, jak se to vyřešilo - jen jsme museli striktně zastavit uživatelský provoz do této aplikace, nechat všechny instance stoupnout a následně spustit veškerý uživatelský provoz najednou, aby byl již rozdělen mezi všech deset instancí.
Nebýt ohlášení tohoto testu živosti, který by to vše vynutil restartovat, aplikace by to zvládla v pohodě. Ale vše z bilancování je pro nás zakázáno, protože databáze jsou nepřístupné a všichni uživatelé „spadli“. Poté, když bude tato databáze k dispozici, vše je zahrnuto do vyvažování, ale aplikace se nemusí spouštět znovu a není třeba ztrácet čas a zdroje. Všichni už jsou tady, jsou připraveni na provoz, takže provoz se jen otevírá, vše je v pořádku - aplikace je na místě, vše funguje dál.
Testy připravenosti a živosti jsou tedy různé, navíc teoreticky můžete dělat různé zdravotní kontroly, jeden typ rádiusu, jeden typ liv, například, a kontrolovat různé věci. Během testů připravenosti zkontrolujte své backendy. A například na testu životnosti nezkontrolujete z toho pohledu, že test životnosti je obecně pouze aplikace, která reaguje, pokud je vůbec schopna reagovat.
Protože zkouškou živosti celkově nastává, když jsme „uvízli“. Začala nekonečná smyčka nebo něco jiného - a žádné další požadavky se nezpracovávají. Proto má smysl je dokonce oddělit – a implementovat do nich jinou logiku.
Ohledně toho, co musíte odpovědět, když máte test, když provádíte zdravotní kontroly. Je to opravdu bolest. Ti, kteří to znají, se asi zasmějí – ale vážně, v životě jsem viděl služby, které ve 200 % případů odpověděly „XNUMX“. Tedy kdo je úspěšný. Ale zároveň v těle odpovědi píšou „taková a taková chyba“.
To znamená, že vám přijde stav odpovědi - vše je úspěšné. Ale zároveň musíte tělo analyzovat, protože tělo říká „promiň, požadavek skončil chybou“ a to je prostě realita. Viděl jsem to v reálném životě.
A aby to některým lidem nepřišlo vtipné a jiným naopak velmi bolestivé, stále se vyplatí držet se jednoduchého pravidla. Ve zdravotních kontrolách a v zásadě při práci s webovými aplikacemi.
Pokud vše proběhlo v pořádku, odpovězte dvoustou odpovědí. V zásadě vám bude vyhovovat jakákoliv dvousetová odpověď. Pokud čtete ragsy velmi dobře a víte, že některé stavy odpovědí se liší od ostatních, odpovězte vhodnými: 204, 5, 10, 15, cokoliv. Pokud to není moc dobré, pak jen „dvě nula nula“. Pokud jde všechno špatně a kontrola stavu neodpovídá, tak odpovězte libovolnou pětistovkou. Opět, pokud rozumíte tomu, jak reagovat, jak se různé stavy odpovědí od sebe liší. Pokud nerozumíte, pak 502 je vaše možnost reagovat na zdravotní kontroly, pokud se něco pokazí.
Toto je další bod, chci se vrátit trochu o kontrole základních služeb. Pokud začnete například kontrolovat všechny základní služby, které stojí za vaší aplikací – vše obecně. Co dostáváme z pohledu architektury mikroslužeb, máme takový koncept jako „low coupling“ – tedy když jsou vaše služby na sobě minimálně závislé. Pokud jeden z nich selže, všechny ostatní bez této funkce budou jednoduše fungovat dál. Některé funkce prostě nefungují. Pokud tedy spojíte všechny zdravotní kontroly na sebe, skončíte s tím, že jedna věc spadne v infrastruktuře, a protože spadla, začnou selhávat i všechny zdravotní kontroly všech služeb – a obecně existuje více infrastruktury pro celá architektura mikroslužeb č. Všechno tam potemnělo.
Proto chci znovu zopakovat, že je třeba zkontrolovat podkladové služby, ty, bez kterých vaše aplikace ve sto procentech případů nemůže dělat svou práci. Čili je logické, že pokud máte REST API, přes které uživatel ukládá do databáze nebo načítá z databáze, tak při absenci databáze nemůžete zaručit práci se svými uživateli.
Pokud jsou ale vaši uživatelé, když je vyjmete z databáze, navíc obohaceni o nějaká další metadata, z jiného backendu, která zadáte před odesláním odpovědi na frontend – a tento backend není dostupný, znamená to, že dáte své odpověď bez jakékoli části metadat.
Dále tu máme také jeden z bolestivých problémů při spouštění aplikací.
Ve skutečnosti se to netýká jen Kubernetes a obecně, stalo se, že kultura jakéhosi masového vývoje a DevOps konkrétně se začala šířit zhruba ve stejnou dobu jako Kubernetes. Celkově se tedy ukazuje, že musíte svou aplikaci elegantně vypnout bez Kubernetes. I před Kubernetes to lidé dělali, ale s příchodem Kubernetes jsme se o tom začali masově bavit.
Půvabné vypnutí
Obecně, co je Graceful Shutdown a proč je to potřeba? To je o tom, když se vaše aplikace z nějakého důvodu zhroutí, musíte to udělat app stop - nebo přijmete např. signál z operačního systému, vaše aplikace mu musí rozumět a něco s tím udělat. Nejhorším scénářem samozřejmě je, když vaše aplikace obdrží SIGTERM a zní jako „SIGTERM, vydržme, pracujme, nedělejme nic“. Tohle je vyloženě špatná varianta.
Téměř stejně špatná možnost je, když vaše aplikace obdrží SIGTERM a je jako „řekli segterm, to znamená, že končíme, neviděl jsem, neznám žádné požadavky uživatelů, nevím jaké požadavky, na kterých právě pracuji, řekli SIGTERM, to znamená, že končíme“ To je také špatná volba.
Která možnost je dobrá? Prvním bodem je vzít v úvahu dokončení operací. Dobrou možností je, aby váš server stále bral v úvahu, co udělá, když obdrží SIGTERM.
SIGTERM je měkké vypnutí, je speciálně navrženo, může být zachyceno na úrovni kódu, může být zpracováno, řekněme, že teď, počkej, nejdřív dokončíme práci, kterou máme, pak skončíme.
Z pohledu Kubernetes to vypadá takto. Když řekneme podu, který je spuštěn v clusteru Kubernetes, „zastav se, jdi pryč“ nebo dojde k restartu nebo dojde k aktualizaci, když Kubernetes znovu vytvoří pody, Kubernetes odešle do podu stejnou zprávu SIGTERM, čeká na nějaký čas, a , to je doba, po kterou čeká, je také nakonfigurována, v diplomech je takový speciální parametr a jmenuje se Graceful ShutdownTimeout. Jak chápete, neříká se tomu tak nadarmo a ne nadarmo o tom teď mluvíme.
Tam můžeme konkrétně říci, jak dlouho musíme čekat mezi okamžikem, kdy pošleme SIGTERM do aplikace, a okamžikem, kdy pochopíme, že se aplikace pro něco zbláznila nebo se „zasekla“ a nechystá se skončit – a my musíme pošlete to SIGKILL, to znamená, tvrdě dokončete jeho práci. To znamená, že máme spuštěného nějakého démona, který zpracovává operace. Chápeme, že v průměru naše operace, na kterých démon pracuje, netrvají najednou déle než 30 sekund. V souladu s tím, když dorazí SIGTERM, chápeme, že náš démon může skončit maximálně 30 sekund po SIGTERM. Napíšeme to například 45 sekund pro každý případ a řekneme, že SIGTERM. Poté počkáme 45 sekund. Teoreticky by během této doby měl démon dokončit svou práci a sám skončit. Ale pokud to najednou nešlo, znamená to, že se s největší pravděpodobností zaseklo – naše požadavky už nezpracovává normálně. A za 45 sekund ho můžete bezpečně přibít.
A tady se vlastně dají zohlednit dokonce 2 aspekty. Zaprvé pochopte, že pokud jste obdrželi požadavek, začali jste s ním nějak pracovat a nedali jste uživateli odpověď, ale dostali jste například SIGTERM. Má smysl to upřesnit a dát uživateli odpověď. To je v tomto ohledu bod číslo jedna. Bod číslo dvě zde je, že pokud napíšete vlastní aplikaci, obecně postavíte architekturu tak, že dostanete požadavek na vaši aplikaci, pak začnete nějakou práci, začnete odněkud stahovat soubory, stahovat databázi a tak dále. Že. Obecně platí, že váš uživatel, váš požadavek visí půl hodiny a čeká, až mu odpovíte - pak s největší pravděpodobností budete muset pracovat na architektuře. To znamená, že vezměte v úvahu i zdravý rozum, že pokud jsou vaše operace krátké, pak má smysl ignorovat SIGTERM a upravit jej. Pokud jsou vaše operace dlouhé, pak nemá smysl v tomto případě ignorovat SIGTERM. Má smysl přepracovat architekturu, aby se předešlo tak dlouhým operacím. Aby uživatelé jen nezdržovali a nečekali. Nevím, udělejte si tam nějaký websocket, udělejte zpětné háky, které váš server již pošle klientovi, cokoliv jiného, ale nenuťte uživatele půl hodiny viset a jen čekat na relaci, dokud odpověz mu. Protože je nepředvídatelné, kde se může zlomit.
Když se vaše aplikace ukončí, měli byste poskytnout nějaký vhodný ukončovací kód. To znamená, že pokud byla vaše aplikace požádána o uzavření, zastavení a byla schopna se normálně zastavit, nemusíte vracet nějaký druh výstupního kódu 1,5,255 a tak dále. Cokoli, co není nulový kód, alespoň v systémech Linux, tím jsem si jistý, je považováno za neúspěšné. To znamená, že se má za to, že vaše aplikace v tomto případě skončila s chybou. Pokud tedy byla vaše žádost dokončena bez chyby, přátelským způsobem řeknete na výstupu 0. Pokud vaše aplikace z nějakého důvodu selže, ve výstupu řeknete ne-0. A s těmito informacemi můžete pracovat.
A poslední možnost. Je špatné, když váš uživatel odešle požadavek a zasekne se na půl hodiny, zatímco jej zpracováváte. Ale obecně bych také rád řekl o tom, co se obecně vyplatí ze strany klienta. Nezáleží na tom, zda máte mobilní aplikaci, front-end atd. Je třeba vzít v úvahu, že obecně může být uživatelská relace ukončena, stát se může cokoliv. Požadavek může být odeslán, například nedostatečně zpracován a není vrácena žádná odpověď. Váš frontend nebo vaše mobilní aplikace – řekněme to obecně jakékoli frontendy – by s tím měly počítat. Pokud pracujete s websockets, je to obecně ta nejhorší bolest, jakou jsem kdy měl.
Když to vývojáři některých běžných chatů nevědí, ukázalo se, že websocket může prasknout. Pro ně, když se něco stane na proxy, prostě změníme konfiguraci a on se znovu načte. Přirozeně jsou v tomto případě všechny dlouhotrvající relace roztrhané. Přiběhnou k nám vývojáři a říkají: „Kluci, co to děláte, všem našim klientům se rozpadl chat!“ Říkáme jim: „Co to děláte? Nemohou se vaši klienti znovu připojit? Říkají: "Ne, potřebujeme, aby se sezení netrhalo." Zkrátka je to vlastně nesmysl. Je třeba brát ohled na stranu klienta. Zejména, jak říkám, u dlouhotrvajících relací, jako jsou websockets, může dojít k přerušení a uživatel si toho nevšimne, takže takové relace musíte být schopni znovu nainstalovat. A pak je vše dokonalé.
Ресурсы
Vlastně vám tady řeknu rovnou příběh. Opět z reálného života. Nejhorší věc, jakou jsem kdy slyšel o zdrojích.
Zdroje v tomto případě mám na mysli nějaké požadavky, limity, které můžete umístit na pody ve vašich clusterech Kubernetes. Nejzábavnější věc, kterou jsem od vývojáře slyšel... Jeden z mých kolegů vývojářů na předchozím pracovišti jednou řekl: „Moje aplikace se nespustí v clusteru.“ Podíval jsem se, abych viděl, že se to nespouští, ale buď se to nevešlo do zdrojů, nebo nastavili velmi malé limity. Zkrátka aplikace nejde spustit kvůli zdrojům. Říkám: "Nezačne to kvůli zdrojům, vy se rozhodnete, kolik potřebujete, a nastavte adekvátní hodnotu." Říká: "Jaké zdroje?" Začal jsem mu vysvětlovat, že je potřeba nastavit Kubernetes, limity na požadavky a bla, bla, bla. Muž poslouchal pět minut, přikývl a řekl: „Přišel jsem sem pracovat jako vývojář, nechci nic vědět o žádných zdrojích. Přišel jsem sem napsat kód a je to." Je to smutné. To je z pohledu vývojáře velmi smutný koncept. Zvláště v moderním světě, abych tak řekl, progresivních devopů.
Proč jsou vůbec potřeba zdroje? V Kubernetes jsou 2 typy zdrojů. Některé se nazývají požadavky, jiné se nazývají limity. Pod pojmem zdroje pochopíme, že v podstatě vždy existují pouze dvě základní omezení. Tedy časové limity CPU a limity RAM pro kontejner běžící v Kubernetes.
Limit stanoví horní limit toho, jak lze zdroj ve vaší aplikaci použít. To znamená, že pokud v limitech řeknete 1 GB RAM, vaše aplikace nebude moci využít více než 1 GB RAM. A pokud to najednou bude chtít a pokusí se to udělat, pak přijde proces zvaný oom killer, který nemá paměť, to znamená, že vaši aplikaci zabije – to znamená, že se jednoduše restartuje. Aplikace se nerestartují na základě CPU. Pokud jde o CPU, pokud se aplikace snaží využívat hodně, více než je uvedeno v limitech, bude CPU jednoduše přísně vybráno. To nevede k restartům. Toto je limit – toto je horní limit.
A je tu prosba. Požadavek je způsob, jakým Kubernetes rozumí tomu, jak jsou uzly ve vašem clusteru Kubernetes naplněny aplikacemi. To znamená, že požadavek je druh potvrzení vaší aplikace. Říká to, co chci použít: „Chtěl bych, abyste mi rezervovali tolik CPU a tolik paměti.“ Takové jednoduché přirovnání. Co když máme uzel, který má, nevím, celkem 8 CPU. A tam dorazí modul, jehož požadavky říkají 1 CPU, což znamená, že uzlu zbývá 7 CPU. To znamená, že jakmile do tohoto uzlu dorazí 8 podů, z nichž každý má ve svých požadavcích 1 CPU, uzel, jako by z pohledu Kubernetes, došel CPU a další pody s požadavky nelze spuštěna na tomto uzlu. Pokud všem uzlům dojde CPU, tak Kubernetes začne říkat, že v clusteru nejsou žádné vhodné uzly pro spuštění vašich podů, protože CPU došel.
Proč jsou potřeba požadavky a proč bez požadavků myslím není potřeba v Kubernetes nic spouštět? Představme si hypotetickou situaci. Spustíte svou aplikaci bez požadavků, Kubernetes neví, kolik z toho máte, do jakých uzlů to můžete poslat. No, tlačí, strká, strká na uzly. V určitém okamžiku začnete získávat provoz do vaší aplikace. A jedna z aplikací najednou začne využívat zdroje až do limitů, které podle limitů má. Ukazuje se, že poblíž je další aplikace a ta také potřebuje zdroje. Uzel ve skutečnosti začne fyzicky docházet zdroje, například OP. Uzel ve skutečnosti začne fyzicky docházet zdroje, například paměť RAM (random access memory). Když uzlu dojde energie, nejprve přestane reagovat docker, poté cubelet a poté OS. Jednoduše upadnou do bezvědomí a definitivně vám VŠECHNO přestane fungovat. To znamená, že to povede k zablokování vašeho uzlu a budete jej muset restartovat. Stručně řečeno, situace není příliš dobrá.
A když máte požadavky, limity se moc neliší, alespoň ne mnohonásobně větší než limity nebo požadavky, pak můžete mít takové normální, racionální plnění aplikací napříč uzly clusterů Kubernetes. Kubernetes si přitom přibližně uvědomuje, kolik z toho, co kam umístí, kolik z toho, co se kde použije. To znamená, že je to jen takový okamžik. Je důležité tomu porozumět. A je důležité kontrolovat, že je to indikováno.
Ukládání dat
Náš další bod se týká ukládání dat. Co s nimi a obecně, co dělat s vytrvalostí v Kubernetes?
Myslím, že opět v našem , bylo téma o databázi v Kubernetes. A zdá se mi, že dokonce zhruba vím, co vám řekli vaši kolegové na otázku: „Je možné provozovat databázi v Kubernetes?“ Z nějakého důvodu se mi zdá, že vám vaši kolegové měli říct, že pokud se ptáte na to, zda je možné provozovat databázi v Kubernetes, tak je to nemožné.
Logika je zde jednoduchá. Jen pro případ, vysvětlím to ještě jednou, pokud jste opravdu skvělý chlap, který dokáže vybudovat poměrně odolný systém distribuovaného síťového úložiště, pochopte, jak do tohoto případu vměstnat databázi, jak by měl cloud nativní v kontejnerech fungovat v databázi obecně. S největší pravděpodobností nemáte žádnou otázku, jak jej spustit. Pokud máte takovou otázku a chcete se ujistit, že se to všechno rozvine a ustojí ve výrobě a nikdy nespadne, pak se to nestane. S tímto přístupem se zaručeně střelíte do nohy. Proto je lepší ne.
Co máme dělat s daty, která by naše aplikace chtěla ukládat, s některými obrázky, které uživatelé nahrávají, s některými věcmi, které naše aplikace generuje během svého provozu, například při spuštění? Co s nimi v Kubernetes dělat?
Obecně, v ideálním případě, ano, samozřejmě, Kubernetes je velmi dobře navržen a byl obecně původně koncipován pro bezstavové aplikace. Tedy pro ty aplikace, které informace vůbec neukládají. To je ideální.
Ale samozřejmě ne vždy existuje ideální možnost. No a co? Prvním a nejjednodušším bodem je vzít si nějaký druh S3, jen ne domácí, u kterého také není jasné, jak to funguje, ale od nějakého poskytovatele. Dobrý, normální poskytovatel – a naučte svou aplikaci používat S3. To znamená, že když chce váš uživatel nahrát soubor, řekněte „zde, prosím, nahrajte jej do S3“. Až ji bude chtít přijmout, řekněte: „Tady je odkaz na S3 zpět a vezměte si to odtud.“ To je ideální.
Pokud najednou z nějakého důvodu tato ideální volba nevyhovuje, máte aplikaci, kterou jste nenapsali, nevyvíjíte, nebo je to nějaké hrozné dědictví, neumí používat protokol S3, ale musí pracovat s místními adresáři v místní složky. Vezměte něco víceméně jednoduchého, nasaďte Kubernetes. To znamená, že okamžitě šermovat Cepha kvůli nějakým minimálním úkolům, zdá se mi, je špatný nápad. Protože Ceph je samozřejmě dobrý a módní. Ale pokud opravdu nerozumíte tomu, co děláte, pak jakmile něco nasadíte na Ceph, můžete to odtamtud velmi snadno a jednoduše nikdy dostat. Protože, jak víte, Ceph ukládá data ve svém clusteru v binární formě a ne ve formě jednoduchých souborů. Pokud se tedy náhle shluk Ceph porouchá, pak je úplná a vysoká pravděpodobnost, že odtamtud svá data už nikdy nedostanete.
Budeme mít kurz na Ceph, můžete .
Proto je lepší udělat něco jednoduchého, jako je server NFS. Kubernetes s nimi umí pracovat, můžete připojit adresář pod NFS server - vaše aplikace je jako lokální adresář. Zároveň samozřejmě musíte pochopit, že opět musíte něco udělat se svým NFS, musíte pochopit, že někdy se může stát nepřístupným a zvážit otázku, co v tomto případě uděláte. Možná by to mělo být zálohováno někde na samostatném počítači.
Dalším bodem, o kterém jsem mluvil, je to, co dělat, pokud vaše aplikace během provozu generuje nějaké soubory. Například při spuštění vygeneruje nějaký statický soubor, který je založen na nějakých informacích, které aplikace obdrží až při spuštění. Jaký okamžik. Pokud takových dat není mnoho, nemusíte se vůbec obtěžovat, stačí si nainstalovat tuto aplikaci a pracovat. Jediná otázka je co, podívej. Velmi často všemožné starší systémy, jako je WordPress a tak dále, zejména s upravenými nějakými chytrými pluginy, chytrými vývojáři PHP, často vědí, jak to udělat, aby si vygenerovali nějaký soubor. Podle toho jeden generuje jeden soubor, druhý generuje druhý soubor. Jsou rozdílní. K vyvažování v clusteru Kubernetes klientů dochází jednoduše náhodou. V souladu s tím se ukazuje, že například nevědí, jak spolupracovat. Jedna poskytuje jednu informaci, druhá dává uživateli jinou informaci. To je něco, čemu byste se měli vyhnout. To znamená, že v Kubernetes je zaručeno, že vše, co spustíte, bude fungovat ve více instancích. Protože Kubernetes je pohyblivá věc. V souladu s tím může hýbat čímkoli, kdykoli chce, aniž by se kohokoli ptal. Proto s tím musíte počítat. Vše spuštěné v jedné instanci dříve nebo později selže. Čím více rezervací budete mít, tím lépe. Ale znovu říkám, pokud máte pár takových souborů, můžete je dát přímo pod sebe, váží malé množství. Pokud je jich o něco více, pravděpodobně byste je neměli strkat do nádoby.
Poradil bych, že v Kubernetes je taková úžasná věc, můžete použít objem. Zejména se jedná o svazek typu prázdný dir. To znamená, že Kubernetes automaticky vytvoří adresář ve svých adresářích služeb na serveru, kde jste začali. A dá vám ji, abyste ji mohli použít. Je zde pouze jeden důležitý bod. To znamená, že vaše data nebudou uložena uvnitř kontejneru, ale spíše na hostiteli, na kterém běžíte. Kubernetes navíc může takové prázdné diry ovládat za normální konfigurace a je schopen řídit jejich maximální velikost a nedovolit její překročení. Jediným bodem je, že to, co jste napsali do prázdného adresáře, se během restartování modulu neztratí. To znamená, že pokud váš modul omylem spadne a znovu se zvedne, informace v prázdném adresáři nikam neodejdou. Může to znovu použít na novém začátku – a to je dobře. Pokud váš modul někam odejde, přirozeně odejde bez dat. To znamená, že jakmile modul z uzlu, kde byl spuštěn s prázdným adresářem, zmizí, prázdný adresář je smazán.
Co je ještě dobrého na prázdném adresáři? Může být například použit jako cache. Představme si, že naše aplikace něco generuje za běhu, dává to uživatelům a dělá to po dlouhou dobu. Tudíž aplikace to třeba vygeneruje a dá uživatelům a zároveň to někam uloží, takže až si příště uživatel přijde pro to samé, bude rychlejší to dát hned vygenerované. Prázdný adresář lze požádat Kubernetes o vytvoření v paměti. A tak mohou vaše mezipaměti obecně pracovat rychlostí blesku – pokud jde o rychlost přístupu k disku. To znamená, že máte v paměti prázdný adresář, v OS je uložen v paměti, ale pro vás, pro uživatele uvnitř pod, to vypadá jen jako místní adresář. Nepotřebujete aplikaci, abyste konkrétně učili nějaké kouzlo. Jednoduše vezmete a vložíte svůj soubor do adresáře, ale ve skutečnosti do paměti operačního systému. To je také velmi pohodlná funkce, pokud jde o Kubernetes.
Jaké problémy má Minio? Hlavní problém Minia je ten, že aby tahle věc fungovala, musí někde běžet a musí tam být nějaký souborový systém, tedy úložiště. A zde narážíme na stejné problémy, jaké má Ceph. To znamená, že Minio musí někde ukládat své soubory. Je to prostě HTTP rozhraní pro vaše soubory. Funkčnost je navíc zjevně horší než u Amazonu S3. Dříve nebyl schopen správně autorizovat uživatele. Nyní, pokud vím, již umí vytvářet kýble s různými oprávněními, ale opět se mi zdá, že hlavním problémem je takříkajíc minimálně základní úložný systém.
Jak Empty dir v paměti ovlivňuje limity? Nijak neovlivňuje limity. Leží v paměti hostitele a ne v paměti vašeho kontejneru. To znamená, že váš kontejner nevidí prázdný adresář v paměti jako součást své obsazené paměti. Host to vidí. V souladu s tím ano, z pohledu kubernetes, když toto začnete používat, bylo by dobré pochopit, že část své paměti věnujete prázdnému adresáři. A podle toho pochopte, že paměť může dojít nejen kvůli aplikacím, ale také proto, že do těchto prázdných adresářů někdo zapisuje.
Oblačnost
A posledním podtématem je to, co je Cloudnative. Proč je to potřeba? Oblačnost a tak dále.
Tedy ty aplikace, které jsou schopné a napsané tak, aby fungovaly v moderní cloudové infrastruktuře. Ale ve skutečnosti má Cloudnative ještě jeden takový aspekt. Že se nejedná pouze o aplikaci, která zohledňuje všechny požadavky moderní cloudové infrastruktury, ale umí s touto moderní cloudovou infrastrukturou pracovat, využijte výhod i nevýhod toho, že v těchto cloudech funguje. Nepřehánějte to a pracujte v cloudu, ale využijte výhod práce v cloudu.
Vezměme si jako příklad Kubernetes. Vaše aplikace běží v Kubernetes. Vaše aplikace může vždy, nebo spíše správci vaší aplikace, vždy vytvořit servisní účet. Tedy účet pro autorizaci v samotném Kubernetes na jeho serveru. Přidejte tam nějaká práva, která potřebujeme. A ke Kubernetes můžete přistupovat ze své aplikace. Co můžete tímto způsobem udělat? Například z aplikace přijímejte data o tom, kde se nacházejí vaše další aplikace, další podobné instance, a společně se nějak seskupujte nad Kubernetes, pokud je to potřeba.
Opět jsme měli nedávno doslova případ. Máme jednoho řadiče, který hlídá frontu. A když se v této frontě objeví nějaké nové úkoly, přejde do Kubernetes – a uvnitř Kubernetes vytvoří nový pod. Zadá tomuto podu nějaký nový úkol a v rámci tohoto podu úkol provede, odešle odpověď samotnému ovladači a ovladač pak s touto informací něco udělá. Například sčítá databázi. To je opět plus toho, že naše aplikace běží v Kubernetes. Můžeme použít samotnou vestavěnou funkcionalitu Kubernetes, abychom nějak rozšířili a zpříjemnili funkčnost naší aplikace. To znamená, neskrývat nějaké kouzlo o tom, jak spustit aplikaci, jak spustit pracovníka. V Kubernetes jednoduše odešlete požadavek v aplikaci, pokud je aplikace napsána v Pythonu.
Totéž platí, pokud překročíme Kubernetes. Někde nám běží naše Kubernetes – je dobré, když jsou v nějakém cloudu. Opět můžeme využít, a dokonce věřím, že bychom měli využívat možnosti samotného cloudu tam, kde běžíme. Od elementárních věcí, které nám cloud poskytuje. Balancing, to znamená, že můžeme vytvářet cloud balancery a používat je. To je přímá výhoda toho, co můžeme využít. Protože cloud balancing nás za prvé jednoduše hloupě zbavuje odpovědnosti za to, jak funguje, jak je nakonfigurován. Navíc je to velmi pohodlné, protože běžné Kubernetes lze integrovat s cloudy.
Totéž platí pro škálování. Běžné Kubernetes se mohou integrovat s poskytovateli cloudu. Ví, jak pochopit, že pokud clusteru dojdou uzly, to znamená, že se vyčerpal prostor uzlů, pak musíte přidat - Kubernetes sám přidá do vašeho clusteru nové uzly a začne na nich spouštět pody. To znamená, že když přijde vaše zátěž, začne se počet ohnišť zvyšovat. Když uzly v clusteru pro tyto pody dojdou, Kubernetes spustí nové uzly, a proto se počet podů může stále zvyšovat. A je to velmi pohodlné. Toto je přímá příležitost škálovat cluster za chodu. Není to příliš rychlé, v tom smyslu, že to není sekunda, je to spíš minuta na přidání nových uzlů.
Ale z mé zkušenosti je to opět ta nejlepší věc, jakou jsem kdy viděl. Když se cluster Cloudnative změnil na základě denní doby. Byla to backendová služba, kterou používali lidé v back office. To znamená, že přijdou do práce v 9 hodin ráno, začnou se přihlašovat do systému a podle toho se cluster Cloudnative, kde to všechno běží, začne bobtnat a spouštět nové moduly, aby s aplikací mohl pracovat každý, kdo přijde do práce. Když odejdou z práce ve 8:6 nebo v 30:XNUMX, clustery Kubernetes si všimnou, že už aplikaci nikdo nepoužívá, a začnou se zmenšovat. Garantovaná je úspora až XNUMX procent. V Amazonu to tehdy fungovalo, v Rusku tehdy nebyl nikdo, kdo by to uměl tak dobře.
Řeknu vám rovnou, úspora je 30 procent jednoduše proto, že používáme Kubernetes a využíváme možnosti cloudu. Nyní to lze provést v Rusku. Nebudu samozřejmě nikomu dělat reklamu, ale řekněme, že existují poskytovatelé, kteří to umí a poskytnou to hned po vybalení pomocí tlačítka.
Je tu ještě jeden poslední bod, na který bych vás také rád upozornil. Aby vaše aplikace, vaše infrastruktura byla Cloudnative, má smysl konečně začít přizpůsobovat přístup zvaný Infrastruktura jako kód, to znamená, že vaše aplikace, respektive vaše infrastruktura, je potřeba úplně stejně jako kód Popište svou aplikaci, svou obchodní logiku ve formě kódu. A pracovat s tím jako s kódem, to znamená, testovat, zavádět, ukládat do git, aplikovat na něj CICD.
A to je přesně to, co vám za prvé umožňuje mít vždy kontrolu nad vaší infrastrukturou, abyste vždy pochopili, v jakém stavu se nachází. Za druhé se vyhněte ručním operacím, které způsobují chyby. Za třetí, vyhněte se jednoduše tomu, čemu se říká obrat, kdy neustále potřebujete provádět stejné manuální úkoly. Za čtvrté, umožňuje vám mnohem rychlejší zotavení v případě poruchy. V Rusku pokaždé, když o tom mluvím, vždy se najde obrovské množství lidí, kteří říkají: „Jo, to je jasné, ale máte přístupy, zkrátka není potřeba nic opravovat.“ Ale je to pravda. Pokud se ve vaší infrastruktuře něco porouchá, pak z pohledu cloudnativního přístupu a z pohledu Infrastruktura jako kód, než to opravit, jít na server, zjistit, co je poškozeno a opravit to, je jednodušší. smazat server a vytvořit jej znovu. A tohle všechno nechám obnovit.
Všechny tyto otázky jsou podrobněji diskutovány na . Kliknutím na odkaz se můžete seznámit s programem a podmínkami. Pohodlné je, že Kubernetes zvládnete studiem z domova nebo v práci 1-2 hodiny denně.
Zdroj: www.habr.com