Na konci mája uskutočnilo online stretnutie na túto tému . Hovorili sme o kontajneroch, Kubernetes a princípe orchestrácie, kritériách pre výber infraštruktúry a oveľa viac. Účastníci zdieľali prípady z vlastnej praxe.
Účastníci:
- Evgeniy Potapov, generálny riaditeľ spoločnosti ITSumma. Viac ako polovica zákazníkov sa už sťahuje alebo chce prejsť na Kubernetes.
- Dmitrij Stolyarov, CTO "Flant". Má viac ako 10 rokov skúseností s prácou s kontajnerovými systémami.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, bývalý RAO UES. Sľúbil, že bude hovoriť o prípadoch v „krvavom“ podniku.
- Andrey Fedorovsky, CTO “News360.com”Po odkúpení spoločnosti iným hráčom je zodpovedný za množstvo projektov a infraštruktúry ML a AI.
- Ivan Kruglov, systémový inžinier, ex-Booking.com.Ten istý človek, ktorý s Kubernetesom urobil veľa vlastnými rukami.
Motívy:
- Názory účastníkov na kontajnery a orchestráciu (Docker, Kubernetes atď.); čo bolo vyskúšané v praxi alebo analyzované.
- Prípad: Spoločnosť už roky buduje plán rozvoja infraštruktúry. Ako sa rozhoduje, či vybudovať (alebo migrovať súčasnú) infraštruktúru na kontajnery a Kuber alebo nie?
- Problémy v cloudovom natívnom svete, čo chýba, predstavme si, čo bude zajtra.
Rozprúdila sa zaujímavá diskusia, názory účastníkov boli natoľko rozdielne a vyvolali toľko komentárov, že sa o ne chcem s vami podeliť. Jedzte a nižšie je zhrnutie diskusie.
Je už Kubernetes štandardom alebo skvelým marketingom?
"Prišli sme na to (Kubernetes. - Ed.), keď o tom ešte nikto nevedel. Prišli sme k nemu, aj keď tam nebol. Chceli sme to už predtým" - Dmitrij Stolyarov
Foto z Reddit.com
Pred 5-10 rokmi existovalo obrovské množstvo nástrojov a neexistoval jediný štandard. Každých šesť mesiacov sa objavil nový produkt, alebo dokonca viac ako jeden. Najprv Vagrant, potom Soľ, Šéfkuchár, Bábka,... „a každých šesť mesiacov obnovujete svoju infraštruktúru. Máte päť správcov, ktorí sú neustále zaneprázdnení prepisovaním konfigurácií,“ spomína Andrey Fedorovsky. Verí, že Docker a Kubernetes „vytlačili“ zvyšok. Docker sa stal štandardom za posledných päť rokov, Kubernetes za posledné dva roky. A to je dobré pre priemysel..
Dmitrij Stolyarov a jeho tím milujú Kubera. Chceli takýto nástroj skôr, ako sa objavil, a prišli k nemu, keď o ňom nikto nevedel. V súčasnosti z dôvodu pohodlia neprijmú klienta, ak chápu, že s ním nebudú implementovať Kubernetes. Zároveň má spoločnosť podľa Dmitrija „veľa obrovských úspechov o prerobení hrozného dedičstva“.
Kubernetes nie je len orchestrácia kontajnerov, je to systém riadenia konfigurácie s vyvinutým API, sieťovým komponentom, vyvažovaním L3 a kontrolérmi Ingress, vďaka čomu je relatívne jednoduché spravovať zdroje, škálovať a abstrahovať od nižších vrstiev infraštruktúry.
Bohužiaľ, v našom živote musíme platiť za všetko. A táto daň je veľká, najmä ak hovoríme o prechode na Kubernetes spoločnosti s rozvinutou infraštruktúrou, ako sa domnieva Ivan Kruglov. Mohol voľne pracovať ako vo firme s tradičnou infraštruktúrou, tak aj s Kuberom. Hlavná vec je pochopiť vlastnosti spoločnosti a trhu. Ale napríklad pre Jevgenija Potapova, ktorý by zovšeobecnil Kubernetes na akýkoľvek nástroj na orchestráciu kontajnerov, takáto otázka nevzniká.
Evgeniy nakreslil analógiu so situáciou v 1990. rokoch, keď sa objektovo orientované programovanie objavilo ako spôsob programovania zložitých aplikácií. V tom čase debata pokračovala a objavili sa nové nástroje na podporu OOP. Potom sa mikroslužby objavili ako spôsob, ako sa vzdialiť od monolitického konceptu. To následne viedlo k vzniku kontajnerov a nástrojov na správu kontajnerov. „Myslím si, že čoskoro prídeme do doby, kedy už nebude otázka, či sa oplatí písať malú mikroslužbu, štandardne sa bude písať ako mikroslužba,“ verí. Rovnako tak Docker a Kubernetes sa časom stanú štandardným riešením bez potreby voľby.
Problém databáz v bezstavovom stave
Foto
V súčasnosti existuje veľa receptov na spustenie databáz v Kubernetes. Dokonca aj to, ako oddeliť časť, ktorá pracuje s I/O diskom, od aplikačnej časti databázy. Je možné, že sa v budúcnosti databázy zmenia natoľko, že budú dodávané v krabici, kde jedna časť bude riadená cez Docker a Kubernetes a v inej časti infraštruktúry bude cez samostatný softvér poskytovaná úložná časť? ? Zmenia sa bázy ako produkt?
Tento popis je podobný riadeniu frontov, ale požiadavky na spoľahlivosť a synchronizáciu informácií v tradičných databázach sú oveľa vyššie, domnieva sa Andrey. Pomer prístupov do vyrovnávacej pamäte v bežných databázach zostáva na úrovni 99 %. Ak pracovník vypadne, spustí sa nový a vyrovnávacia pamäť sa „zahreje“ od nuly. Kým sa vyrovnávacia pamäť nezahreje, pracovník pracuje pomaly, čo znamená, že ho nemožno načítať užívateľskou záťažou. Kým nedochádza k žiadnemu zaťaženiu používateľa, vyrovnávacia pamäť sa nezohrieva. Je to začarovaný kruh.
Dmitrij zásadne nesúhlasí – problém riešia kvóra a sharding. Andrey však trvá na tom, že riešenie nie je vhodné pre každého. V niektorých situáciách je kvórum vhodné, ale zaťažuje sieť dodatočne. NoSQL databáza nie je vhodná vo všetkých prípadoch.
Účastníci stretnutia boli rozdelení do dvoch táborov.
Denis a Andrey tvrdia, že všetko, čo je zapísané na disk – databázy a tak ďalej – je v súčasnom ekosystéme Kuber nemožné. Je nemožné zachovať integritu a konzistenciu produkčných údajov v Kubernetes. Toto je základná vlastnosť. Riešenie: hybridná infraštruktúra.
Dokonca aj moderné natívne cloudové databázy ako MongoDB a Cassandra alebo fronty správ ako Kafka alebo RabbitMQ vyžadujú trvalé úložiská údajov mimo Kubernetes.
Evgeniy namieta: „Základne v Kubere sú takmer ruským alebo takmer podnikovým zranením, ktoré súvisí so skutočnosťou, že v Rusku neexistuje žiadna adopcia cloudu. Malé alebo stredné firmy na Západe sú Cloud. Databázy Amazon RDS sa používajú jednoduchšie, ako sa sami hrabať v Kubernetes. V Rusku používajú Kuber „on-premise“ a presúvajú doň základne, keď sa snažia zbaviť zoo.
Dmitry tiež nesúhlasil s tvrdením, že v Kubernetes nemožno uchovávať žiadne databázy: „Základňa je iná ako základňa. A ak tlačíte obrovskú relačná databázu, tak za žiadnych okolností. Ak stlačíte niečo malé a cloudové natívne, čo je mentálne pripravené na semi-efemérny život, všetko bude v poriadku.“ Dmitry tiež spomenul, že nástroje na správu databáz nie sú pripravené ani pre Docker, ani pre Kuber, takže vznikajú veľké ťažkosti.
Ivan si je zasa istý, že aj keď abstrahujeme od pojmov stavový a bezstavový, ekosystém podnikových riešení v Kubernetes ešte nie je pripravený. S Kuberom je náročné dodržať legislatívne a regulačné požiadavky. Napríklad nie je možné vytvoriť riešenie na zabezpečenie identity tam, kde sa vyžadujú prísne záruky identifikácie servera, až po hardvér, ktorý je vložený do serverov. Táto oblasť sa rozvíja, no riešenie zatiaľ neexistuje.
Účastníci sa nevedeli dohodnúť, preto v tejto časti nebudú vyvodené žiadne závery. Uveďme pár praktických príkladov.
Prípad 1. Kybernetická bezpečnosť „megaregulátora“ so základňami mimo Kubery
V prípade vyvinutého systému kybernetickej bezpečnosti umožňuje použitie kontajnerov a orchestrácie bojovať proti útokom a prienikom. Napríklad v jednom megaregulátore Denis a jeho tím implementovali kombináciu orchestrátora s vyškolenou službou SIEM, ktorá analyzuje protokoly v reálnom čase a určuje proces útoku, hacknutia alebo zlyhania. V prípade útoku, pokusu niečo umiestniť alebo v prípade invázie ransomvérového vírusu to prostredníctvom orchestrátora vyzdvihne kontajnery s aplikáciami rýchlejšie, ako sa infikujú, alebo rýchlejšie, ako na ne útočník zaútočí.
Prípad 2. Čiastočná migrácia databáz Booking.com do Kubernetes
V Booking.com je hlavnou databázou MySQL s asynchrónnou replikáciou – je tam master a celá hierarchia otrokov. V čase, keď Ivan odišiel zo spoločnosti, bol spustený projekt presunu otrokov, ktorí by mohli byť „zastrelení“ s určitým poškodením.
Okrem hlavnej základne je tu inštalácia Cassandra so samopísanou orchestráciou, ktorá bola napísaná ešte predtým, ako Kuber vstúpil do hlavného prúdu. V tomto ohľade nie sú žiadne problémy, ale na lokálnych SSD diskoch pretrváva. Vzdialené úložisko, dokonca ani v rámci toho istého dátového centra, sa nepoužíva kvôli problémom s vysokou latenciou.
Treťou triedou databáz je vyhľadávacia služba Booking.com, kde každý uzol služby je databázou. Pokusy o prenos vyhľadávacej služby do Kuber zlyhali, pretože každý uzol má 60-80 GB miestneho úložiska, ktoré je ťažké „zdvihnúť“ a „zahriať“.
V dôsledku toho sa vyhľadávač nepreniesol na Kubernetes a Ivan si nemyslí, že v blízkej budúcnosti dôjde k novým pokusom. Databáza MySQL bola prenesená na polovicu: iba otroci, ktorí sa neboja byť „zastrelení“. Cassandra sa dokonale usadila.
Výber infraštruktúry ako úloha bez všeobecného riešenia
Foto
Povedzme, že máme novú spoločnosť, alebo spoločnosť, kde je časť infraštruktúry vybudovaná po starom. Na roky buduje plán rozvoja infraštruktúry. Ako sa rozhoduje, či vybudovať infraštruktúru na kontajneroch a Kuberi alebo nie?
Spoločnosti, ktoré bojujú o nanosekundy, sú z diskusie vylúčené. Zdravý konzervativizmus sa vypláca z hľadiska spoľahlivosti, no stále existujú firmy, ktoré by mali zvážiť nové prístupy.
Ivan: „Určite by som teraz založil spoločnosť na cloude, jednoducho preto, že je to rýchlejšie“, aj keď nie nevyhnutne lacnejšie. S rozvojom rizikového kapitalizmu nemajú startupy veľké problémy s peniazmi a hlavnou úlohou je dobyť trh.
Ivan je toho názoru výberovým kritériom je rozvoj súčasnej infraštruktúry. Ak v minulosti došlo k vážnej investícii a funguje to, potom nemá zmysel to prerábať. Ak infraštruktúra nie je rozvinutá a existujú problémy s nástrojmi, bezpečnosťou a monitorovaním, potom má zmysel pozrieť sa na distribuovanú infraštruktúru.
Daň bude treba zaplatiť v každom prípade a Ivan by platil tú, ktorá mu umožnila v budúcnosti platiť menej. "Pretože jednoducho vďaka tomu, že sa veziem vo vlaku, ktorým sa presúvajú iní, precestujem oveľa ďalej, ako keby som sedel v inom vlaku, do ktorého si musím sám naliať palivo.“ hovorí Ivan. Keď je spoločnosť nová a požiadavky na latenciu sú desiatky milisekúnd, Ivan by sa zameral na „operátorov“, do ktorých sú dnes „zabalené“ klasické databázy. Zvyšujú replikačný reťazec, ktorý sa sám prepne v prípade zlyhania atď.
Pre malú spoločnosť s niekoľkými servermi nemá Kubera zmysel,“ hovorí Andrey. Ale ak plánuje rast na stovky serverov alebo viac, potom potrebuje automatizáciu a systém správy zdrojov. 90% prípadov stojí za to. Navyše bez ohľadu na úroveň zaťaženia a zdrojov. Pre každého, od startupov až po veľké spoločnosti s miliónovým publikom, má zmysel postupne sa poobzerať po produktoch kontajnerovej orchestrácie. "Áno, toto je naozaj budúcnosť," je si istý Andrey.
Denis načrtol dve hlavné kritériá - škálovateľnosť a stabilita prevádzky. Vyberie nástroje, ktoré sú pre danú úlohu najvhodnejšie. „Môže to byť noname zostavené na kolenách a je na ňom Nutanix Community Edition. Môže to byť druhý riadok vo forme aplikácie na Kuber s databázou na backende, ktorá je replikovaná a má špecifikované parametre RTO a RPO“ (ciele času/bodu obnovy – približne.).
Evgeniy identifikoval možný problém s personálom. V súčasnosti nie je na trhu veľa vysokokvalifikovaných odborníkov, ktorí rozumejú „črevám“. Ak je zvolená technológia stará, potom je ťažké zamestnať niekoho iného ako ľudí v strednom veku, ktorí sa nudia a sú unavení životom. Aj keď iní účastníci sa domnievajú, že ide o školenie personálu.
Ak si položíme otázku voľby: spustiť malú spoločnosť vo verejnom cloude s databázami v Amazon RDS alebo „on premise“ s databázami v Kubernetes, potom sa napriek niektorým nedostatkom stal Amazon RDS voľbou účastníkov.
Keďže väčšina poslucháčov stretnutia nie je z „krvavého“ podniku distribuované riešenia sú to, o čo by sme sa mali snažiť. Systémy na ukladanie údajov musia byť distribuované, spoľahlivé a musia vytvárať latenciu meranú v jednotkách milisekúnd, maximálne v desiatkach“, zhrnul Andrey.
Hodnotenie používania Kubernetes
Poslucháč Anton Zhbankov položil apologétom Kubernetesa pascu: ako ste vybrali a vykonali štúdiu uskutočniteľnosti? Prečo Kubernetes, prečo nie napríklad virtuálne stroje?
Foto
Dmitrij a Ivan na to odpovedali. V oboch prípadoch sa pomocou pokusov a omylov urobila postupnosť rozhodnutí, v dôsledku ktorých obaja účastníci dorazili do Kubernetes. Teraz podniky začínajú nezávisle vyvíjať softvér, ktorý má zmysel preniesť na Kuber. Nehovoríme o klasických systémoch tretích strán, ako napríklad 1C. Kubernetes pomáha, keď vývojári potrebujú rýchlo vydať vydania, s nepretržitým neustálym zlepšovaním.
Andreyho tím sa pokúsil vytvoriť škálovateľný klaster založený na virtuálnych strojoch. Uzly padali ako domino, čo niekedy viedlo ku kolapsu klastra. „Teoreticky to môžete dokončiť a podoprieť rukami, ale je to únavné. A ak je na trhu riešenie, ktoré vám umožní pracovať ako zo škatuľky, potom sa do toho radi pustíme. A v dôsledku toho sme prešli,“ hovorí Andrey.
Existujú štandardy pre takúto analýzu a výpočet, ale nikto nemôže povedať, ako presné sú na skutočnom prevádzkovanom hardvéri. Pre výpočty je tiež dôležité pochopiť každý nástroj a ekosystém, ale to nie je možné.
Čo nás čaká
Foto
Ako sa technológia vyvíja, objavuje sa stále viac a viac nesúrodých kúskov a potom dôjde k fázovému prechodu, objaví sa predajca, ktorý zabil dosť cesta, aby sa všetko spojilo v jedinom nástroji.
Myslíte si, že príde čas, keď bude existovať nástroj ako Ubuntu pre svet Linuxu? Možno jediný nástroj na kontajnerizáciu a orchestráciu bude zahŕňať Kuber. Uľahčí to budovanie on-premise cloudov.
Odpoveď dal Ivan: „Google teraz buduje Anthos – toto je ich balíková ponuka, ktorá nasadzuje cloud a zahŕňa Kuber, Service Mesh, monitorovanie – všetok hardvér, ktorý je potrebný pre lokálne mikroslužby.“ Sme takmer v budúcnosti."
Denis spomenul aj Nutanix a VMWare s produktom vRealize Suite, ktorý si s podobnou úlohou poradí aj bez kontajnerizácie.
Dmitrij zdieľal svoj názor, že zníženie „bolesti“ a zníženie daní sú dve oblasti, v ktorých môžeme očakávať zlepšenie.
Aby sme zhrnuli diskusiu, zdôrazňujeme nasledujúce problémy modernej infraštruktúry:
- Traja účastníci okamžite identifikovali problém so stavom.
- Rôzne problémy s podporou zabezpečenia vrátane možnosti, že Docker skončí s viacerými verziami Pythonu, aplikačnými servermi a komponentmi.
Nadmerné výdavky, o ktorých je lepšie diskutovať na samostatnom stretnutí.
Výzvou učenia, ako je orchestrácia, je komplexný ekosystém.
Častým problémom v priemysle je nesprávne používanie nástrojov.Ostatné závery sú na vás. Stále existuje pocit, že pre kombináciu Docker+Kubernetes nie je jednoduché stať sa „centrálnou“ súčasťou systému. Napríklad operačné systémy sa najskôr inštalujú na hardvér, čo sa nedá povedať o kontajneroch a orchestrácii. Možno sa v budúcnosti zlúčia operačné systémy a kontajnery so softvérom na správu cloudu.
FotoChcela by som využiť túto príležitosť a pozdraviť moju mamu a pripomenúť vám, že máme facebookovú skupinu , kanál so zaujímavými publikáciami z rôznych technických blogov. A môj kanál , kde hovorím o riadení vývoja v produktových spoločnostiach.
Zdroj: hab.com