Mai lõpus korraldasime veebikohtumise teemal . Rääkisime konteineritest, Kubernetesest ja orkestreerimisest üldiselt, infrastruktuuri valimise kriteeriumidest ja paljust muust. Osalejad jagasid juhtumiuuringuid oma praktikast.
Osalejad:
- Evgeni Potapov, „ITSumma” tegevjuht. Üle poole tema klientidest kas juba liiguvad või tahavad liikuda Kubernetesesse.
- Dmitri Stollyarov, „Flant” tehnoloogia juht. Omab üle 10-aastast kogemust konteinerite süsteemidega.
- Denis Remchukov (aka Eric Oldmann), argotech.io tegevjuht, endine RAO EES. Lubas rääkida juhtumiuuringutest "veresegases" ettevõttes.
- Andrei Fedorovski, „News360.com” tehnoloogia juhtPärast ettevõtte ostmist teise mängija poolt vastutab mitmete ML ja AI projektide ning infrastruktuuri eest.
- Ivan Kruglov, süsteemiinsener, endine Booking.com.Just see inimene, kes on teinud Kubernetesega väga palju tööd.
Teemad:
- Osalejate teadmised konteineritest ja orkestreerimisest (Docker, Kubernetes jne); mida on praktikas proovitud või analüüsitud.
- Juhtum: Ettevõttes töötatakse infrastruktuuri arendamise plaani kallal tulevikura plaanide tegemiseks. Kuidas otsustatakse, kas ehitada (või üle viia praegune) infrastruktuur konteineritele ja Kubernetesile või mitte?
- Probleemid cloud-native maailmas, mida on puudu, las pakume koos välja, mis homme olema hakkab.
Käidi huvitav arutelu, osalejate arvamused olid nii erinevad ja tekitasid nii palju kommentaare, et tahame neid teiega jagada. On , ja allpool – arutelu kokkuvõte.
Kas Kubernetes on juba standard või suurepärane turundus?
«Me jõudsime selleni (Kubernetes. — Toim.) siis, kui keegi veel ei teadnud, mis see on. Me jõudsime selleni veel siis, kui seda polnud olemas. Me tahtsime seda juba varem» — Dmitri Stolyarov
Foto Reddit.com-ist
Viie või kümne aasta eest oli palju tööriistu ja ühtegi standardit ei olnud. Iga kuue kuu tagant ilmus uus toode, kui mitte mitu. Esiteks Vagrant, seejärel Salt, Chef, Puppet,… «ja iga kuue kuu tagant pead oma infrastruktuuri ümber ehitama. Sul on viis adminni, kes pidevalt tegelevad konfigureerimise ümberkirjutamisega» — meenutab Andrei Fedorovski. Ta usub, et Docker ja Kubernetes «töötasid välja» kõik teised. Docker on viimase viie aasta jooksul saanud standardiks, Kubernetes viimase kahe aasta jooksul. Ja see on hea tööstuse jaoks..
Dmitri Stolyarov ja tema meeskond armastavad Kubernetesi. Nad soovisid sellist tööriista juba enne selle ilmumist ja tulid selle juurde, kui keegi sellest veel ei teadnud. Praegu, mugavuse tõttu, ei võta nad klienti, kui nad mõistavad, et ei suuda Kubernetesi juurutada. Dmitri sõnul on ettevõttel "mitmeid tohutuid edulugusid, mis puudutavad kohmakate pärand-süsteemide ümbertegemist."
Kubernetes pole mitte ainult konteinerite orkestreerimine, vaid ka konfiguratsioonihaldussüsteem arenenud API, võrgu töötluskomponendi, L3 tasandi tasakaalustamise ja Ingress kontrollereid, mis võimaldab suhteliselt kergelt hallata ressursse, skaleerida ja eristuda infrastruktuuri alumistest kihtidest.
Kahjuks tuleb meil elus kõige eest maksta. See maks on suur, eriti kui rääkida ettevõtte üleminekust Kubernetesile arenenud infrastruktuuriga, nagu arvab Ivan Kruglov. Ta saaks vabalt töötada nii traditsioonilise infrastruktuuriga ettevõttes kui ka Kubernetesis. Peamine on mõista ettevõtte ja turu eripära. Kuid näiteks Jevgeni Potapovi jaoks, kes kokkuvõtlikult käsitleks Kubernetesit kui ükskõik millist konteinerite orkestreerimise tööriista, ei ole see küsimus oluline.
Evgeny tõi paralleeli 1990. aastate olukorraga, mil tekkis objektorienteeritud programmeerimine keerukate rakenduste programmeerimise viisina. Sel ajal käidi pidevalt arutelu ja ilmusid uued tööriistad, mis toetasid OOP-d. Hiljem ilmusid mikroteenused, et loobuda monoliitlikust kontseptsioonist. See omakorda tõi kaasa konteinerite ja nende haldamise tööriistade ilmumise. "Ma arvan, et me jõuame peagi aega, kus küsimus ei ole enam selles, kas kirjutada väikest rakendust mikroteenusena, vaid see kirjutatakse vaikimisi mikroteenusena," usub ta. Samamoodi muutuvad Docker ja Kubernetes aja jooksul standardlahenduseks ilma erilise valikuta.
Andmebaaside probleemid statelessis.
Foto autor
Täna on palju retsepte andmebaaside käivitamiseks Kuberneteses. Isegi kuidas eraldada I/O-diskiga töötav osa, erinevalt rakendusest — andmebaasi osast. Kas on võimalik, et tulevikus andmebaasid muutuvad nii, et need tarnitakse kompaktselt, kus üks osa orkestreeritakse Dockeris ja Kuberneteses, ja teises infrastruktuuri osas, eraldi tarkvara kaudu, pakutakse salvestusruumi osa? Kas andmebaasid muutuvad tootena?
See kirjeldus sarnaneb järjekordade haldamisega, kuid nõuded traditsiooniliste andmebaaside usaldusväärsuse ja teabe sünkroonimise osas on palju kõrgemad, arvab Andrei. Tavalistes andmebaasides on Cache hit ratio tavaliselt 99%. Kui töötlusprotsess kukub, käivitatakse uus ja vahemälu "soojendatakse" nullist. Seni, kuni vahemälu ei ole soojendatud, töötab töötlusprotsess aeglaselt, seega ei saa sellele koormust rakendada. Kui kasutajakoormust ei ole, ei soojene vahemälu. See on sulguv ring.
Dmitri ei nõustu selgelt — kvoorumid ja jagamine lahendavad probleemi. Kuid Andrei väidab, et lahendus ei sobi kõigile. Mõnedes olukordades sobib kvoorum, kuid see tekitab võrgu kohta lisakoormust. NoSQL andmebaas ei sobi igas olukorras.
Kohtumise osalejad jagunesid kahte leeri.
Denis ja Andreid väidavad, et kõik, mis kettale kirjutatakse — andmebaasid ja muu — on praeguses Kuberase ökosüsteemis võimatu. Kuberneteses on võimatu säilitada tootlikkuse andmete terviklikkust ja järjepidevust. See on fundamentaalne omadus. Lahendus: hübriidne infrastruktuur.
Ievened kaasaegsed cloud native andmebaasid, nagu MongoDB ja Cassandra, või sõnumijärjekorrad, nagu Kafka või RabbitMQ, vajavad pidevat andmete salvestamist väljaspool Kuberneteset.
Evgeni vaidleb: „Andmebaasid Kuberis on Venemaa-teemaline trauma või äri-teemaline, mis on seotud sellega, et Venemaal pole pilve vastuvõtmist.“ Läänes on väikesed või keskmise suurusega ettevõtted pilve. Amazon RDS-i andmebaaside kasutamine on lihtsam kui ise Kubernetesega vaeva näha. Venemaal kasutatakse Kuberit „on-premise“ ja andmebaasid tõstetakse sinna, kui püütakse vabaneda loomaaedadest.
Dmitri ei nõustunud väitega, et Kuberneteses ei saa hoida mingeid andmebaase: „Andmebaas on erinev. Kui panna sinna hiiglaslik relatsiooniline andmebaas, siis kindlasti mitte. Kui aga kasutada midagi väiksemat ja pilvepõhist, mis on moraalselt valmis pooläratuslikuks eluks, siis on kõik hästi.” Dmitri mainis ka, et andmebaaside haldamise tööriistad ei ole valmis ei Dockerile ega Kuberile, mistõttu tekivad suured raskused.
Ivan on omakorda veendunud, et isegi kui abstraktiseerida stateful ja stateless mõisted, pole Kuberneteses ettevõtte lahenduste ökosüsteem veel valmis. Kubers on keeruline, et täita seadusandlikke ja regulatiivseid nõudeid. Näiteks ei ole võimalik luua identiteedi pakkumise lahendust, kus nõutakse ranget serveri identifitseerimise garantiid, sealhulgas riistvara, mis serveritesse paigaldatakse. See valdkond areneb, kuid praegu lahendust pole.
Osalejatel ei õnnestunud kokku leppida, seega ei tule antud osas järeldusi. Paremini toome välja paar praktilist näidet.
Juhtum 1. Küberturvalisus „megarregulaatori” andmebaasidega väljaspool Kuberit
Arenenatud küberjulgeoleku süsteemi korral võimaldab konteinerite ja orkestreerimise kasutamine rünnakutest ja sissetungi katsetest tõhusalt tõrjuda. Näiteks ühes suurregulaatoris rakendas Denis ja tema meeskond orkestreerijat, mis oli seotud treenitud SIEM-teenusega, mis analüüsib logisid reaalajas ning tuvastab rünnaku, häkkimise või rikke protsessi. Rünnaku korral, katse midagi paigaldada või juhusliku lunavaraga sissetungi korral, tõstab ta orkestreerija kaudu konteinerite rakendusi kiiremini üles, kui need saavad nakatuda või kui neil on oht kurjategijate rünnakule.
Juhtum 2. Osaline andmebaaside üleviimine Booking.com-i Kubernetesesse
Booking.com-i peamine andmebaas on MySQL koos asünkroonse replikatsiooniga - olemas on master ja terve ordu slave'e. Ivan ettevõttest lahkumise ajaks oli käivitatud projekt slave'ide üleviimiseks, mida on võimalik teatud kahjuga "välja tulistada".
Lisaks põhikandjale on olemas Cassandra installatsioon, mille orkestreerimise viisid kirjutasime enne seda, kui Kubernetes tõeliselt levima hakkas. Selle osas probleeme pole, kuid see tugineb kohalikele SSD-dele. Kaugandmed, isegi ühe andmekeskuse piires, ei ole kasutusel kõrge latentsuse probleemi tõttu.
Kolmas andmebaaside klass on Booking.com'i otsinguteenuse, kus iga teenuse sõlm on andmebaas. Katsetused viia otsinguteenuse Kubernetesesse ei õnnestunud, kuna iga sõlm on 60–80 GB kohaliku salvestusruumiga, mida on keeruline 'käivitada' ja 'soojendada'.
Kokkuvõttes ei viidud otsingu mootori Kubernetesesse ja Ivan ei arva, et lähiajal oleks uusi katseid. MySQL andmebaas viidi osaliselt üle: ainult Slayvid, mille eemaldamine ei tekita probleeme. Cassandra on 'juurdunud' suurepäraselt.
Infrastruktuuri valik kui ülesanne, millele pole ühtset lahendust.
Foto autor
Eeldame, et meil on uus ettevõte või ettevõte, kus osa infrastruktuurist on rajatud vanamoodi. Seal koostatakse infrastruktuuri arengu plaan aastateks. Kuidas tehakse otsus, kas ehitada infrastruktuur konteineritele ja Kubernetesesse või mitte?
Ettevõtted, kes võitlevad nanosekundite pärast, jäävad arutelust välja. Tervislik konservatisim tasub ära usaldusväärsuse tõttu, kuid samas on ka ettevõtteid, kellel tasub kaaluda uusi lähenemisviise.
Ivan: "Praegu alustaksin kindlasti ettevõtet cloudis, lihtsalt sellepärast, et see on kiiremini", kuigi see ei pruugi tingimata odavam olla. Riskikapitalismi kasvades ei ole rahaga alustavatel ettevõtetel suuri probleeme, ja peamine ülesanne on turgu vallutada.
Ivan on seisukohal, et praeguse infrastruktuuri areng on valikukriteerium. Kui minevikus on tehtud tõsiseid investeeringuid ja see töötab, siis pole mõtet seda ümber teha. Kui aga infrastruktuur pole välja arendatud ning on probleeme tööriistade, turvalisuse ja jälgimisega, siis tasub vaadata jaotatud infrastruktuuri poole.
Maksu tuleb igal juhul maksta ja Ivan maksaks selle, mis lubaks tal tulevikus maksta vähem. "Kuna lihtsalt selle kaudu, et sõidan rongis, mille liigutavad teised, jõuan ma palju kaugemale kui juhul, kui istun teises rongis, kuhu pean ise kütust panema."» — ütleb Ivan. Kui ettevõte on uus ja latency-nõuded on kümneid millisekunde, vaataks Ivan klassikaliste andmebaaside suunas, millega tänapäeval "operaatorid" tegelevad. Need tõstavad üles replikatsiooniahela, mis lülitub automaatselt üle failide korral jne...
Kaks väikese serveriga ettevõtte jaoks ei ole Kuberes mõtet, — väidab Andrei. Kuid kui ettevõte plaanib kasvada sadade serveriteni, on automaatika ja ressursihaldussüsteem vajalikud. 90% juhtudest õigustavad kulutusi. Ja see kehtib sõltumata koormusest ja ressurssidest. Kõigile, alates idufirmadest kuni suurte ettevõteteni, millel on miljoniline publik, on mõistlik järk-järgult vaadata konteinerite orkestreerimise toodete poole. "Jah, see on tõeliselt tulevik," — usub Andrei.
Deniss märkis kaks peamist kriteeriumi — skaalautuvus ja töö usaldusväärsus. Ta valib need tööriistad, mis sobivad selle ülesande jaoks kõige paremini. „See võib olla käsitsi kokku pandud tundmatu tootja seade, millel on Nutanix Community Edition. See võib olla ka rakendus Kuberneteses, millel on andmebaas taga, mis replikeerib ja millel on määratud RTO ja RPO parameetrid.” näiteks).
Evgeni märkis, et kaadri probleem on võimalik. Hetkel ei ole turul palju kõrgekvaliteedilisi spetsialiste, kes mõistavad „seestpoolt”. Tõepoolest, kui valitud tehnoloogia on vana, on raske leida kedagi peale vanemate, igavlevaid ja elu väsinud inimesi. Kuigi teised osalenud arvavad, et see on personalikoolituse probleem.
Kui küsida, kas käivitada väike ettevõte Public Cloudis Amazon RDS andmebaasidega või „on premise” Kuberneteses andmebaasidega, siis vaatamata mõningatele puudustele, valisid osalised Amazon RDS.
Kuna enamik meetup’i kuulajatest ei ole „veres” ettevõtluses, siis jaotatud lahendused on see, mille poole tuleb püüelda. Andmete salvestussüsteemid peaksid olema jaotatud, usaldusväärsed ning looma latentsust, mida mõõdetakse millisekundites, maksimaalselt kümnetes., — lõpetas Andrei.
Kubernetes kasutamise hindamine
Kuulaja Anton Zhbankov esitas Kubernetes'i pooldajatele küsimuse-püünise: kuidas valiti ja viidi läbi tehnilist ja majanduslikku põhjendust? Miks Kubernetes ja mitte näiteks virtuaalmasinad?
Foto autor
Neile vastasid Dmitri ja Ivan. Mõlemal juhul katsetati lahendusi nagu katse-eksitusmeetod, mille tulemusena jõudsid osalised Kubernetes'eni. Praegu hakkab äri iseseisvalt arendama tarkvara, mille üleviimine Kubersisse on mõttekas. Jutt ei käi klassikalistest kolmandate osapoolte süsteemidest, nagu 1C. Kubernetes aitab, kui arendajatele on vaja kiiresti väljaandeid teha, kasutades pidevat täiustamist.
Andrei meeskond proovis luua skaleeritavat klastrit virtuaalmasinate baasil. Node’id kukkusid nagu domino, mis mõnikord viis klastrite kokkuvarisemiseni. „Teoreetiliselt on võimalik seda käsitsi lõpule viia ja toetada, kuid see on tüütu. Ja kui turul on lahendus, mis töötab kohe, siis me läheme hea meelega selle juurde. Ja me jõudsime selle tulemuseni,” räägib Andrei.
Sarnased analüüsi ja arvutamise standardid eksisteerivad, kuid keegi ei ütle, kui õiged need on tegelikus riistvaras. Arvutuste jaoks on oluline mõista iga tööriista ja ökosüsteemi, kuid see on pea võimatu.
Mida meid ootab?
Foto autor
Kui tehnoloogia areneb, ilmub üha rohkem killustunud osi, seejärel toimub faasimuutus, kus ilmub ettevõte, mis on hävitanud piisavalt „kopikaid”, et kõik kokku ühendada ühe tööriista alla.
Kas te ei arva, et tuleb päev, mil ilmub tööriist, nagu Ubuntu Linuxi maailmas? Võib-olla hõlmab üksainus konteineriseerimise ja orkestreerimise tööriist ka Kuberneteset. Sellega on lihtne luua kohapealseid pilvi.
Ivan vastas: "Google ehitab praegu Anthost - see on nende pakett, mis käivitab pilve ja sisaldab Kuberneteset, teenusevahetust, jälgimist ja kogu taristut, mis on vajalik mikroteenuste jaoks "kohapeal". Oleme peaaegu tulevikus."
Denis mainis ka Nutanixi ja VMWare'i toodet vRealize Suite, mis suudavad sarnaste probleemidega toime tulla ilma konteineriseerimiseta.
Dmitri väljendas arvamust, et "valude" vähendamine ja maksude alandamine on kaks suunda, kus oodata paranemist.
Kokkuvõtlikult arutelust, tõstame esile järgmised kaasaegse infrastruktuuri probleemid.
- Kolm osalejat tõid esile stateful'i probleemi.
- Erinevad probleemid turbe toetamisega, sealhulgas tõenäosus, et Dockeris on mitu versiooni Pythonist, rakenduste serveritest ja komponentidest.
Liigne kulu, millest oleks parem korraldada eraldi koosolek.
Koolituse probleem, kuna orkestreerimine esindab keerulist ökosüsteemi.
Tööstuse üldine probleem on tööriistade väärkasutamine.Ülejäänud järeldused jäävad teile. Siiski on tunne, et Docker + Kubernetes ei suuda kergesti saada süsteemi "keskseks" osaks. Näiteks paigaldatakse operatsioonisüsteemid esmalt riistvarale, mida ei saa öelda konteinerite ja orkestreerimise kohta. Võib-olla tulevikus ühinevad operatsioonisüsteemid ja konteinerid koos pilvehalduse tarkvaraga.
Foto autorKasutan juhust, et saata tervitused emale ja meenutada, et meil on Facebooki grupp. , kanal huvitavate postitustega erinevatest tehnoblogidest. Ja minu kanal , kus räägin tooteettevõtete arenduse juhtimisest.
Allikas: habr.com
