Die URUS-maatskappy het Kubernetes in verskillende vorme probeer: onafhanklike ontplooiing op kaal metaal, in Google Wolk, en het toe sy platform na die Mail.ru Cloud Solutions (MCS)-wolk oorgeplaas. Igor Shishkin vertel hoe hulle 'n nuwe wolkverskaffer gekies het en hoe hulle daarin geslaag het om binne 'n rekord twee uur daarheen te migreer (), senior stelseladministrateur by URUS.
Wat doen URUS?
Daar is baie maniere om die kwaliteit van die stedelike omgewing te verbeter, en een daarvan is om dit omgewingsvriendelik te maak. Dit is presies waaraan die URUS - Smart Digital Services-maatskappy werk. Hier implementeer hulle oplossings wat ondernemings help om belangrike omgewingsaanwysers te monitor en hul negatiewe impak op die omgewing te verminder. Sensors versamel data oor lugsamestelling, geraasvlak en ander parameters, en stuur dit dan na die verenigde URUS-Ekomon-platform vir ontleding en maak aanbevelings.
Hoe URUS van binne werk
'n Tipiese kliënt van URUS is 'n maatskappy wat in of naby 'n woongebied geleë is. Dit kan 'n fabriek, hawe, spoorwegdepot of enige ander fasiliteit wees. As ons kliënt reeds 'n waarskuwing ontvang het, beboet is vir omgewingsbesoedeling, of minder geraas wil maak, die hoeveelheid skadelike emissies wil verminder, kom hy na ons toe, en ons bied hom reeds 'n klaargemaakte oplossing vir omgewingsmonitering.
Die H2S-konsentrasiemoniteringsgrafiek toon gereelde nagvrystellings van 'n nabygeleë aanleg
Die toestelle wat ons by URUS gebruik, bevat verskeie sensors wat inligting insamel oor die inhoud van sekere gasse, geraasvlakke en ander data om die omgewingsituasie te assesseer. Die presiese aantal sensors word altyd deur die spesifieke taak bepaal.
Afhangende van die besonderhede van die metings, kan toestelle met sensors op die mure van geboue, pale en ander arbitrêre plekke geleë wees. Elke sodanige toestel samel inligting in, versamel dit en stuur dit na die data-ontvangspoort. Daar stoor ons die data vir langtermynberging en verwerk dit vooraf vir daaropvolgende ontleding. Die eenvoudigste voorbeeld van wat ons as gevolg van ontleding kry, is die luggehalte-indeks, ook bekend as AQI.
Terselfdertyd werk baie ander dienste op ons platform, maar hulle is hoofsaaklik van 'n diensaard. Byvoorbeeld, die kennisgewingdiens stuur kennisgewings aan kliënte indien enige van die gemonitorde parameters (byvoorbeeld CO2-inhoud) die toelaatbare waarde oorskry.
Hoe ons data stoor. Die verhaal van Kubernetes op kaal metaal
Die URUS-omgewingsmoniteringprojek het verskeie datapakhuise. In een hou ons "rou" data - wat ons direk van die toestelle self ontvang het. Hierdie stoor is 'n "magnetiese" band, soos op ou kassetbande, met 'n geskiedenis van alle aanwysers. Die tweede tipe berging word gebruik vir voorafverwerkte data - data vanaf toestelle, verryk met metadata oor verbindings tussen sensors en die lesings van die toestelle self, affiliasie met organisasies, liggings, ens. Hierdie inligting laat jou toe om dinamies te assesseer hoe 'n spesifieke aanwyser het verander oor 'n sekere tydperk. Ons gebruik die "rou" databerging, onder andere, as 'n rugsteun en vir die herstel van voorafverwerkte data, indien so 'n behoefte ontstaan.
Toe ons 'n paar jaar gelede ons bergingsprobleem wou oplos, het ons twee platformkeuses gehad: Kubernetes en OpenStack. Maar aangesien laasgenoemde nogal monsteragtig lyk (kyk net na sy argitektuur om hiervan oortuig te wees), het ons ons op Kubernetes gevestig. Nog 'n argument in sy guns was die relatief eenvoudige sagtewarebeheer, die vermoë om selfs hardeware nodusse volgens hulpbronne meer buigsaam te sny.
Parallel met die bemeestering van Kubernetes self, het ons ook maniere bestudeer om data te stoor, terwyl ons al ons berging in Kubernetes op ons eie hardeware gehou het, het ons uitstekende kundigheid ontvang. Alles wat ons toe gehad het, het op Kubernetes gewoon: staatvolle berging, moniteringstelsel, CI/CD. Kubernetes het 'n alles-in-een platform vir ons geword.
Maar ons wou met Kubernetes as 'n diens werk, en nie betrokke raak by die ondersteuning en ontwikkeling daarvan nie. Boonop het ons nie gehou van hoeveel dit ons gekos het om dit op kaal metaal te onderhou nie, en ons het voortdurend ontwikkeling nodig gehad! Byvoorbeeld, een van die eerste take was om Kubernetes Ingress-beheerders in die netwerkinfrastruktuur van ons organisasie te integreer. Dit is 'n omslagtige taak, veral as in ag geneem word dat op daardie stadium niks gereed was vir programmatiese hulpbronbestuur soos DNS-rekords of die toekenning van IP-adresse nie. Later het ons begin eksperimenteer met eksterne databerging. Ons het nooit by die implementering van die PVC-beheerder uitgekom nie, maar selfs toe het dit duidelik geword dat dit 'n groot werksgebied was wat toegewyde spesialiste vereis het.
Om oor te skakel na Google Cloud Platform is 'n tydelike oplossing
Ons het besef dat dit nie kon voortgaan nie, en het ons data van kaal metaal na Google Wolk-platform geskuif. Trouens, op daardie tydstip was daar nie baie interessante opsies vir 'n Russiese maatskappy nie: behalwe Google Cloud Platform, het net Amazon 'n soortgelyke diens aangebied, maar ons het steeds op die oplossing van Google besluit. Toe het dit vir ons meer ekonomies winsgewend gelyk, nader aan Stroomop, om nie te praat van die feit dat Google self 'n soort PoC Kubernetes in Produksie is nie.
Die eerste groot probleem het op die horison verskyn namate ons kliëntebasis gegroei het. Toe ons 'n behoefte gehad het om persoonlike data te stoor, het ons voor 'n keuse gestaan: óf ons werk met Google en oortree Russiese wette, óf ons soek 'n alternatief in die Russiese Federasie. Die keuse was oor die algemeen voorspelbaar. 🙂
Hoe ons die ideale wolkdiens gesien het
Teen die begin van die soektog het ons reeds geweet wat ons van die toekomstige wolkverskaffer wou kry. Watter diens het ons gesoek:
- Vinnig en buigsaam. Sodanig dat ons enige tyd vinnig 'n nuwe nodus kan byvoeg of iets kan ontplooi.
- Goedkoop. Ons was baie bekommerd oor die finansiële kwessie, aangesien ons beperk was in hulpbronne. Ons het reeds geweet dat ons met Kubernetes wil werk, en nou was die taak om die koste daarvan te verminder om die doeltreffendheid van die gebruik van hierdie oplossing te verhoog of ten minste te handhaaf.
- outomatiese. Ons het beplan om met die diens deur die API te werk, sonder bestuurders en telefoonoproepe of situasies waar ons 'n paar dosyn nodusse handmatig in noodmodus moet verhoog. Aangesien die meeste van ons prosesse geoutomatiseer is, het ons dieselfde van die wolkdiens verwag.
- Met bedieners in die Russiese Federasie. Natuurlik het ons beplan om aan Russiese wetgewing en daardie selfde 152-FZ te voldoen.
Op daardie tydstip was daar min Kubernetes aaS-verskaffers in Rusland, en wanneer ons 'n verskaffer kies, was dit vir ons belangrik om nie ons prioriteite in te boet nie. Die Mail.ru Cloud Solutions-span, met wie ons begin werk het en steeds saamwerk, het aan ons 'n ten volle outomatiese diens verskaf, met API-ondersteuning en 'n gerieflike beheerpaneel wat Horizon insluit - daarmee kon ons vinnig 'n arbitrêre aantal nodusse opbou.
Hoe ons daarin geslaag het om binne twee uur na MCS te migreer
In sulke skuiwe het baie maatskappye probleme en terugslae, maar in ons geval was daar geen. Ons was gelukkig: aangesien ons reeds aan Kubernetes gewerk het voordat die migrasie begin het, het ons eenvoudig drie lêers reggestel en ons dienste op die nuwe wolkplatform, MCS, bekendgestel. Laat ek jou herinner dat ons teen daardie tyd uiteindelik kaal metaal verlaat het en op die Google Wolk-platform gewoon het. Daarom het die skuif self nie meer as twee uur geneem nie, plus 'n bietjie meer tyd (ongeveer 'n uur) is bestee aan die kopiëring van data vanaf ons toestelle. Destyds het ons reeds Spinnaker ('n multi-wolk CD-diens om deurlopende aflewering te verskaf) gebruik. Ons het dit ook vinnig by die nuwe groepering gevoeg en voortgegaan om soos gewoonlik te werk.
Danksy die outomatisering van ontwikkelingsprosesse en CI/CD word Kubernetes by URUS deur een spesialis (en dit is ek) hanteer. Op 'n stadium het 'n ander stelseladministrateur saam met my gewerk, maar toe blyk dit dat ons al die hoofroetine reeds geoutomatiseer het en daar was al hoe meer take aan die kant van ons hoofproduk en dit het sin gemaak om hulpbronne hiertoe te rig.
Ons het ontvang wat ons van die wolkverskaffer verwag het, aangesien ons sonder illusies begin saamwerk het. As daar enige voorvalle was, was dit meestal tegnies en dié wat maklik verklaar kon word deur die relatiewe varsheid van die diens. Die belangrikste ding is dat die MCS-span vinnig tekortkominge uitskakel en vinnig op vrae in boodskappers reageer.
As ek my ervaring met Google Cloud Platform vergelyk, het ek in hul geval nie eers geweet waar die terugvoerknoppie was nie, aangesien dit eenvoudig nie nodig was nie. En as enige probleme wel voorgekom het, het Google self kennisgewings eensydig uitgestuur. Maar in die geval van MCS dink ek die groot voordeel is dat hulle so na as moontlik aan Russiese kliënte is – beide geografies en geestelik.
Hoe ons sien werk met wolke in die toekoms
Nou is ons werk nou gekoppel aan Kubernetes, en dit pas heeltemal by ons uit die oogpunt van infrastruktuurtake. Daarom beplan ons nêrens om daarvandaan te migreer nie, alhoewel ons voortdurend nuwe praktyke en dienste bekendstel om roetinetake te vereenvoudig en nuwes te outomatiseer, die stabiliteit en betroubaarheid van dienste te verhoog... Ons stel nou die Chaos Monkey-diens bekend (spesifiek , ons gebruik chaoskube, maar dit verander nie die konsep nie: ), wat oorspronklik deur Netflix geskep is. Chaos Monkey doen een eenvoudige ding: dit vee 'n ewekansige Kubernetes-peul op 'n ewekansige tyd uit. Dit is nodig vir ons diens om normaal te leef met die aantal gevalle n–1, so ons oefen onsself om voorbereid te wees vir enige probleme.
Nou sien ek die gebruik van derdeparty-oplossings – dieselfde wolkplatforms – as die enigste regte ding vir jong maatskappye. Gewoonlik, aan die begin van hul reis, is hulle beperk in hulpbronne, beide menslike en finansiële, en die bou en instandhouding van hul eie wolk of datasentrum is te duur en arbeidsintensief. Wolkverskaffers laat jou toe om hierdie koste te minimaliseer; jy kan vinnig van hulle die hulpbronne verkry wat nodig is vir die bedryf van dienste hier en nou, en later vir hierdie hulpbronne betaal. Wat die URUS-maatskappy betref, sal ons vir eers getrou bly aan Kubernetes in die wolk. Maar wie weet, ons sal dalk geografies moet uitbrei, of oplossings moet implementeer wat op een of ander spesifieke toerusting gebaseer is. Of dalk sal die hoeveelheid hulpbronne wat verbruik word, eie Kubernetes op kaalmetaal regverdig, soos in die goeie ou dae. 🙂
Wat ons geleer het uit die werk met wolkdienste
Ons het Kubernetes op kaal metaal begin gebruik, en selfs daar was dit goed op sy eie manier. Maar die sterkpunte daarvan is juis onthul as 'n aaS-komponent in die wolk. As jy 'n doelwit stel en alles so veel as moontlik outomatiseer, sal jy insluiting van verkopers kan vermy en sal dit 'n paar uur neem om tussen wolkverskaffers te beweeg, en die senuweeselle sal by ons bly. Ons kan ander maatskappye adviseer: as jy jou eie (wolk) diens wil begin, met beperkte hulpbronne en maksimum snelheid vir ontwikkeling, begin dadelik deur wolkhulpbronne te huur, en bou jou datasentrum nadat Forbes oor jou geskryf het.
Bron: will.com