Företaget «УРУС» har prövat Kubernetes i olika former: självständig installation på bare metal, i Google Cloud, och sedan flyttade de sin plattform till Mail.ru Cloud Solutions (MCS). Hur de valde en ny molnleverantör och hur de lyckades migrera till den på rekordlåga två timmar berättar Igor Shishkin (), senior systemadministratör på «УРУС».
Vad gör «УРУС»
Det finns många sätt att förbättra kvaliteten på stadsmiljön, och ett av dem är att göra den ekologiskt säker. Just det arbetas det med på företaget «УРУС — Smarta digitala tjänster». Här implementeras lösningar som hjälper företag att övervaka viktiga ekologiska parametrar och minska negativ påverkan på miljön. Sensorerna samlar in data om luftens sammansättning, ljudnivå och andra parametrar, för att sedan skicka dem till den enhetliga plattformen «УРУС — Экомон» för analys och rekommendationer.
Hur «УРУС» fungerar inifrån
Den typiska kunden till «УРУС» är ett företag som ligger i eller nära ett bostadsområde. Det kan vara en fabrik, hamn, järnvägsdepå eller någon annan anläggning. Om vår kund redan har fått en varning, blivit bötesbelagd för miljöförorening eller själv vill minska ljudnivån, minska skadliga utsläpp, kommer de till oss, och vi erbjuder dem en färdig lösning för ekologisk övervakning.
I övervakningsgrafen över H2S-koncentrationer syns regelbundna nattutsläpp från en anläggning i närheten.
De enheter vi använder på «УРУС» innehåller flera sensorer som samlar information om koncentrationen av vissa gaser, ljudnivå och andra data för att bedöma den ekologiska situationen. Det exakta antalet sensorer bestäms alltid av den specifika uppgiften.
Beroende på mätningarnas specifik fördelas sensorvårdande enheter på byggnader, stolpar och andra valfria platser. Varje sådan enhet samlar information, aggregerar den och skickar den till datamottagningsporten. Där sparar vi data för långvarig lagring och behandlar dem för efterföljande analys. Ett enkelt exempel på vad vi får ut efter analysen är luftkvalitetsindexet, även känt som AQI.
Parallellt finns det många andra tjänster på vår plattform, men de är huvudsakligen av stödjande karaktär. Till exempel skickar notifieringstjänsten meddelanden till kunderna om någon av de övervakade parametrarna (till exempel CO2-innehåll) överskrider det tillåtna värdet.
Hur vi lagrar data. Historien med Kubernetes på bare metal
I projektet för ekomonitorering "URUS" finns det flera datalagringar. I en av dem lagrar vi "råa" data – det vi har fått direkt från enheterna. Detta lagring fungerar som ett "magnetband", precis som de gamla kasetterna, med historik över alla mätningar. Den andra typen av lagring används för förbehandlade data – data från enheter berikade med metadata om sensoröverenskommelser och enheternas avläsningar, tillhörighet till organisationer, platser och så vidare. Denna information gör det möjligt att dynamiskt utvärdera hur en viss parameter har förändrats över en viss tidsperiod. Lagringen av "råa" data använder vi också som en backup och för återställning av förbehandlade data om behovet skulle uppstå.
När vi för några år sedan letade efter hur vi skulle lösa lagringsproblemet hade vi två alternativ för val av plattform: Kubernetes och OpenStack. Men eftersom det senare ser ganska monstruöst ut (bara titta på dess arkitektur för att se detta), valde vi just Kubernetes. Ett annat argument för dess fördelar var den relativt enkla programmeringshanteringen och möjligheten att mer flexibelt dela även hårdvarunoder efter resurser.
Parallellt med att vi bemästrade Kubernetes själv studerade vi också sätt att lagra data. Medan vi höll alla våra lagringar i Kubernetes på vår egen hårdvara, fick vi utmärkt expertis. Allt vi hade då levde just på Kubernetes: stateful-lagring, övervakningssystem, CI/CD. Kubernetes blev för oss en all-in-one plattform.
Men vi ville jobba med Kubernetes som en tjänst, snarare än att själva hantera och utveckla det. Dessutom gillade vi inte kostnaden för att hålla det på bare metal, och utveckling var något vi behövde kontinuerligt! Till exempel blev en av de första uppgifterna att integrera Kubernetes Ingress-kontroller i vår organisations nätverksinfrastruktur. Det är en omfattande uppgift, särskilt med tanke på att det då inte fanns något klart för att programhantera resurser som DNS-post eller tilldelning. IP-adresser. Senare började vi experimentera med extern datalagring. Vi lyckades aldrig implementera PVC-kontrollern, men redan då stod det klart att det var ett stort arbete som krävde speciella resurser.
Övergången till Google Cloud Platform — en tillfällig lösning.
Vi insåg att vi inte kunde fortsätta så här, och flyttade våra data från bare metal till Google Cloud Platform. Faktum är att det inte fanns många intressanta alternativ för ett ryskt företag vid den tidpunkten: förutom Google Cloud Platform erbjöd endast Amazon en liknande tjänst, men vi valde ändå Googles lösning. Det verkade vara mer kostnadseffektivt, mer i linje med Upstream, för att inte tala om att Google självt är en slags PoC Kubernetes i produktion.
Det första allvarliga problemet dök upp parallellt med att vår kundbas växte. När vi behövde lagra personuppgifter stod vi inför valet: antingen arbetar vi med Google och bryter mot ryska lagar, eller så söker vi en alternativ lösning i Ryssland. Valet var i stort sett förutsägbart. 🙂
Så som vi såg den ideala molntjänsten.
I början av vår sökning visste vi redan vad vi ville ha från vår framtida molnleverantör. Vilken tjänst letade vi efter:
- Snabb och flexibel. En sådan där vi snabbt skulle kunna lägga till en ny nod eller distribuera något när som helst.
- Billig. Vi var mycket bekymrade över de ekonomiska aspekterna, eftersom vi var begränsade i resurser. Vi visste redan att vi ville arbeta med Kubernetes, och nu var uppgiften att minimera kostnaden för detta för att öka eller åtminstone bibehålla effektiviteten i användningen av denna lösning.
- Automatiserad. Vi planerade att arbeta med tjänsten via API, utan chefer och telefonsamtal eller situationer där vi behöver manuellt skapa flera dussin noder i ett akutläge. Eftersom de flesta processer är automatiserade, förväntade vi oss detsamma från molntjänsten.
- Med servrar i Ryssland. Självklart planerade vi att följa rysk lagstiftning och den specifika 152-FZ.
Vid den tiden fanns det få Kubernetes-leverantörer i aaS-modellen i Ryssland, och när vi valde en leverantör var det viktigt för oss att inte kompromissa med våra prioriteringar. Teamet på Mail.ru Cloud Solutions, som vi började samarbeta med och fortfarande gör, tillhandahöll en helt automatiserad tjänst med API-stöd och en användarvänlig kontrollpanel, där det finns Horizon - med det kunde vi snabbt skapa önskat antal noder.
Hur vi lyckades migrera till MCS på två timmar
Vid sådana flyttar stöter många företag på svårigheter och misslyckanden, men i vårt fall fanns det inga. Vi hade tur: eftersom vi innan migrationen redan arbetade på Kubernetes, justerade vi bara tre filer och startade våra tjänster på den nya molnplattformen, MCS. Låt mig påminna att vi vid den tiden helt hade lämnat bare metal och levde på Google Cloud Platform. Så själva flytten tog inte mer än två timmar, plus lite tid (cirka en timme) gick åt till att kopiera data från våra enheter. Då använde vi redan Spinnaker (en multi-moln CD-tjänst för att säkerställa Continous Delivery). Den lade vi också snabbt till i den nya klustret och fortsatte arbeta som vanligt.
Tack vare automatiseringen av utvecklings- och CI/CD-processer hanteras Kubernetes i „URUS“ av en specialist (och det är jag). Vid något tillfälle arbetade en annan systemadministratör med mig, men det visade sig att vi redan hade automatiserat hela den huvudsakliga rutinen, och från sidan av vår huvudprodukt ökade uppgifterna, vilket gör det meningsfullt att rikta resurser mot detta.
Vi fick från molnleverantören vad vi förväntade oss, eftersom vi inledde samarbetet utan illusioner. Om det fanns några incidenter var det för det mesta tekniska och sådana som lätt kan förklaras med tjänstens relativa nyhet. Det viktigaste är att teamet på MCS snabbt åtgärdar brister och snabbt reagerar på frågor i meddelandetjänster.
Om man jämför erfarenheten av att arbeta med Google Cloud Platform, så visste jag inte ens var feedback-knappen fanns, eftersom det helt saknades behov. Och om några problem uppstod, skickade Google själva ut meddelanden ensidigt. Men i fallet med MCS anser jag att den stora fördelen är att de ligger nära ryska kunder — både geografiskt och mentalt.
Så här ser vi på framtiden för arbete med molntjänster
Just nu är vårt arbete tätt kopplat till Kubernetes, och det möter helt våra behov när det gäller infrastrukturella uppgifter. Därför planerar vi inte att migrera någonstans, även om vi ständigt inför nya metoder och tjänster för att förenkla rutinuppgifter och automatisera nya, samt öka stabiliteten och tillförlitligheten hos tjänsterna… Just nu lanserar vi tjänsten Chaos Monkey (konkret använder vi chaoskube, men konceptet förändras inte :), som ursprungligen skapades av Netflix. Chaos Monkey gör en enkel sak: den tar bort en slumpmässig pod i Kubernetes vid en godtycklig tidpunkt. Det är nödvändigt för att vår tjänst ska klara sig med antal instanser n–1, så vi vänjer oss vid att vara beredda på alla problem.
Just nu ser jag användningen av tredjepartslösningar — såsom molnplattformar — som det enda rätta för unga företag. Vanligtvis är de i början av sin resa begränsade i resurser, både när det gäller personal och finansiellt, och att bygga och underhålla eget moln eller datacenter är för dyrt och arbetskrävande. Molnleverantörer möjliggör att minimera dessa kostnader, man kan snabbt få resurser som behövs för att driva tjänsterna här och nu, och betala för dem efter verklig användning. När det gäller företaget "УРС", så kommer vi för tillfället att förbli trogna Kubernetes i molnet. Men vem vet, kanske måste vi expandera geografiskt, eller implementera lösningar baserade på något specifikt utrustning. Eller kanske kommer mängden använda resurser att motivera en egen Kubernetes på bare-metal, precis som i gamla goda tider. 🙂
Vad vi har lärt oss av erfarenheten av att arbeta med molntjänster
Vi har börjat använda Kubernetes på bare metal, och även där var det bra på sitt sätt. Men dess styrkor kom verkligen till sin rätt som en aaS-komponent i molnet. Om man sätter upp målet och maximerar automatiseringen kan man undvika vendor lock-in och flyttningen mellan molnleverantörer tar bara några timmar, och våra nervceller kommer att förbli i gott skick. Vi kan rådge andra företag: vill ni starta er egen (moln)tjänst med begränsade resurser och maximal hastighet för utveckling – börja direkt med att hyra molnressurser och bygg ert datacenter efter att ni blivit omskrivna av Forbes.
Källa: habr.com
