URUS-virksomheden prøvede Kubernetes i forskellige former: uafhængig implementering på bare metal, i Google Cloud og overførte derefter sin platform til Mail.ru Cloud Solutions (MCS)-skyen. Igor Shishkin fortæller, hvordan de valgte en ny cloud-udbyder, og hvordan det lykkedes dem at migrere til den på rekordhøje to timer (), senior systemadministrator hos URUS.
Hvad laver URUS?
Der er mange måder at forbedre kvaliteten af bymiljøet på, og en af dem er at gøre det miljøvenligt. Det er præcis, hvad firmaet URUS - Smart Digital Services arbejder på. Her implementerer de løsninger, der hjælper virksomheder med at overvåge vigtige miljøindikatorer og reducere deres negative påvirkning af miljøet. Sensorer indsamler data om luftsammensætning, støjniveau og andre parametre og sender dem derefter til den forenede URUS-Ekomon platform for analyse og anbefalinger.
Hvordan URUS virker indefra
En typisk kunde hos URUS er en virksomhed beliggende i eller i nærheden af et boligområde. Dette kan være en fabrik, en havn, et jernbanedepot eller en hvilken som helst anden facilitet. Hvis vores klient allerede har modtaget en advarsel, fået en bøde for miljøforurening, eller ønsker at støje mindre, reducere mængden af skadelige emissioner, kommer han til os, og vi tilbyder ham allerede en færdig løsning til miljøovervågning.
H2S-koncentrationsovervågningsgrafen viser regelmæssige natlige emissioner fra et nærliggende anlæg
De enheder, som vi bruger hos URUS, indeholder flere sensorer, der indsamler information om indholdet af bestemte gasser, støjniveauer og andre data for at vurdere miljøsituationen. Det nøjagtige antal sensorer bestemmes altid af den specifikke opgave.
Afhængigt af målingernes specifikationer kan enheder med sensorer placeres på væggene i bygninger, pæle og andre vilkårlige steder. Hver sådan enhed indsamler information, samler den og sender den til den datamodtagende gateway. Der gemmer vi dataene til langtidslagring og forbehandler dem til efterfølgende analyse. Det enkleste eksempel på, hvad vi får som resultat af analyser, er luftkvalitetsindekset, også kendt som AQI.
Sideløbende opererer mange andre tjenester på vores platform, men de er hovedsageligt af servicekarakter. For eksempel sender notifikationstjenesten meddelelser til kunder, hvis nogen af de overvågede parametre (f.eks. CO2-indhold) overstiger den tilladte værdi.
Hvordan vi opbevarer data. Historien om Kubernetes på bar metal
URUS miljøovervågningsprojekt har flere datavarehuse. I en opbevarer vi "rå" data - hvad vi modtog direkte fra selve enhederne. Denne opbevaring er et "magnetisk" bånd, ligesom på gamle kassettebånd, med en historie med alle indikatorer. Den anden type lagring bruges til forbehandlede data - data fra enheder, beriget med metadata om forbindelser mellem sensorer og aflæsningerne af selve enhederne, tilknytning til organisationer, lokationer osv. Denne information giver dig mulighed for dynamisk at vurdere, hvordan en bestemt indikator har ændret sig over en vis periode. Vi bruger den "rå" datalagring blandt andet som backup og til gendannelse af forbehandlede data, hvis et sådant behov opstår.
Da vi søgte at løse vores lagringsproblem for flere år siden, havde vi to platformsvalg: Kubernetes og OpenStack. Men da sidstnævnte ser ret monstrøs ud (se bare på dens arkitektur for at blive overbevist om dette), slog vi os ned på Kubernetes. Et andet argument til fordel var den relativt enkle softwarekontrol, muligheden for mere fleksibelt at skære selv hardwarenoder i henhold til ressourcer.
Parallelt med at mestre selve Kubernetes, undersøgte vi også måder at gemme data på, mens vi holdt al vores lager i Kubernetes på vores egen hardware, vi modtog fremragende ekspertise. Alt, hvad vi dengang havde boet på Kubernetes: statefull storage, overvågningssystem, CI/CD. Kubernetes er blevet en alt-i-en platform for os.
Men vi ønskede at arbejde med Kubernetes som en tjeneste og ikke engagere os i dens support og udvikling. Plus, vi kunne ikke lide, hvor meget det kostede os at vedligeholde det på bart metal, og vi havde brug for udvikling konstant! For eksempel var en af de første opgaver at integrere Kubernetes Ingress-controllere i netværksinfrastrukturen i vores organisation. Dette er en besværlig opgave, især i betragtning af, at intet på det tidspunkt var klar til programmatisk ressourcestyring såsom DNS-poster eller tildeling af IP-adresser. Senere begyndte vi at eksperimentere med ekstern datalagring. Vi nåede aldrig at implementere PVC-controlleren, men allerede da blev det klart, at dette var et stort arbejdsområde, der krævede dedikerede specialister.
At skifte til Google Cloud Platform er en midlertidig løsning
Vi indså, at dette ikke kunne fortsætte, og flyttede vores data fra bare metal til Google Cloud Platform. Faktisk var der på det tidspunkt ikke mange interessante muligheder for et russisk firma: Udover Google Cloud Platform tilbød kun Amazon en lignende tjeneste, men vi slog os stadig fast på løsningen fra Google. Så forekom det os mere økonomisk rentabelt, tættere på Upstream, for ikke at nævne det faktum, at Google selv er en slags PoC Kubernetes i produktion.
Det første store problem dukkede op i horisonten, efterhånden som vores kundebase voksede. Da vi havde et behov for at gemme personlige data, stod vi over for et valg: enten arbejder vi med Google og overtræder russiske love, eller vi leder efter et alternativ i Den Russiske Føderation. Valget var i det hele taget forudsigeligt. 🙂
Hvordan vi så den ideelle cloud-tjeneste
Ved begyndelsen af søgningen vidste vi allerede, hvad vi ønskede at få fra den fremtidige cloud-udbyder. Hvilken service ledte vi efter:
- Hurtig og fleksibel. Sådan at vi hurtigt kan tilføje en ny node eller implementere noget til enhver tid.
- Billig. Vi var meget bekymrede over det økonomiske spørgsmål, da vi var begrænsede i ressourcer. Vi vidste allerede, at vi ville arbejde med Kubernetes, og nu var opgaven at minimere omkostningerne for at øge eller i det mindste bevare effektiviteten ved at bruge denne løsning.
- automatiseret. Vi planlagde at arbejde med tjenesten gennem API'en uden ledere og telefonopkald eller situationer, hvor vi manuelt skulle hæve flere dusin noder i nødtilstand. Da de fleste af vores processer er automatiserede, forventede vi det samme fra cloud-tjenesten.
- Med servere i Den Russiske Føderation. Selvfølgelig planlagde vi at overholde russisk lovgivning og den samme 152-FZ.
På det tidspunkt var der få Kubernetes aaS-udbydere i Rusland, og når vi skulle vælge 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, forsynede os med en fuldautomatisk service med API-understøttelse og et praktisk kontrolpanel, der inkluderer Horizon - med det kunne vi hurtigt hæve et vilkårligt antal noder.
Hvordan det lykkedes os at migrere til MCS på to timer
I sådanne træk står mange virksomheder over for vanskeligheder og tilbageslag, men i vores tilfælde var der ingen. Vi var heldige: Da vi allerede arbejdede på Kubernetes før migreringen begyndte, rettede vi blot tre filer og lancerede vores tjenester på den nye cloudplatform, MCS. Lad mig minde dig om, at vi på det tidspunkt endelig havde forladt bare metal og boet på Google Cloud Platform. Derfor tog selve flytningen ikke mere end to timer, plus der blev brugt lidt mere tid (cirka en time) på at kopiere data fra vores enheder. Dengang brugte vi allerede Spinnaker (en multi-cloud CD-tjeneste til at levere kontinuerlig levering). Vi tilføjede det også hurtigt til den nye klynge og fortsatte med at arbejde som normalt.
Takket være automatiseringen af udviklingsprocesser og CI/CD håndteres Kubernetes hos URUS af én specialist (og det er mig). På et tidspunkt arbejdede en anden systemadministrator sammen med mig, men så viste det sig, at vi allerede havde automatiseret al hovedrutinen, og der kom flere og flere opgaver fra vores hovedprodukts side, og det gav mening at dirigere ressourcer til dette.
Vi modtog, hvad vi forventede fra cloud-udbyderen, siden vi begyndte samarbejdet uden illusioner. Hvis der var nogen hændelser, var de for det meste tekniske og dem, der let kunne forklares med den relative friskhed af tjenesten. Det vigtigste er, at MCS-teamet hurtigt eliminerer mangler og hurtigt svarer på spørgsmål i messengers.
Hvis jeg sammenligner min erfaring med Google Cloud Platform, vidste jeg i deres tilfælde ikke engang, hvor feedback-knappen var, da der simpelthen ikke var behov for det. Og hvis der opstod problemer, sendte Google selv meddelelser ensidigt. Men i tilfældet med MCS, tror jeg, at den store fordel er, at de er så tæt som muligt på russiske kunder – både geografisk og mentalt.
Hvordan ser vi arbejdet med skyer i fremtiden
Nu er vores arbejde tæt knyttet til Kubernetes, og det passer os fuldstændig ud fra infrastrukturopgavernes synspunkt. Derfor planlægger vi ikke at migrere fra det nogen steder, selvom vi konstant introducerer ny praksis og tjenester for at forenkle rutineopgaver og automatisere nye, øge stabiliteten og pålideligheden af tjenester... Vi lancerer nu Chaos Monkey-tjenesten (specifikt , vi bruger chaoskube, men det ændrer ikke på konceptet: ), som oprindeligt blev skabt af Netflix. Chaos Monkey gør en simpel ting: den sletter en tilfældig Kubernetes-pod på et tilfældigt tidspunkt. Dette er nødvendigt for, at vores service kan leve normalt med antallet af instanser n–1, så vi træner os selv i at være forberedte på eventuelle problemer.
Nu ser jeg brugen af tredjepartsløsninger – de samme cloud-platforme – som det eneste rigtige for unge virksomheder. Normalt, i begyndelsen af deres rejse, er de begrænsede i ressourcer, både menneskelige og økonomiske, og det er for dyrt og arbejdskrævende at bygge og vedligeholde deres egen cloud eller datacenter. Cloud-udbydere giver dig mulighed for at minimere disse omkostninger; du kan hurtigt få de nødvendige ressourcer fra dem til driften af tjenester her og nu, og betale for disse ressourcer bagefter. Hvad angår URUS-virksomheden, vil vi forblive tro mod Kubernetes i skyen indtil videre. 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 egne Kubernetes på bare-metal, som i de gode gamle dage. 🙂
Hvad vi lærte af at arbejde med cloud-tjenester
Vi begyndte at bruge Kubernetes på bar metal, og selv der var det godt på sin egen måde. Men dens styrker blev afsløret netop som en aaS-komponent i skyen. Hvis du sætter dig et mål og automatiserer alt så meget som muligt, vil du kunne undgå leverandørlåsning og flytning mellem cloud-udbydere vil tage et par timer, og nervecellerne bliver hos os. Vi kan rådgive andre virksomheder: Hvis du ønsker at lancere din egen (sky)-tjeneste med begrænsede ressourcer og maksimal hastighed til udvikling, så start allerede nu med at leje cloud-ressourcer, og byg dit datacenter, efter Forbes har skrevet om dig.
Kilde: www.habr.com