Virksomheden «URUS» har prøvet Kubernetes på forskellige måder: selvstændig deployment på bare metal, i Google Cloud, og derefter flyttede de deres platform til Mail.ru Cloud Solutions (MCS). Hvordan de valgte en ny cloud-udbyder, og hvordan de lykkedes med at migrere til denne på rekordtid, fortæller Igor Shishkin (), senior systemadministrator hos «URUS».
Hvad laver «URUS»
Der er mange måder at forbedre kvaliteten af det urbane miljø på, og en af dem er at gøre det miljøvenligt. Præcis dette arbejder firmaet «URUS — Smarte digitale tjenester» på. Her implementeres løsninger, der hjælper virksomheder med at overvåge vigtige miljømæssige indikatorer og reducere den negative indvirkning på miljøet. Sensorer indsamler data om luftens sammensætning, lydniveau og andre parametre og sender dem derefter til en central platform «URUS — Ecomon» til analyse og udarbejdelse af anbefalinger.
Hvordan «URUS» fungerer fra indersiden
Den typiske kunde hos «URUS» er en virksomhed, der er placeret i en boligzone eller tæt på en. Det kan være en fabrik, en havn, et jernbanedepot eller en anden type anlæg. Hvis vores kunde allerede har modtaget en advarsel, er blevet bødebelagt for forurening af miljøet, eller ønsker at udlede mindre støj og reducere mængden af skadelige emissioner, henvender han sig til os, og vi tilbyder ham en klar løsning til miljøovervågning.
Grafen der overvåger koncentrationen af H2S viser regelmæssige nattelige emissioner fra den nærliggende virksomhed
De enheder, vi bruger i «URUS», indeholder flere sensorer, der indsamler information om indholdet af bestemte gasser, lydniveau og andre data til vurdering af den miljømæssige situation. Det præcise antal sensorer bestemmes altid af den specifikke opgave.
Afhængig af målingernes karakter kan enheder med sensorer placeres på bygningsvægge, stolper og andre vilkårlige steder. Hver sådan enhed indsamler information, aggregerer den og sender den til dataindsamlingsgatewayen. Her gemmer vi dataene til langtidslagring og forbehandler dem til efterfølgende analyse. Et simpelt eksempel på, hvad vi får ud af analysen, er luftkvalitetsindekset, også kaldet AQI.
Samtidig kører mange andre tjenester på vores platform, men de har hovedsageligt en supportfunktion. For eksempel sender notifikationsservicen beskeder til kunderne, hvis nogen af de overvågede parametre (lad os sige CO2-indholdet) overstiger den acceptable grænse.
Hvordan vi opbevarer data. Historien om Kubernetes på bare metal.
I projektet for økmonitorering 'URUS' findes der flere datalagre. I det ene opbevarer vi de 'rå' data - det, vi har fået direkte fra enhederne. Dette lager fungerer som et 'magnetbånd', ligesom de gamle kassettebånd, med historien om alle målinger. Den anden type lager bruges til forbehandlede data - data fra enheder, beriget med metadata om sensorernes relationer og selve enhedernes målinger, tilknytning til organisationer, beliggenhed osv. Disse oplysninger gør det muligt at vurdere, hvordan en bestemt måling har ændret sig over en given tidsperiode. Vi bruger lageret af 'rå' data også som backup og til at gendanne de forbehandlede data, hvis der skulle opstå behov for det.
Da vi for flere år siden søgte efter en løsning til lagringsproblemet, havde vi to muligheder for valg af platform: Kubernetes og OpenStack. Men da den sidstnævnte ser temmelig monstrøs ud (bare se på dens arkitektur for at overbevise dig selv om det), valgte vi netop Kubernetes. Et andet argument for det var den relativt enkle programkontrol og muligheden for mere fleksibelt at fordele selv fysiske noder efter ressourcer.
Samtidig med at vi blev fortrolige med Kubernetes, studerede vi også metoder til datalagring. Da vi holdt alle vores lagre i Kubernetes på eget udstyr, opnåede vi fremragende ekspertise. Alt, hvad vi havde dengang, kørte på Kubernetes: stateful-lagring, overvågningssystem, CI/CD. Kubernetes blev for os en all-in-one platform.
Men vi ønskede at arbejde med Kubernetes som en service og ikke skulle håndtere vedligeholdelse og udvikling. Derudover kunne vi ikke lide de omkostninger, det medførte at køre det på bare metal, og der var konstant behov for udvikling! For eksempel blev en af de første opgaver at integrere Kubernetes Ingress-controllere i vores organisations netværksinfrastruktur. Dette var en omfattende opgave, især når man tænker på, at der på det tidspunkt ikke var noget klar til programmatisk styring af ressourcer som DNS-poster eller tildeling. IP-adresser. Senere begyndte vi at eksperimentere med eksterne datalagringsløsninger. Vi nåede aldrig at implementere PVC-controlleren, men vi indså allerede dengang, at det var et stort arbejdsmateriale, for hvilket vi skulle afsætte specialister.
Overgangen til Google Cloud Platform — en midlertidig løsning
Vi indså, at dette ikke kunne fortsætte, og vi overførte vores data fra bare metal til Google Cloud Platform. Faktisk var der dengang ikke så mange interessante muligheder for et russisk firma: udover Google Cloud Platform tilbød kun Amazon en lignende service, men vi valgte alligevel Googles løsning. Det virkede mere økonomisk fordelagtigt, tættere på Upstream, for ikke at nævne, at Google i sig selv er en slags PoC Kubernetes i produktion.
Det første alvorlige problem dukkede op parallel med, at vores kundebase voksede. Da vi fik behov for at opbevare personlige data, stod vi over for valget: enten arbejder vi sammen med Google og overtræder russisk lovgivning, eller søger vi efter et alternativ i Rusland. Valget var i bund og grund forudsigeligt. 🙂
Sådan forestillede vi os den ideelle cloud-service
Ved begyndelsen af vores søgen vidste vi allerede, hvad vi ønskede at få fra den fremtidige cloud-udbyder. Hvilken service søgte vi:
- Hurtig og fleksibel. En sådan, så vi hurtigt kunne tilføje en ny node eller deploye noget.
- Billig. Vi var meget bekymrede over de finansielle forhold, da vi var begrænset i vores ressourcer. Vi vidste allerede, at vi ønskede at arbejde med Kubernetes, og nu var opgaven at minimere omkostningerne for at øge eller i det mindste bevare effektiviteten af denne løsning.
- Automatiseret. Vi planlagde at arbejde med tjenesten via API'et, uden ledere, telefonopkald eller situationer, hvor vi skulle oprette adskillige noder manuelt i en hast. Da de fleste af vores processer er automatiserede, forventede vi det samme fra cloud-tjenesten.
- Med servere i Rusland. Selvfølgelig planlagde vi at overholde russisk lovgivning og den såkaldte 152-FZ.
På det tidspunkt var der få Kubernetes-udbydere efter aaS-modellen i Rusland, og i valg af udbyder var det vigtigt for os ikke at gå på kompromis med vores prioriteter. Mail.ru Cloud Solutions-teamet, som vi begyndte at arbejde med og stadig samarbejder med, tilbød os en fuldt automatiseret tjeneste med API-understøttelse og et brugervenligt kontrolpanel, hvor der er Horizon – med det kunne vi hurtigt oprette et vilkårligt antal noder.
Hvordan vi migrede til MCS på to timer
I sådanne flytninger støder mange virksomheder på vanskeligheder og fiaskoer, men i vores tilfælde var der ingen. Vi var heldige: Da vi før migrationen allerede arbejdede på Kubernetes, skulle vi blot justere tre filer og starte vores tjenester på den nye cloud-platform, i MCS. Jeg vil minde om, at vi på det tidspunkt helt havde forladt bare metal og boede på Google Cloud Platform. Så selve flytningen tog ikke mere end to timer, plus lidt tid (cirka en time) gik på at kopiere data fra vores enheder. På det tidspunkt brugte vi allerede Spinnaker (en multi-cloud CD-tjeneste til at sikre kontinuerlig levering). Det tilføjede vi også hurtigt til det nye cluster og fortsatte med at arbejde i normal drift.
Takket være automatiseringen af udviklingsprocesserne og CI/CD i Kubernetes arbejdes der i «УРУС» af én specialist (og det er mig). På et tidspunkt arbejdede jeg sammen med en anden systemadministrator, men det viste sig, at vi allerede havde automatiseret hele den grundlæggende rutine, og fra vores hovedproduktionsside vokser opgaverne, så det giver mening at målrette ressourcerne imod det.
Vi har fået det, vi forventede fra cloududbyderen, da vi begyndte at samarbejde uden illusioner. Hvis der var nogen hændelser, var de mest tekniske og let forklarlige på grund af den relative nyhed af tjenesten. Det vigtigste er, at MCS-teamet hurtigt løser problemerne og reagerer hurtigt på spørgsmål i messenger.
Sammenlignet med oplevelsen med Google Cloud Platform, vidste jeg faktisk ikke, hvor knappen til feedback var, da jeg slet ikke havde brug for den. Hvis der opstod problemer, sendte Google ensidigt beskeder ud. Men i tilfælde af MCS ser jeg det som en stor fordel, at de er meget tæt på de russiske kunder — både geografisk og mentalt.
Hvordan vi ser arbejdet med cloud-løsninger i fremtiden
I øjeblikket er vores arbejde tæt bundet til Kubernetes, og det opfylder fuldt ud vores behov, når det kommer til infrastruktur. Derfor planlægger vi ikke at migrere væk fra det, selvom vi konstant indfører nye metoder og tjenester for at forenkle rutineopgaver, automatisere nye og forbedre stabilitet og pålidelighed af tjenesterne… Vi lancerer i øjeblikket tjenesten Chaos Monkey (konkret bruger vi chaoskube, men konceptet ændres ikke :), som oprindeligt blev lavet i Netflix. Chaos Monkey gør én simpel ting: den fjerner tilfældigt en pod i Kubernetes på vilkårlige tidspunkter. Det er nødvendigt for at sikre, at vores service fungerer godt med antallet af instanser n–1, så vi vænner os til at være forberedt på enhver form for problemer.
I dag ser jeg brugen af tredjepartsløsninger - de samme cloud-platforme - som den eneste rigtige løsning for nye virksomheder. Normalt er de i begyndelsen begrænsede i ressourcer, både menneskelige og finansielle, og det er for dyrt og ressourcekrævende at bygge og vedligeholde en egen cloud eller datacenter. Cloud-udbydere gør det muligt at minimere disse omkostninger, og man kan hurtigt få de ressourcer, der er nødvendige for at drive tjenesterne her og nu, og man betaler for disse ressourcer baseret på forbrug. Hvad angår virksomheden 'URUS', så vil vi indtil videre forblive tro mod Kubernetes i skyen. Men hvem ved, måske skal vi udvide geografisk eller implementere løsninger baseret på noget specifikt udstyr. Eller måske vil mængden af forbrugte ressourcer retfærdiggøre vores eget Kubernetes på bare metal, som i de gode gamle dage. 🙂
Hvad vi har lært af erfaringerne med cloud-tjenester
Vi begyndte at bruge Kubernetes på bare metal, og selv der var det godt på sin måde. Men det er virkelig i rollen som aaS-komponent i skyen, at dets stærke sider kommer til deres ret. Hvis man sætter sig et mål og automatiserer alt maksimalt, undgår man vendor lock-in, og flytningen mellem cloud-udbydere vil tage et par timer, mens nervecellerne forbliver i fred hos os. Til andre virksomheder kan vi anbefale: ønsker I at starte jeres egen (cloud) tjeneste med begrænsede ressourcer og maksimal hastighed i udviklingen - start med det samme med leje af cloud-ressourcer, og byg jeres eget datacenter efter at Forbes har skrevet om jer.
Kilde: habr.com
