Mai lõpus pidas sellel teemal veebikoosoleku . Rääkisime konteineritest, Kubernetesest ja orkestratsioonist põhimõtteliselt, taristu valiku kriteeriumidest ja paljust muust. Osalejad jagasid juhtumeid enda praktikast.
Osalejad:
- Jevgeni Potapov, ITSumma tegevjuht. Rohkem kui pooled selle klientidest kas juba kolivad või soovivad üle minna Kubernetesele.
- Dmitri Stolyarov, "Flant" tehnikajuht. Omab 10+ aastat konteinersüsteemidega töötamise kogemust.
- Denis Remchukov (teise nimega Eric Oldmann), COO argotech.io, endine RAO UES. Ta lubas rääkida juhtumitest "verises" ettevõttes.
- Andrey Fedorovsky, tehnoloogiajuht "News360.com"Pärast ettevõtte ostmist teise mängija poolt vastutab ta mitmete ML ja AI projektide ja infrastruktuuri eest.
- Ivan Kruglov, süsteemiinsener, endine Booking.com.Sama inimene, kes Kubernetesega oma kätega palju ära tegi.
Teemad:
- Osalejate arusaamad konteineritest ja orkestratsioonist (Docker, Kubernetes jne); mida praktikas prooviti või analüüsiti.
- Juhtum: Ettevõte koostab aastateks taristu arengukava. Kuidas tehakse otsus, kas ehitada (või migreerida praegune) infrastruktuur konteineritele ja Kuberile või mitte?
- Probleemid pilve-native maailmas, mis on puudu, kujutame ette, mis juhtub homme.
Tekkis huvitav arutelu, osalejate arvamused olid nii erinevad ja tekitasid nii palju kommentaare, et tahan neid teiega jagada. Sööma , ja allpool on arutelu kokkuvõte.
Kas Kubernetes on juba standard või suurepärane turundus?
«Jõudsime selleni (Kubernetes. – Toim.) siis, kui keegi sellest veel ei teadnud. Tulime tema juurde ka siis, kui teda seal polnud. Me tahtsime seda varem" - Dmitri Stoljarov
Foto saidilt Reddit.com
5-10 aastat tagasi oli tohutult palju tööriistu ja polnud ühtset standardit. Iga kuue kuu tagant ilmus uus toode või isegi rohkem kui üks. Kõigepealt Vagrant, siis Salt, Chef, Puppet,... ja te ehitate oma infrastruktuuri iga kuue kuu tagant uuesti üles. Teil on viis administraatorit, kes on pidevalt hõivatud konfiguratsioonide ümberkirjutamisega,” meenutab Andrei Fedorovski. Ta usub, et Docker ja Kubernetes on ülejäänud "välja tõrjunud". Dockerist on saanud standard viimase viie aastaga, Kubernetes viimase kahe aastaga. Ja see on tööstusele kasulik.
Dmitri Stolyarov ja tema meeskond armastavad Kuberit. Nad tahtsid sellist tööriista enne selle ilmumist ja jõudsid selleni, kui keegi sellest ei teadnud. Praegu nad mugavuse huvides klienti ei võta, kui saavad aru, et ei hakka temaga Kubernetest juurutama. Samal ajal on Dmitri sõnul ettevõttel "palju hiiglaslikke edulugusid kohutava pärandi ümberkujundamise kohta".
Kubernetes ei ole ainult konteinerite orkestreerimine, see on konfiguratsioonihaldussüsteem, millel on välja töötatud API, võrgukomponent, L3 tasakaalustamine ja sisestuskontrollerid, mis teeb suhteliselt lihtsaks ressursside haldamise, skaleerimise ja taristu alumistest kihtidest abstraktsiooni.
Kahjuks peame oma elus kõige eest maksma. Ja see maks on suur, eriti kui rääkida Ivan Kruglovi hinnangul arenenud infrastruktuuriga ettevõtte Kubernetesele üleminekust. Ta sai vabalt töötada nii traditsioonilise infrastruktuuriga ettevõttes kui ka Kuberiga. Peamine on mõista ettevõtte ja turu omadusi. Aga näiteks Jevgeni Potapovil, kes üldistaks Kubernetese mis tahes konteineri orkestreerimisvahendiks, sellist küsimust ei teki.
Evgeniy tõi analoogia olukorraga 1990ndatel, mil objektorienteeritud programmeerimine ilmus keerukate rakenduste programmeerimise viisina. Sel ajal arutelu jätkus ja OOP-i toetamiseks ilmusid uued vahendid. Seejärel tekkisid mikroteenused kui viis, kuidas monoliitsest kontseptsioonist eemalduda. See omakorda tõi kaasa konteinerite ja konteinerihaldusvahendite tekkimise. "Ma arvan, et varsti jõuame sellesse aega, kus pole küsimustki, kas tasub väikest mikroteenuse rakendust kirjutada, see kirjutatakse vaikimisi mikroteenusena," usub ta. Samuti saavad Dockerist ja Kubernetesest lõpuks standardlahendus, ilma et oleks vaja valida.
Andmebaaside probleem kodakondsuseta
Foto:
Tänapäeval on Kubernetes andmebaaside käitamiseks palju retsepte. Isegi kuidas eraldada I/O-kettaga töötav osa tinglikult andmebaasi rakendusosast. Kas on võimalik, et tulevikus muutuvad andmebaasid nii palju, et need tarnitakse kastis, kus üks osa orkestreeritakse läbi Dockeri ja Kubernetese ning teises infrastruktuuri osas läbi eraldi tarkvara antakse talletusosa ? Kas alused muutuvad tootena?
See kirjeldus sarnaneb järjekorrahaldusega, kuid traditsioonilistes andmebaasides on teabe usaldusväärsuse ja sünkroniseerimise nõuded palju kõrgemad, usub Andrey. Vahemälu tabamuste suhe tavalistes andmebaasides jääb 99% juurde. Kui töötaja läheb alla, käivitatakse uus ja vahemälu "soojeneb" nullist. Kuni vahemälu on soojenenud, töötab töötaja aeglaselt, mis tähendab, et seda ei saa kasutaja koormusega laadida. Kuigi kasutajat ei laadita, vahemälu ei soojene. See on nõiaring.
Dmitri pole põhimõtteliselt nõus - kvoorumid ja killustamine lahendavad probleemi. Andrei aga kinnitab, et lahendus ei sobi kõigile. Mõnes olukorras sobib kvoorum, kuid see koormab võrku täiendavalt. NoSQL-i andmebaas ei sobi kõigil juhtudel.
Kohtumisel osalejad jagunesid kahte leeri.
Denis ja Andrey väidavad, et kõike, mis kettale kirjutatakse – andmebaase ja nii edasi – on praeguses Kuberi ökosüsteemis võimatu teha. Kubernetes on tootmisandmete terviklikkuse ja järjepidevuse säilitamine võimatu. See on põhiomadus. Lahendus: hübriidtaristu.
Isegi tänapäevased pilvandmebaasid, nagu MongoDB ja Cassandra, või sõnumijärjekorrad, nagu Kafka või RabbitMQ, nõuavad püsivaid andmesalve väljaspool Kubernetest.
Jevgeni vaidlustab: "Kubera baasid on Venemaa- või ettevõttelähedane kahju, mis on seotud sellega, et Venemaal pilve vastuvõtmist pole." Väikesed või keskmise suurusega ettevõtted Läänes on Cloud. Amazoni RDS-andmebaase on lihtsam kasutada kui ise Kubernetesega nokitseda. Venemaal kasutavad nad Kuberit kohapeal ja annavad sellele baasid üle, kui nad üritavad loomaaiast lahti saada.
Dmitri ei nõustunud ka väitega, et Kubernetes ei saa ühtegi andmebaasi pidada: „Baas erineb baasist. Ja kui lükata hiiglaslikku relatsiooniandmebaasi, siis mitte mingil juhul. Kui surute peale midagi väikest ja pilvepõhist, mis on vaimselt ette valmistatud poolefemeerseks eluks, on kõik hästi." Dmitri mainis ka, et andmebaasihaldustööriistad pole ei Dockeri ega Kuberi jaoks valmis, mistõttu tekivad suured raskused.
Ivan omakorda on kindel, et isegi kui abstraheerida mõistetest riikkondlik ja kodakondsuseta, pole Kubernetese ettevõtluslahenduste ökosüsteem veel valmis. Kuberiga on raske seadusandlikke ja regulatiivseid nõudeid säilitada. Näiteks on võimatu teha identiteedi pakkumise lahendust, kus nõutakse rangeid serveri tuvastamise garantiisid kuni serveritesse sisestatava riistvarani. See valdkond areneb, kuid lahendust veel pole.
Osalejad ei jõudnud kokkuleppele, mistõttu selles osas järeldusi ei tehta. Toome paar praktilist näidet.
Juhtum 1. Kuberast väljaspool asuvate baasidega „megaregulaatori” küberturvalisus
Arenenud küberturvasüsteemi puhul võimaldab konteinerite ja orkestratsiooni kasutamine tõrjuda rünnakuid ja sissetungi. Näiteks ühes megaregulaatoris rakendas Denis ja tema meeskond orkestri kombinatsiooni koolitatud SIEM-teenusega, mis analüüsib logisid reaalajas ja määrab rünnaku, häkkimise või tõrkeprotsessi. Rünnaku, katse midagi paigutada või lunavaraviiruse sissetungi korral korjab see läbi orkestraatori konteinerid rakendustega kiiremini kui need nakatuvad või kiiremini kui ründaja neid ründab.
Juhtum 2. Booking.com-i andmebaaside osaline üleviimine Kubernetesesse
Booking.com-is on põhiandmebaas asünkroonse replikatsiooniga MySQL – seal on ülem ja terve orjade hierarhia. Selleks ajaks, kui Ivan ettevõttest lahkus, käivitati projekt orjade üleandmiseks, keda võis teatud kahjustustega "tulistada".
Lisaks põhialusele on omakirjutatud orkestratsiooniga Cassandra installatsioon, mis on kirjutatud juba enne Kuberi peavoolu sisenemist. Sellega seoses pole probleeme, kuid kohalikel SSD-del on see püsiv. Kaugsalvestust, isegi samas andmekeskuses, ei kasutata suure latentsusaja probleemi tõttu.
Kolmas andmebaaside klass on Booking.com-i otsinguteenus, kus iga teenusesõlm on andmebaas. Otsinguteenuse Kuberisse ülekandmise katsed ebaõnnestusid, kuna igal sõlmel on 60–80 GB kohalikku salvestusruumi, mida on raske “tõsta” ja “soojeneda”.
Selle tulemusena ei viidud otsingumootorit Kubernetesesse ja Ivan ei usu, et lähiajal uusi katseid tuleb. MySQL-i andmebaas kanti üle pooleks: ainult orjad, kes ei karda mahalaskmist. Cassandra on end suurepäraselt sisse elanud.
Taristu valik kui ülesanne ilma üldlahenduseta
Foto:
Oletame, et meil on uus ettevõte või ettevõte, kus osa infrastruktuurist on ehitatud vanaviisi. See koostab aastateks taristu arengukava. Kuidas tehakse otsus, kas ehitada infrastruktuur konteineritele ja Kuberile või mitte?
Nanosekundite eest võitlevad ettevõtted on arutelust välja jäetud. Terve konservatiivsus tasub end ära usaldusväärsuse poolest, kuid siiski leidub ettevõtteid, kes peaksid kaaluma uusi lähenemisi.
Ivan: "Kindlasti asutaksin praegu pilvepõhise ettevõtte lihtsalt sellepärast, et see on kiirem," kuigi mitte tingimata odavam. Riskikapitalismi arenedes pole startuppidel rahaga suuri probleeme ning põhiülesanne on turu vallutamine.
Ivan on seda meelt valikukriteeriumiks on praeguse taristu arendamine. Kui varem oli tõsine investeering ja see toimib, siis pole mõtet seda uuesti teha. Kui infrastruktuur on arendamata ning probleeme on tööriistade, turvalisuse ja monitooringuga, siis on mõttekas vaadata hajutatud taristut.
Maks tuleb igal juhul tasuda ja Ivan maksaks selle, mis võimaldas edaspidi vähem maksta. "Sest ainuüksi tänu sellele, et sõidan rongis, millega teised liiguvad, sõidan palju kaugemale, kui istun teisele rongile, kuhu pean ise kütust panema."ütleb Ivan. Kui ettevõte on uus ja latentsusnõuded on kümned millisekundid, siis vaataks Ivan "operaatorite" poole, millesse on tänapäeval "mähitud" klassikalised andmebaasid. Nad tõstavad üles replikatsiooniahela, mis tõrkevahetuse korral lülitub ise ümber jne...
Paari serveriga väikese ettevõtte jaoks pole Kuberal mõtet,” ütleb Andrey. Kuid kui see plaanib kasvada sadade või enama serveriteni, vajab see automatiseerimist ja ressursihaldussüsteemi. 90% juhtudest on oma hinda väärt. Veelgi enam, sõltumata koormuse ja ressursside tasemest. Kõigil, alustavatest ettevõtetest kuni miljonilise vaatajaskonnaga suurettevõteteni on mõttekas vaadata järk-järgult konteinerite orkestreerimistoodete poole. "Jah, see on tõesti tulevik," on Andrey kindel.
Denis tõi välja kaks peamist kriteeriumi - skaleeritavus ja töö stabiilsus. Ta valib ülesande jaoks kõige paremini sobivad tööriistad. "See võib olla teie põlvedele kokku pandud noname ja sellel on Nutanix Community Edition. See võib olla teine rida Kuberi rakenduse kujul, mille taustaprogrammis on andmebaas, mis on paljundatud ja millel on määratud RTO ja RPO parameetrid" (taastamise aja/punkti eesmärgid - u.).
Jevgeni tuvastas võimaliku probleemi personaliga. Praegu pole turul palju kõrgelt kvalifitseeritud spetsialiste, kes mõistaksid "sisikonda". Tõepoolest, kui valitud tehnika on vana, siis on raske kedagi peale keskealiste, kes on tüdinud ja elust tüdinud, tööle võtta. Kuigi teised osalejad usuvad, et see on personali koolituse küsimus.
Kui seada valikuküsimus: käivitada väikeettevõte avalikus pilves koos Amazon RDS-i andmebaasidega või "eelmisel" andmebaasidega Kubernetes, siis hoolimata mõningatest puudustest sai Amazon RDS osalejate valikuks.
Kuna enamus kohtumiskuulajaid pole “verise” ettevõtmisega, siis hajutatud lahendused on see, mille poole peaksime püüdlema. Andmesalvestussüsteemid peavad olema hajutatud, töökindlad ja looma latentsusaega, mõõdetuna millisekundites, kõige rohkem kümnetes“ võttis Andrei kokku.
Kubernetese kasutamise hindamine
Kuulaja Anton Žbankov esitas Kubernetese apologeedidele lõksuküsimuse: kuidas valisite ja viisite läbi teostatavusuuringu? Miks Kubernetes, miks mitte näiteks virtuaalmasinad?
Foto:
Dmitri ja Ivan vastasid sellele. Mõlemal juhul tehti katse-eksituse meetodil otsuste jada, mille tulemusena jõudsid mõlemad osalejad Kubernetesesse. Nüüd hakkavad ettevõtted iseseisvalt arendama tarkvara, mis on mõttekas Kuberisse üle kanda. Me ei räägi klassikalistest kolmanda osapoole süsteemidest, näiteks 1C. Kubernetes aitab pideva pideva täiustamise abil, kui arendajatel on vaja kiiresti väljalaseid teha.
Andrey meeskond püüdis luua virtuaalsetel masinatel põhinevat skaleeritavat klastrit. Sõlmed langesid nagu doominokivid, mis mõnikord viis klastri kokkuvarisemiseni. "Teoreetiliselt saate selle valmis teha ja kätega toetada, kuid see on tüütu. Ja kui turul on lahendus, mis võimaldab teil kastist välja töötada, siis võtame selle hea meelega vastu. Ja selle tulemusel vahetasime,” räägib Andrey.
Selliseks analüüsiks ja arvutamiseks on olemas standardid, kuid keegi ei saa öelda, kui täpsed need on reaalse töökorras riistvara puhul. Arvutuste jaoks on oluline mõista ka iga tööriista ja ökosüsteemi, kuid see pole võimalik.
Mis meid ees ootab
Foto:
Tehnoloogia arenedes ilmub üha rohkem erinevaid tükke ja seejärel toimub faasiüleminek, ilmub müüja, kes on tapnud piisavalt tainast, et kõik saaks ühte tööriista.
Kas arvate, et tuleb aeg, mil Linuxi maailma jaoks on olemas selline tööriist nagu Ubuntu? Võib-olla sisaldab üks konteineriseerimis- ja orkestreerimistööriist Kuberit. See muudab kohapealsete pilvede loomise lihtsaks.
Vastuse andis Ivan: "Google ehitab praegu Anthost – see on nende pakitud pakkumine, mis juurutab pilve ja sisaldab Kuberit, Service Meshi, monitooringut - kogu riistvara, mida on kohapealsete mikroteenuste jaoks vaja." Oleme peaaegu tulevikus."
Denis mainis vRealize Suite'i tootega ka Nutanixi ja VMWare'i, mis saavad sarnase ülesandega hakkama ilma konteinerisse paigutamiseta.
Dmitri jagas arvamust, et "valu" vähendamine ja maksude vähendamine on kaks valdkonda, kus on oodata edusamme.
Arutelu kokkuvõtteks toome välja järgmised kaasaegse infrastruktuuri probleemid:
- Kolm osalejat tuvastasid kohe probleemi staatusega.
- Erinevad turvatoe probleemid, sealhulgas võimalus, et Dockeril on mitu Pythoni versiooni, rakendusservereid ja komponente.
Ülekulu, mida on parem eraldi koosolekul arutada.
Õppimise väljakutse kui orkestreerimine on keeruline ökosüsteem.
Tööstuses on levinud probleem tööriistade väärkasutamine.Ülejäänud järeldused on teie enda teha. Endiselt on tunne, et kombinatsioonil Docker+Kubernetes pole lihtne süsteemi “keskseks” osaks saada. Näiteks operatsioonisüsteemid installitakse esmalt riistvarale, mida ei saa öelda konteinerite ja orkestratsiooni kohta. Võib-olla ühinevad tulevikus operatsioonisüsteemid ja konteinerid pilvehaldustarkvaraga.
Foto:Kasutan juhust ja ütlen oma emale tere ja tuletan meelde, et meil on Facebooki grupp , kanal huvitavate väljaannetega erinevatest tehnikablogidest. Ja minu kanal , kus räägin arenduse juhtimisest tooteettevõtetes.
Allikas: www.habr.com