It URUS-bedriuw besocht Kubernetes yn ferskate foarmen: ûnôfhinklike ynset op blank metaal, yn Google Cloud, en ferpleatst dan har platfoarm nei de Cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin fertelt hoe't se in nije wolkprovider keas en hoe't se it slagge om te migrearjen nei it yn in rekord twa oeren (), senior systeembehearder by URUS.
Wat docht URUS?
D'r binne in protte manieren om de kwaliteit fan 'e stedske omjouwing te ferbetterjen, en ien fan har is om it miljeufreonlik te meitsjen. Dit is krekt wêr't it bedriuw URUS - Smart Digital Services oan wurket. Hjir implementearje se oplossingen dy't bedriuwen helpe om wichtige miljeu-yndikatoaren te kontrolearjen en har negative ynfloed op it miljeu te ferminderjen. Sensors sammelje gegevens oer loftkomposysje, lûdsnivo en oare parameters, en stjoere se dan nei it ferienige URUS-Ekomon-platfoarm foar analyze en oanbefellings.
Hoe URUS wurket fan binnen
In typyske klant fan URUS is in bedriuw yn of tichtby in wenwyk. Dit kin in fabryk, haven, spoardepot of in oare foarsjenning wêze. As ús klant al in warskôging krige, in boete krigen hat foar miljeufersmoarging, of minder lûd meitsje wol, de hoemannichte skealike útstjit ferminderje, komt er by ús, en biede wy him al in klearebare oplossing foar miljeumonitoring.
De H2S-konsintraasjemonitorgrafyk toant reguliere nachtlike útstjit fan in tichtby lizzende plant
De apparaten dy't wy brûke by URUS befetsje ferskate sensoren dy't ynformaasje sammelje oer de ynhâld fan bepaalde gassen, lûdsnivo's en oare gegevens om de miljeusituaasje te beoardieljen. It krekte oantal sensoren wurdt altyd bepaald troch de spesifike taak.
Ofhinklik fan 'e spesifikaasjes fan' e mjittingen kinne apparaten mei sensoren lizze op 'e muorren fan gebouwen, peallen en oare willekeurige plakken. Elk sa'n apparaat sammelet ynformaasje, aggregearret it en stjoert it nei de gegevens-ûntfangende gateway. Dêr bewarje wy de gegevens foar opslach op lange termyn en foarferwurkje se foar folgjende analyze. It ienfâldichste foarbyld fan wat wy krije as gefolch fan analyse is de loftkwaliteitsyndeks, ek wol bekend as AQI.
Parallel operearje in protte oare tsjinsten op ús platfoarm, mar se binne benammen fan in tsjinstkarakter. Bygelyks, de notifikaasjetsjinst stjoert notifikaasjes nei kliïnten as ien fan 'e kontroleare parameters (bygelyks CO2-ynhâld) de tastiene wearde grutteret.
Hoe't wy gegevens bewarje. It ferhaal fan Kubernetes op blank metaal
It projekt foar miljeumonitoring URUS hat ferskate datapakhuzen. Yn ien hâlde wy "rauwe" gegevens - wat wy direkt krigen fan 'e apparaten sels. Dizze opslach is in "magnetyske" tape, lykas op âlde kassettebânnen, mei in skiednis fan alle yndikatoaren. It twadde type opslach wurdt brûkt foar foarbewurke gegevens - gegevens fan apparaten, ferrike mei metadata oer ferbiningen tusken sensors en de lêzingen fan 'e apparaten sels, oansluting by organisaasjes, lokaasjes, ensfh.. Dizze ynformaasje lit jo dynamysk beoardielje hoe't in bepaalde yndikator hat feroare oer in bepaalde perioade. Wy brûke de "rauwe" gegevens opslach, ûnder oare, as in reservekopy en foar it herstellen fan foarbewurke gegevens, as sa'n needsaak ûntstiet.
Doe't wy ferskate jierren lyn sochten om ús opslachprobleem op te lossen, hienen wy twa platfoarmkeuzes: Kubernetes en OpenStack. Mar om't dat lêste nochal meunsterlik sjocht (sjoch mar nei de arsjitektuer om hjirfan oertsjûge te wurden), setten wy ús op Kubernetes nei wenjen. In oar argumint yn syn foardiel wie de relatyf ienfâldige softwarekontrôle, de mooglikheid om sels hardwareknooppunten fleksibeler te snijen neffens boarnen.
Parallel mei it behearskjen fan Kubernetes sels, hawwe wy ek studearre manieren om gegevens op te slaan, wylst wy al ús opslach yn Kubernetes op ús eigen hardware hâlde, krigen wy poerbêste saakkundigens. Alles wat wy doe op Kubernetes hienen libbe: statefull opslach, tafersjochsysteem, CI / CD. Kubernetes is in alles-yn-ien platfoarm wurden foar ús.
Mar wy woenen wurkje mei Kubernetes as in tsjinst, en net meidwaan oan syn stipe en ûntwikkeling. Plus, wy hâlde net fan hoefolle it ús koste om it op blank metaal te behâlden, en wy hienen konstant ûntwikkeling nedich! Bygelyks, ien fan 'e earste taken wie om Kubernetes Ingress-controllers te yntegrearjen yn' e netwurkynfrastruktuer fan ús organisaasje. Dit is in omslachtige taak, benammen yn betinken nommen dat op dat stuit neat klear wie foar programmatysk boarnebehear lykas DNS-records of de tawizing fan IP-adressen. Letter binne wy begûn te eksperimintearjen mei eksterne gegevens opslach. Wy kamen noait by it ymplementearjen fan de PVC-controller, mar sels doe waard it dúdlik dat dit in grut wurkgebiet wie dat tawijde spesjalisten easke.
Oerskeakelje nei Google Cloud Platform is in tydlike oplossing
Wy realisearre dat dit net trochgean koe, en ferpleatse ús gegevens fan blank metaal nei Google Cloud Platform. Yn feite wiene d'r op dat stuit net in protte nijsgjirrige opsjes foar in Russyske bedriuw: neist Google Cloud Platform hat allinich Amazon in ferlykbere tsjinst oanbean, mar wy hawwe noch altyd fêststeld op 'e oplossing fan Google. Dan like it ús ekonomysk rendabeler, tichter by Upstream, net te hawwen oer it feit dat Google sels in soarte fan PoC Kubernetes yn produksje is.
It earste grutte probleem ferskynde oan 'e hoarizon doe't ús klantenbasis groeide. Doe't wy de needsaak hiene om persoanlike gegevens op te slaan, stiene wy foar in kar: of wy wurkje mei Google en brekke Russyske wetten, of wy sykje in alternatyf yn 'e Russyske Federaasje. De kar wie oer it algemien foarsisber. 🙂
Hoe wy seagen de ideale wolk tsjinst
Oan it begjin fan it sykjen wisten wy al wat wy woene krije fan 'e takomstige wolkprovider. Hokker tsjinst sochten wy:
- Fluch en fleksibel. Sadat wy op elk momint fluch in nij knooppunt kinne tafoegje of wat ynsette.
- Goedkeap. Wy wiene tige soargen oer de finansjele kwestje, om't wy wiene beheind yn middels. Wy wisten al dat wy mei Kubernetes wolle wurkje, en no wie de taak om de kosten te minimalisearjen om de effisjinsje fan it brûken fan dizze oplossing te fergrutsjen of op syn minst te behâlden.
- automatisearre. Wy planden om te wurkjen mei de tsjinst fia de API, sûnder managers en tillefoantsjes of situaasjes wêr't wy ferskate tsientallen knopen manuell moatte ferheegje yn needmodus. Om't de measte fan ús prosessen automatisearre binne, ferwachten wy itselde fan 'e wolktsjinst.
- Mei tsjinners yn 'e Russyske Federaasje. Fansels hawwe wy plannen om te foldwaan oan Russyske wetjouwing en dyselde 152-FZ.
Op dat stuit wiene d'r in pear Kubernetes aaS-oanbieders yn Ruslân, en by it kiezen fan in provider wie it wichtich foar ús om ús prioriteiten net te kompromittearjen. It team fan Mail.ru Cloud Solutions, mei wa't wy begon te wurkjen en noch altyd gearwurkje, levere ús in folslein automatisearre tsjinst, mei API-stipe en in handich kontrôlepaniel dat Horizon omfettet - dêrmei koenen wy fluch in willekeurige oantal knopen ophelje.
Hoe't wy it slagge om te migrearjen nei MCS yn twa oeren
Yn sokke bewegingen hawwe in protte bedriuwen swierrichheden en tsjinslaggen, mar yn ús gefal wiene d'r gjin. Wy wiene gelok: om't wy al oan Kubernetes wurken foardat de migraasje begon, hawwe wy gewoan trije bestannen korrizjearre en ús tsjinsten lansearre op it nije wolkplatfoarm, MCS. Lit my jo herinnerje dat wy tsjin dy tiid einlings blank metaal hienen ferlitten en op it Google Cloud Platform wennen. Dêrom naam de ferhuzing sels net mear as twa oeren, plus in bytsje mear tiid (sawat in oere) waard bestege oan it kopiearjen fan gegevens fan ús apparaten. Doe brûkten wy al Spinnaker (in multi-cloud CD-tsjinst om Continuous Delivery te leverjen). Wy hawwe it ek gau tafoege oan it nije kluster en wurken lykas gewoanlik.
Mei tank oan de automatisearring fan ûntwikkeling prosessen en CI / CD, Kubernetes by URUS wurdt behannele troch ien spesjalist (en dat bin ik). Op in stuit wurke in oare systeembehearder mei my, mar doe die bliken dat wy al de haadroutine al automatisearre hiene en d'r wiene hieltyd mear taken fan 'e kant fan ús haadprodukt en it wie logysk om middels hjirop te rjochtsjen.
Wy krigen wat wy ferwachte fan 'e wolkprovider, om't wy sûnder yllúzjes mei gearwurking begon. As d'r ynsidinten wiene, wiene se meast technysk en dejingen dy't maklik wurde kinne ferklearre troch de relative frisheid fan 'e tsjinst. It wichtichste is dat it MCS-team fluch tekoarten elimineert en rap reagearret op fragen yn boaden.
As ik myn ûnderfining fergelykje mei Google Cloud Platform, yn har gefal wist ik net iens wêr't de feedbackknop wie, om't d'r gewoan gjin ferlet wie. En as der problemen wiene, stjoerde Google sels iensidich notifikaasjes út. Mar yn it gefal fan MCS tink ik dat it grutte foardiel is dat se sa ticht mooglik by Russyske kliïnten binne - sawol geografysk as mentaal.
Hoe sjogge wy wurkje mei wolken yn 'e takomst
No is ús wurk nau bûn oan Kubernetes, en it past ús folslein út it eachpunt fan ynfrastruktuertaken. Dêrom binne wy net fan plan om dêr oeral fan te migrearjen, hoewol wy konstant nije praktiken en tsjinsten yntrodusearje om routinetaken te ferienfâldigjen en nije te automatisearjen, de stabiliteit en betrouberens fan tsjinsten te fergrutsjen ... Wy lansearje no de Chaos Monkey-tsjinst (spesifyk , wy brûke chaoskube, mar dit feroaret it konsept net: ), dy't oarspronklik makke waard troch Netflix. Chaos Monkey docht ien ienfâldich ding: it wisket in willekeurige Kubernetes-pod op in willekeurige tiid. Dit is nedich foar ús tsjinst om normaal te libjen mei it oantal ynstânsjes n–1, dus traine wy ússels om taret te wêzen op alle problemen.
No sjoch ik it gebrûk fan oplossingen fan tredden - deselde wolkplatfoarms - as it ienige goede ding foar jonge bedriuwen. Meastentiids binne se oan it begjin fan har reis beheind yn boarnen, sawol minsklik as finansjeel, en it bouwen en ûnderhâlden fan har eigen wolk as datasintrum is te djoer en arbeidsintensyf. Wolke-oanbieders kinne jo dizze kosten minimalisearje; jo kinne fluch fan har de boarnen krije dy't nedich binne foar de eksploitaasje fan tsjinsten hjir en no, en betelje foar dizze boarnen nei it feit. Wat it URUS-bedriuw oangiet, sille wy no trou bliuwe oan Kubernetes yn 'e wolk. Mar wa wit, moatte wy miskien geografysk útwreidzje, of oplossingen ymplementearje basearre op wat spesifike apparatuer. Of miskien sil de hoemannichte konsumearre boarnen eigen Kubernetes rjochtfeardigje op bare-metaal, lykas yn 'e goede âlde dagen. 🙂
Wat wy leard hawwe fan it wurkjen mei wolktsjinsten
Wy begûnen mei Kubernetes op blank metaal, en sels dêr wie it goed op syn eigen manier. Mar syn sterke punten waarden krekt iepenbiere as in aaS-komponint yn 'e wolk. As jo in doel ynstelle en alles safolle mooglik automatisearje, kinne jo it sluten fan ferkeapers foarkomme en it ferpleatsen tusken wolkproviders sil in pear oeren duorje, en de senuwsellen sille by ús bliuwe. Wy kinne oare bedriuwen advisearje: as jo jo eigen (wolk) tsjinst wolle lansearje, mei beheinde boarnen en maksimale snelheid foar ûntwikkeling, begjin no direkt mei it hieren fan wolkboarnen, en bou jo datasintrum neidat Forbes oer jo skriuwt.
Boarne: www.habr.com