Na konci mája usporiadali online meetup na tému . Hovorili sme o kontajneroch, Kubernetes a orchestriácii vo všeobecnosti, o kritériách výberu infraštruktúry a mnohom ďalšom. Účastníci zdieľali prípady zo svojej praxe.
Účastníci:
- Evgenij Potapov, CEO „ITSumma“. Viac ako polovica jeho klientov už prechádza alebo má v úmysle prejsť na Kubernetes.
- Dmitrij Stoljarov, CTO „Flant“. Má viac ako 10-ročné skúsenosti s kontajnerovými systémami.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ex-RAO EES. Sľúbil, že porozpráva o prípadoch v „krvavom“ podniku.
- Andrej Fedorovskij, CTO „News360.com“Po prevzatí spoločnosti iným hráčom zodpovedá za niekoľko ML a AI projektov a za infraštruktúru.
- Ivan Kruglov, systémový inžinier, ex–Booking.com.Ten istý človek, ktorý vlastnými rukami dosiahol veľa s Kubernetes.
Témy:
- Postrehy účastníkov o kontajneroch a orchestriácii (Docker, Kubernetes a podobne); čo vyskúšali v praxi alebo analyzovali.
- Prípad: V spoločnosti vypracovávajú plán rozvoja infraštruktúry na roky. Ako sa rozhoduje, či vybudovať (alebo preniesť súčasnú) infraštruktúru na kontajneroch a Kubernetes alebo nie?
- Problémy vo svete cloud-native, čo chýba, poďme si predstavovať, čo bude zajtra.
Začala sa zaujímavá diskusia, názory účastníkov boli natoľko rôzne a vyvolali toľko komentárov, že sa chceme o ne s vami podeliť. Je , a nižšie – zhrnutie z diskusie.
Je Kubernetes už štandard alebo výborný marketing?
„K nemu (Kubernetes. — Red.) sme prišli vtedy, keď o ňom ešte nikto nevedel. Prišli sme k nemu ešte vtedy, keď ho nebolo. Chceli sme ho ešte predtým“ — Dmitrij Stoljarov
Foto z Reddit.com
Pred 5-10 rokmi existovalo obrovské množstvo nástrojov, a neexistoval žiadny jednotný štandard. Každých šesť mesiacov sa objavil nový produkt, alebo aj niekoľko. Najprv Vagrant, potom Salt, Chef, Puppet,… „a ty každých šesť mesiacov prestavuješ svoju infraštruktúru. Máš päť adminov, ktorí sú neustále zamestnaní tým, že prerábajú konfigurácie“ — spomína Andrej Fedorovskij. Domnieva sa, že Docker a Kubernetes „dali do úzadia“ ostatných. Docker sa stal štandardom posledných päť rokov, Kubernetes — za posledné dva roky. A to je dobré pre priemysel..
Dmitrij Stoljarov a jeho tím milujú Kubernetes. Chceli mať takýto nástroj skôr, ako sa objavil, a prišli k nemu, keď o ňom ešte nikto nevedel. V súčasnosti, z dôvodu pohodlia, neberú klienta, ak sa domnievajú, že neimplementujú Kubernetes. Aj podľa Dmitrija má spoločnosť "množstvo obrovských success story pri premenách hrozného legacy."
Kubernetes nie je len orchestrácia kontajnerov, je to systém na správu konfigurácie s vybudovaným API, komponentom na sieťovú prácu, L3 vyrovnávaním záťaže a Ingress kontrolérmi, ktorý umožňuje relatívne jednoduché spravovanie zdrojov, škálovanie a abstrahovanie od spodných vrstiev infraštruktúry.
Bohužiaľ, v našich životoch za všetko treba platiť. A táto daň je veľká, najmä ak hovoríme o prechode na Kubernetes pre spoločnosť s rozvinutou infraštruktúrou, ako si myslí Ivan Kruglov. Mohol by bez problémov pracovať ako vo firme s tradičnou infraštruktúrou, tak aj s Kubernetes. Hlavné je chápať vlastnosti spoločnosti a trhu. Ale napríklad pre Jevgenija Potapova, ktorý by zjednodušil Kubernetes na akýkoľvek nástroj na orchestráciu kontajnerov, taká otázka nestojí.
Jevgenij spravil analógiu so situáciou v 90. rokoch, keď sa objavilo objektovo orientované programovanie ako spôsob programovania zložitých aplikácií. V tom čase sa debaty nezastavovali a objavovali sa nové nástroje, ktoré podporovali OOP. Potom sa objavili mikroslužby ako spôsob, ako sa vzdať monolitnej koncepcie. To, na druhej strane, viedlo k objaveniu kontajnerov a nástrojov na ich správu. "Myslím si, že čoskoro prídeme k času, keď sa nebude klásť otázka, či má zmysel písať mikroslužbovo malé aplikácie, budú sa písať predvolene ako mikroslužby," tvrdí on. Podobne, Docker a Kubernetes sa časom stanú štandardným riešením bez potreby voľby.
Problém databáz v stateless
Foto od
V dnešnej dobe je veľa receptov na spustenie databáz v Kubernetes. Dokonca aj na oddelenie časti, ktorá pracuje s diskovým I/O od, podmienene, aplikačnej časti databázy. Je možné, že sa databázy v budúcnosti zmenia tak, že budú dodávané v boxe, kde jedna časť bude orchestrácia prostredníctvom Dockeru a Kubernetes, a v druhej časti infraštruktúry, prostredníctvom samostatného softvéru, bude poskytovaná úložná časť? Zmenia sa databázy ako produkt?
Tento popis sa podobá na manažment frontov, ale požiadavky na spoľahlivosť a synchronizáciu informácií v tradičných databázach sú podľa Andreja oveľa vyššie. Cache hit ratio v normálnych databázach je na úrovni 99 %. Ak worker zlyhá, spustí sa nový a cache sa "zahrieva" od nuly. Kým cache nie je zahriaty, worker pracuje pomaly, čo znamená, že na neho nemôže byť kladená používateľská záťaž. Kým nie je používateľská záťaž, cache sa nezahrieva. To je uzavretý cyklus.
Dmitrij s tým zásadne nesúhlasí — kvóra a shardovanie riešia problém. Ale Andrej trvá na tom, že riešenie nie je vhodné pre všetkých. V niektorých situáciách je vhodné kvórum, ale to zaťažuje sieť. NoSQL databázy nie sú vo všetkých prípadoch vhodné.
Účastníci meetupu sa rozdelili na dva tábory.
Denis a Andrej tvrdia, že všetko, čo zapisuje na disk — databázy a iné — nie je v súčasnej ekosystéme Kubernetes možné. Nie je možné zachovať integritu a konzistenciu produktívnych dát v Kubernetes. To je základná vlastnosť. Riešenie: hybridná infraštruktúra.
Aj moderné cloud natívne databázy, ako MongoDB a Cassandra, alebo správy frontov, ako Kafka alebo RabbitMQ, vyžadujú neustále úložiská dát mimo Kubernetes.
Evgenij namieta: „Databázy v Kubernete sú trauma okolo ruská, alebo okolo podniková, ktorá súvisí s tým, že v Rusku nie je prijatie cloudu“. Malé alebo stredné firmy na Západe — to je Cloud. Používanie Amazon RDS je jednoduchšie, než sa s Kubernetes zaoberať samostatne. V Rusku používajú Kubernetes „on-premise“ a presúvajú do neho databázy, keď sa snažia zbaviť sa zverine.
Dmitrij tiež nesúhlasil s tvrdením, že žiadne databázy nemôžu byť držané v Kubernetes: „Databáza je iná jak iná. A ak zatlačíš obrovskú relačnú databázu — tak v žiadnom prípade. Ak zatlačíš niečo malé a cloud natívne, čo je morálne pripravené na poluefémérny život, všetko bude v poriadku.“ Dmitrij tiež spomenul, že nástroje na správu databáz nie sú pripravené na Docker ani Kuber, kvôli čomu vznikajú veľké problémy.
Ivan je, na svojej strane, presvedčený, že aj keď sa abstrahuje od pojmov stateful a stateless, ekosystém firemných riešení v Kubernetes zatiaľ nie je pripravený. S Kuberom je náročné splniť požiadavky legislatívnych a regulačných orgánov. Napríklad je nemožné vytvoriť riešenie na poskytovanie identity, kde sú potrebné prísne záruky identifikácie servera, dokonca až po hardvér, ktorý je vložený do serverov. Táto oblasť sa vyvíja, ale zatiaľ neexistuje riešenie.
Ú účastníkom sa nepodarilo dohodnúť, takže v tejto časti záverov nebude nasledovať. Radšej uvedieme pár praktických príkladov.
Prípad 1. Kybernetická bezpečnosť „megaregulátora“ s databázami mimo Kuber
V prípade vyvinutého systému kybernetickej bezpečnosti, využívanie kontajnerov a orchestrácie umožňuje brániť sa proti útokom a narušeniam. Napríklad v jednom megaregulátore Denis a jeho tím implementovali spojenie orchestrátora s vyškolenou SIEM službou, ktorá analyzuje protokoly v reálnom čase a určuje proces útoku, prieniku alebo poruchy. V prípade útoku, pokusu niečo umiestniť alebo pri prenikaní ransomvérom, sa cez orchestrátor rýchlejšie spúšťajú kontajnery s aplikáciami, než ich infikuje, alebo skôr, než ich napadne útočník.
Prípad 2. Čiastočný presun databáz Booking.com do Kubernetes
V Booking.com je základná databáza MySQL s asynchronnou replikáciou — je tu master a celá hierarchia slave-ov. V čase Odchodu Ivana z firmy bol spustený projekt na presun slave-ov, ktoré je možné "odstrániť" s určitými následkami.
Okrem hlavnej databázy existuje inštalácia Cassandra s vlastnou orchestráciou, ktorá bola vyvinutá ešte predtým, než sa Kuber stal hlavnym prúdom. Problémy v tomto smere nie sú, ale má persistentné úložisko na lokálnych SSD diskoch. Vzdialené úložiská, aj v rámci jedného dátového centra, nie sú využívané kvôli problému s vysokou latenciou.
Tretia trieda databáz je vyhľadávací servis Booking.com, kde každá uzol služby predstavuje databázu. Pokusy preniesť vyhľadávací servis do Kubera zlyhali, pretože každý uzol má 60—80 GB lokálneho úložiska, ktoré je ťažké „spustiť“ a „rozbehnúť“.
Nakoniec nepresunuli vyhľadávací engin do Kubernetes, a Ivan neverí, že v blízkej budúcnosti budú nové pokusy. MySQL databáza bola presunutá napoly: iba slave-ov, ktoré nie je problém "odstrániť". Cassandra "sa usadila" výborne.
Výber infraštruktúry ako úloha bez univerzálneho riešenia
Foto od
Predpokladajme, že máme novú spoločnosť alebo spoločnosť, kde je časť infraštruktúry postavená podľa starších noriem. V tejto spoločnosti budujú plán rozvoja infraštruktúry na dlhé roky. Ako sa rozhoduje, či budovať infraštruktúru na kontajneroch a Kubernetes alebo nie?
Spoločnosti, ktoré sa pretekajú o nanosekundy, sú vylúčené z diskusie. Zdravý konzervativizmus sa oplatí z hľadiska spoľahlivosti, ale aj tak existujú spoločnosti, ktoré by mali zvážiť nové prístupy.
Ivan: „Určite by som teraz založil spoločnosť v cloude, jednoducho preto, že je to rýchlejšie“, hoci to nemusí byť lacnejšie. S rozvojom venture kapitálu nemajú startupy s peniazmi veľké problémy a hlavnou úlohou je získať trh.
Ivan si myslí, že rozvinutosť aktuálnej infraštruktúry je kritériom voľby. Ak bolo v minulosti investovaných veľa peňazí a to funguje, nemá zmysel to prerábať. Ak je však infraštruktúra nedostatočne rozvinutá a sú problémy s nástrojmi, bezpečnosťou a monitorovaním, má zmysel pozrieť sa na distribuovanú infraštruktúru.
Daň sa bude musieť zaplatiť v každom prípade a Ivan by zaplatil tú, ktorá mu v budúcnosti umožní platiť menej. „Pretože len z toho dôvodu, že cestujem v vlaku, ktorý riadia iní, prejde oveľa ďalej, ako keby som nastúpil do iného vlaku, do ktorého by som musel sám pridávať palivo.“ — hovorí Ivan. Keď je spoločnosť nová a požiadavky na latenciu sú desiatky milisekúnd, Ivan by sa pozeral na „operátorov“, do ktorých sa dnes „prenášajú“ klasické databázy. Tí zdvíhajú replikačnú šnúru, ktorá sa automaticky prepína v prípade výpadku a podobne...
Pre malú spoločnosť s pár servermi v Kubernetes to nedáva zmysel, — tvrdí Andrej. Ale ak má v pláne rásť na sto serverov a viac, potrebuje automatizáciu a systém správy zdrojov. 90 % prípadov ospravedlňuje náklady. A to bez ohľadu na úroveň zaťaženia a zdrojov. Všetkým, od startupov po veľké spoločnosti s miliónmi používateľov, dáva zmysel postupne sa pozerať na produkty pre orchestrácie kontajnerov. „Áno, to je naozaj budúcnosť,“ — je presvedčený Andrej.
Denis označil dva hlavné kritériá — škálovateľnosť a odolnosť prevádzky. Vyberie tie nástroje, ktoré najlepšie vyhovujú tejto úlohe. „Môže to byť no-name zostavený na kolene, a na ňom Nutanix Community Edition. Môže to byť druhá línia vo forme aplikácie na Kuber s databázou na backend, ktorá sa replikáciuje a má stanovené parametre RTO a RPO“ (recovery time/point objectives — príklad).
Evgenij označil možný problém s odborníkmi. V súčasnosti nie je na trhu veľa vysokokvalitných odborníkov, ktorí sa rozumejú 'vnútornostiam'. Naozaj, ak je vybraná technológia stará, ťažko nájsť niekoho iného ako starších unudených a unavených ľudí. Aj keď ostatní účastníci sa domnievajú, že to je otázka školenia odborníkov.
Ak postavíme otázku voľby: spustiť malú firmu v Public Cloud s databázami v Amazon RDS alebo „on premise“ s databázami v Kubernetes, tak napriek niektorým nedostatkom, výberom účastníkov sa stal Amazon RDS.
Keďže väčšina poslucháčov meetupu nie je z 'krvavého' enterprisu, tak distribuované riešenia sú to, k čomu sa treba snažiť. Systémy na ukladanie údajov by mali byť distribuované, spoľahlivé a vytvárať latenciu meranú v milisekundách, maximálne desiatkach, — zhrnul Andrej.
Hodnotenie použitia Kubernetes
Poslucháč Anton Zhbánkov položil otázku-pascu apológom Kubernetes: ako vyberali a uskutočňovali technicko-ekonomické ospravedlnenie? Prečo Kubernetes, prečo nie virtuálne stroje, napríklad?
Foto od
Odpovedali mu Dmitrij a Ivan. V oboch prípadoch metódou pokus-omyl bola vytvorená sekvencia rozhodnutí, v dôsledku ktorej obaja účastníci prešli na Kubernetes. Teraz biznis začína sám vyvíjať softvér, ktorý má zmysel presunúť do Kuber. Nejde o klasické externé systémy, ako 1C. Kubernetes pomáha, keď vývojárom treba rýchlo robiť releasy, pri neustálom Continuous Improvement.
Andrejov tím sa pokúsil vytvoriť škálovateľný klaster na základe virtuálnych strojov. Uzly padali ako dominá, čo niekedy viedlo k zlyhaniu klastru. „Teoreticky je možné to dodělat a podopierať ručne, ale je to náročné. A ak na trhu existuje riešenie, ktoré umožňuje pracovať z krabice, tak s radosťou sa k nemu obraciame. A výsledkom bolo prechádzanie k nemu,“ hovorí Andrej.
Normy pre takúto analýzu a výpočet existujú, ale nikto nepovie, do akej miery sú pravdivé na reálnom hardvéri v prevádzke. Pre výpočty je taktiež dôležité rozumieť každému nástroju a ekosystému, čo je však nemožné.
Čo nás čaká
Foto od
Keď technológie napredujú, objavuje sa čoraz viac roztrhnutých kusov a potom nastáva fázový prechod, prichádza dodávateľ, ktorý investoval dosť prostriedkov, aby všetko spojil do jedného nástroja.
Nemyslíte, že príde okamih, keď sa objaví nástroj, ktorý sa stane ako Ubuntu pre svet Linuxu? Možno jednotný nástroj pre kontajnerizáciu a orchestrace zahŕňa aj Kuber. S ním bude jednoduchšie budovať on-premise cloud.
Odpoveď poskytol Ivan: „Google teraz buduje Anthos — to je ich balíková ponuka, ktorá rozvíja cloud a zahŕňa Kuber, Service Mesh, monitorovanie — všetku infraštruktúru, ktorá je potrebná pre mikroslužby v on-premise. Sme takmer v budúcnosti.“
Denis tiež spomenul Nutanix a VMWare s produktom vRealize Suite, ktoré môžu zvládnuť podobnú úlohu bez kontajnerizácie.
Dmitrij vyjadril názor, že zníženie „bolesti“ a zníženie nákladov sú dva smery, kde sa očakávajú zlepšenia.
Na záver diskusie vy выделим nasledujúce problémy modernej infraštruktúry
- Hneď traja účastníci poukázali na problém so stateful.
- Rôzne problémy s podporou bezpečnosti, vrátane pravdepodobnosti, že sa v Dockeri objaví niekoľko verzií Pythonu, aplikačných serverov a komponentov.
Nadmerná spotreba, na ktorej by bolo lepšie urobiť samostatný meetup.
Problém učenia, keďže orchestrace predstavuje zložitý ekosystém.
Celkovo je problém odvetvia — používanie nástrojov nie podľa určenia.Zvyšné závery nechávam na vás. Počas zostáva pocit, že prepojenie Docker+Kubernetes nie je jednoduché stať sa „centrálnou“ súčasťou systému. Napríklad operačné systémy sa inštalujú na hardvér ako prvé, čo sa nedá povedať o kontajneroch a orchestrace. Možno sa v budúcnosti prepoja operačné systémy a kontajnery s cloud management softvérom.
Foto odPri tejto príležitosť chcem pozdraviť mamu a pripomenúť, že máme facebookovú skupinu , kanál s zaujímavými publikáciami z rôznych technických blogov. A môj kanál , kde rozprávam o správe vývoja v produktových spoločnostiach.
Zdroj: habr.com
