Sveiki, Habr!
Primename, kad išleidome dar vieną nepaprastai įdomų ir naudingą apie Kubernetes modelius. Viskas prasidėjo nuo ""Brendanas Burnsas, ir, beje, mes turime darbo šiame segmente . Šiandien kviečiame perskaityti MinIO tinklaraščio straipsnį, kuriame trumpai aprašomos Kubernetes duomenų saugojimo modelių tendencijos ir specifika.
Kubernetes iš esmės pakeitė tradicinius programų kūrimo ir diegimo modelius. Dabar komanda gali sukurti, išbandyti ir įdiegti programą per kelias dienas – įvairiose aplinkose, visose „Kubernetes“ grupėse. Toks darbas su ankstesnių kartų technologijomis paprastai užtrukdavo savaites, jei ne mėnesius.
Šis pagreitis yra įmanomas dėl „Kubernetes“ teikiamos abstrakcijos – tai yra dėl to, kad „Kubernetes“ pati sąveikauja su žemo lygio fizinių ar virtualių mašinų detalėmis, leisdama vartotojams deklaruoti norimą procesorių, norimą atminties kiekį ir konteinerio skaičių. atvejų, be kitų parametrų. Didžiulei bendruomenei, palaikančiai Kubernetes ir nuolat plečiantis jos pritaikymui, Kubernetes yra lyderis tarp visų konteinerių orkestravimo platformų plačiu skirtumu.
Augant Kubernetes naudojimui, kyla painiavos dėl jos saugojimo būdų..
Visiems konkuruojant dėl gabalėlio Kubernetes pyrago (t. y. duomenų saugojimo), kalbant apie duomenų saugojimą, signalas paskęsta dideliame triukšme.
„Kubernetes“ įkūnija modernų programų kūrimo, diegimo ir valdymo modelį. Šis modernus modelis atskiria duomenų saugyklą nuo skaičiavimo. Norėdami visiškai suprasti atskyrimą Kubernetes kontekste, taip pat turite suprasti, kas yra būseną turinčios ir be būsenos programos ir kaip duomenų saugojimas tinka prie to. Štai čia S3 naudojamas REST API metodas turi aiškių pranašumų, palyginti su kitų sprendimų POSIX/CSI metodu.
Šiame straipsnyje kalbėsime apie duomenų saugojimo modelius „Kubernetes“ ir konkrečiai paliesime diskusiją tarp būseną turinčių ir be būsenų programų, kad geriau suprastume, kuo jos skiriasi ir kodėl tai svarbu. Likusiame tekste bus nagrinėjamos programos ir jų duomenų saugojimo modeliai, atsižvelgiant į geriausią darbo su konteineriais ir „Kubernetes“ praktiką.
Konteineriai be pilietybės
Konteineriai iš prigimties yra lengvi ir trumpalaikiai. Juos galima lengvai sustabdyti, pašalinti arba perkelti į kitą mazgą – viskas per kelias sekundes. Didelėje konteinerių orkestravimo sistemoje tokios operacijos vyksta nuolat, o vartotojai tokių pokyčių net nepastebi. Tačiau perkėlimai galimi tik tuo atveju, jei konteineris neturi jokių priklausomybių nuo mazgo, kuriame jis yra. Teigiama, kad tokie konteineriai veikia be pilietybės.
Valstybiniai konteineriai
Jei konteineris saugo duomenis lokaliai prijungtuose įrenginiuose (arba blokuotame įrenginyje), tada duomenų saugykla, kurioje ji yra, gedimo atveju turės būti perkelta į naują mazgą kartu su pačiu konteineriu. Tai svarbu, nes priešingu atveju konteineryje veikianti programa negalės tinkamai veikti, nes jai reikia pasiekti duomenis, saugomus vietinėje laikmenoje. Teigiama, kad tokie konteineriai veikia valstybinis.
Grynai techniniu požiūriu būsenos konteineriai taip pat gali būti perkelti į kitus mazgus. Paprastai tai pasiekiama naudojant paskirstytas failų sistemas arba blokuojant tinklo saugyklą, prijungtą prie visų mazgų, kuriuose veikia konteineriai. Tokiu būdu konteineriai pasiekia tomus nuolatiniam duomenų saugojimui, o informacija yra saugoma diskuose, esančiuose visame tinkle. Aš pavadinsiu šį metodąvalstybinio konteinerio metodas“, o likusioje straipsnio dalyje dėl vienodumo taip pavadinsiu.
Taikant tipišką būsenos talpyklos metodą, visos programų grupės yra prijungtos prie vienos paskirstytos failų sistemos – tam tikros bendros saugyklos, kurioje yra visi taikomųjų programų duomenys. Nors kai kurie variantai galimi, tai yra aukšto lygio metodas.
Dabar pažiūrėkime, kodėl į debesis orientuotame pasaulyje požiūris į būseną turintį konteinerį yra priešingas modelis.
Debesų vietinės programos dizainas
Tradiciškai programos naudojo duomenų bazes struktūrizuotam informacijos saugojimui ir vietiniams diskams arba paskirstytoms failų sistemoms, kuriose visi nestruktūruoti ar net pusiau struktūrizuoti duomenys buvo išmesti. Augant nestruktūrizuotų duomenų kiekiui, kūrėjai suprato, kad POSIX buvo per daug šnekus, turėjo didelių papildomų išlaidų ir galiausiai trukdo programos našumui pereinant prie tikrai didelių mastų.
Tai daugiausia prisidėjo prie naujo duomenų saugojimo standarto, ty debesyje pagrįstos saugyklos, atsiradimo, visų pirma veikiančio REST API ir atleidžiančio programą nuo varginančios vietinės duomenų saugyklos priežiūros. Tokiu atveju programa veiksmingai pereina į režimą be būsenos (nes būsena yra nuotolinėje saugykloje). Šiuolaikinės programos kuriamos nuo nulio, atsižvelgiant į šį veiksnį. Paprastai bet kuri šiuolaikinė aplikacija, apdorojanti vienokius ar kitokius duomenis (logus, metaduomenis, blobus ir pan.), yra kuriama pagal į debesį orientuotą paradigmą, kai būsena perkeliama į specialiai jai saugoti skirtą programinę sistemą.
Būdingas konteinerio metodas priverčia visą šią paradigmą grįžti ten, kur ji prasidėjo!
Naudodamos POSIX sąsajas duomenims saugoti, programos veikia taip, lyg būtų būsenos, todėl jos nukrypsta nuo svarbiausių į debesį orientuoto dizaino principų, ty galimybės keisti taikomųjų programų darbuotojo gijų dydį, priklausomai nuo gaunamų duomenų. įvesties apkrova, pereiti į naują mazgą, kai tik dabartinis mazgas sugenda, ir pan.
Atidžiau pažvelgę į šią situaciją, pastebime, kad renkantis duomenų saugyklą vėl ir vėl susiduriame su POSIX vs. REST API dilema, BET su papildomu POSIX problemų paaštrėjimu dėl Kubernetes aplinkų paskirstymo. Visų pirma,
- POSIX yra plepus: POSIX semantika reikalauja, kad kiekviena operacija būtų susieta su metaduomenimis ir failų deskriptoriais, kurie padeda išlaikyti operacijos būseną. Dėl to atsiranda didelių išlaidų, kurios neturi tikrosios vertės. Objektų saugojimo API, ypač S3 API, atsikrato šių reikalavimų, leidžia programai įsijungti ir „pamiršti“ apie skambutį. Saugojimo sistemos atsakymas rodo, ar veiksmas buvo sėkmingas, ar ne. Jei nepavyks, programa gali bandyti dar kartą.
- Tinklo apribojimai: Paskirstytoje sistemoje numanoma, kad gali būti daug programų, bandančių įrašyti duomenis į tą pačią prijungtą laikmeną. Todėl programos ne tik konkuruos tarpusavyje dėl duomenų perdavimo pralaidumo (norint siųsti duomenis į laikmeną), bet ir pati saugojimo sistema konkuruos dėl šio pralaidumo, siųsdama duomenis per fizinius diskus. Dėl POSIX skambumo tinklo skambučių skaičius išauga kelis kartus. Kita vertus, S3 API aiškiai atskiria tinklo skambučius tarp tų, kurie kyla iš kliento į serverį, ir tų, kurie vyksta serveryje.
- saugumas: POSIX saugos modelis sukurtas aktyviam žmonių dalyvavimui: administratoriai konfigūruoja konkrečius prieigos lygius kiekvienam vartotojui ar grupei. Šią paradigmą sunku prisitaikyti prie debesų orientuoto pasaulio. Šiuolaikinės programos priklauso nuo API pagrįstų saugumo modelių, kur prieigos teisės apibrėžiamos kaip strategijų rinkinys, paskirstomos paslaugų paskyros, laikinieji kredencialai ir kt.
- Valdomumas: Būseną atitinkantys konteineriai turi tam tikrų valdymo išlaidų. Kalbame apie lygiagrečios prieigos prie duomenų sinchronizavimą, duomenų nuoseklumo užtikrinimą, visa tai reikalauja gerai apgalvoti, kokius duomenų prieigos modelius naudoti. Papildoma programinė įranga turi būti įdiegta, stebima ir sukonfigūruota, jau nekalbant apie papildomas kūrimo pastangas.
Konteinerio duomenų saugojimo sąsaja
Nors konteinerių saugyklos sąsaja (CSI) labai padėjo plėsti Kubernetes tūrio sluoksnį, iš dalies perduodant jį trečiųjų šalių saugyklos tiekėjams, ji taip pat netyčia prisidėjo prie įsitikinimo, kad būsenos talpyklos metodas yra rekomenduojamas metodas duomenų saugojimas Kubernetes.
CSI buvo sukurtas kaip standartas teikti savavališkas blokų ir failų saugojimo sistemas senoms programoms, kai jos veikia Kubernetes. Ir, kaip parodė šis straipsnis, vienintelė situacija, kai yra prasmingas būsenos talpyklos metodas (ir CSI dabartine forma), yra tada, kai pati programa yra sena sistema, kurioje neįmanoma pridėti objektų saugojimo API palaikymo. .
Svarbu suprasti, kad naudojant CSI dabartine forma, tai yra, montuojant apimtis dirbant su šiuolaikinėmis programomis, susidursime su maždaug tomis pačiomis problemomis, kurios kilo sistemose, kuriose duomenų saugojimas organizuojamas POSIX stiliumi.
Geresnis požiūris
Šiuo atveju svarbu suprasti, kad dauguma programų nėra specialiai sukurtos darbui, kuriam būdinga būsena arba be pilietybės. Šis elgesys priklauso nuo bendros sistemos architektūros ir konkrečių pasirinktų dizaino pasirinkimų. Pakalbėkime šiek tiek apie būsenos programas.
Iš esmės visus programos duomenis galima suskirstyti į keletą plačių tipų:
- Žurnalo duomenys
- Laiko žymos duomenys
- Sandorio duomenys
- Metaduomenys
- Konteinerių vaizdai
- Blob (dvejetainis didelis objektas) duomenys
Visi šie duomenų tipai yra labai gerai palaikomi šiuolaikinėse saugojimo platformose, be to, yra keletas vietinių debesų platformų, pritaikytų teikti duomenis kiekvienu iš šių konkrečių formatų. Pavyzdžiui, operacijų duomenys ir metaduomenys gali būti šiuolaikinėje debesies duomenų bazėje, pvz., CockroachDB, YugaByte ir kt. Sudėtinio rodinio vaizdai arba blob duomenys gali būti saugomi docker registre, pagrįstame MinIO. Laiko žymos duomenys gali būti saugomi laiko eilučių duomenų bazėje, pvz., InfluxDB ir kt. Čia nesigilinsime į kiekvieną duomenų tipą ir jo programas, tačiau bendra idėja yra vengti nuolatinio duomenų saugojimo, kuris priklauso nuo vietinio disko tvirtinimo.
Be to, dažnai efektyvu numatyti laikiną talpyklos sluoksnį, kuris būtų laikina programų failų saugykla, tačiau programos neturėtų priklausyti nuo šio sluoksnio kaip tiesos šaltinio.
Būsenos programos saugykla
Nors daugeliu atvejų naudinga palikti programas be būsenos, tos programos, kurios skirtos duomenims saugoti, pvz., duomenų bazės, objektų saugyklos, raktų reikšmių saugyklos, turi būti būsenos. Pažiūrėkime, kodėl šios programos yra įdiegtos Kubernetes. Paimkime „MinIO“ kaip pavyzdį, tačiau panašūs principai taikomi bet kuriai kitai didelei debesų saugyklos sistemai.
Savosios debesies programos sukurtos taip, kad išnaudotų visus konteineriams būdingo lankstumo privalumus. Tai reiškia, kad jie nedaro jokių prielaidų apie aplinką, kurioje jie bus dislokuoti. Pavyzdžiui, „MinIO“ naudoja vidinį trynimo kodavimo mechanizmą, kad sistema būtų pakankamai atspari, kad ji veiktų, net jei sugenda pusė diskų. „MinIO“ taip pat valdo duomenų vientisumą ir saugumą naudodama patentuotą serverio maišą ir šifravimą.
Tokioms į debesį orientuotoms programoms patogiausia naudoti vietinius nuolatinius tomus (PV) kaip atsarginę saugyklą. Vietinis PV suteikia galimybę saugoti neapdorotus duomenis, o programos, veikiančios ant šių PV, savarankiškai renka informaciją, kad padidintų duomenų mastelį ir valdytų augančius duomenų reikalavimus.
Šis metodas yra daug paprastesnis ir žymiai labiau keičiamas nei CSI pagrįsti PV, kurie sistemoje įdiegia savo duomenų valdymo ir pertekliaus sluoksnius; Esmė ta, kad šie sluoksniai paprastai prieštarauja programoms, sukurtoms taip, kad būtų rodoma būsena.
Stiprus judėjimas link duomenų atsiejimo nuo skaičiavimų
Šiame straipsnyje mes kalbėjome apie tai, kaip programos perorientuojamos į darbą neišsaugant būsenos, arba, kitaip tariant, duomenų saugojimas atsiejamas nuo skaičiavimo. Apibendrinant, pažvelkime į keletą realių šios tendencijos pavyzdžių.
, žymi duomenų analizės platforma, tradiciškai buvo būsena ir įdiegta HDFS. Tačiau „Spark“ pereinant į debesų pasaulį, platforma vis dažniau naudojama be pilietybės naudojant „s3a“. „Spark“ naudoja s3a būsenai perkelti į kitas sistemas, o patys „Spark“ konteineriai veikia visiškai be būsenos. Kiti pagrindiniai įmonių veikėjai didelių duomenų analizės srityje, visų pirma, , , Jie taip pat pereina prie darbo su duomenų saugojimo ir skaičiavimų atskyrimu.
Panašius modelius galima pastebėti ir kitose didelėse analitinėse platformose, įskaitant „Presto“, „Tensorflow to R“, „Jupyter“. Perkeliant būseną į nuotolines debesies saugyklos sistemas, tampa daug lengviau valdyti ir keisti programą. Be to, tai palengvina programos perkėlimą į įvairias aplinkas.
Šaltinis: www.habr.com