URUS-företaget provade Kubernetes i olika former: oberoende distribution på bar metall, i Google Cloud och överförde sedan sin plattform till molnet Mail.ru Cloud Solutions (MCS). Igor Shishkin berättar hur de valde en ny molnleverantör och hur de lyckades migrera till den på rekordhöga två timmar (), senior systemadministratör på URUS.
Vad gör URUS?
Det finns många sätt att förbättra kvaliteten på stadsmiljön, och ett av dem är att göra den miljövänlig. Det är precis vad företaget URUS - Smart Digital Services arbetar med. Här implementerar de lösningar som hjälper företag att övervaka viktiga miljöindikatorer och minska deras negativa påverkan på miljön. Sensorer samlar in data om luftsammansättning, ljudnivå och andra parametrar och skickar dem sedan till den enhetliga URUS-Ekomon-plattformen för analys och rekommendationer.
Hur URUS fungerar från insidan
En typisk kund till URUS är ett företag beläget i eller nära ett bostadsområde. Detta kan vara en fabrik, hamn, järnvägsdepå eller någon annan anläggning. Om vår kund redan fått en varning, fått böter för miljöföroreningar eller vill bullra mindre, minska mängden skadliga utsläpp kommer han till oss och vi erbjuder honom redan en färdig lösning för miljöövervakning.
Grafen för övervakning av H2S-koncentrationen visar regelbundna nattliga utsläpp från en närliggande anläggning
De enheter som vi använder på URUS innehåller flera sensorer som samlar in information om innehållet i vissa gaser, ljudnivåer och annan data för att bedöma miljösituationen. Det exakta antalet sensorer bestäms alltid av den specifika uppgiften.
Beroende på detaljerna i mätningarna kan enheter med sensorer placeras på väggarna i byggnader, stolpar och andra godtyckliga platser. Varje sådan enhet samlar in information, aggregerar den och skickar den till datamottagningsgatewayen. Där sparar vi data för långtidslagring och förbearbetar den för efterföljande analys. Det enklaste exemplet på vad vi får som resultat av analys är luftkvalitetsindex, även känt som AQI.
Parallellt verkar många andra tjänster på vår plattform, men de är främst av tjänstekaraktär. Till exempel skickar aviseringstjänsten meddelanden till kunder om någon av de övervakade parametrarna (till exempel CO2-halt) överskrider det tillåtna värdet.
Hur vi lagrar data. Historien om Kubernetes på bar metall
Miljöövervakningsprojektet URUS har flera datalager. I ett lagrar vi "rå" data - vad vi fick direkt från själva enheterna. Denna lagring är ett "magnetiskt" band, som på gamla kassettband, med en historik över alla indikatorer. Den andra typen av lagring används för förbearbetade data - data från enheter, berikade med metadata om kopplingar mellan sensorer och avläsningarna av själva enheterna, anknytning till organisationer, platser etc. Denna information låter dig dynamiskt bedöma hur en viss indikator har förändrats under en viss tidsperiod. Vi använder den "råa" datalagringen bland annat som backup och för att återställa förbehandlad data, om ett sådant behov uppstår.
När vi ville lösa vårt lagringsproblem för flera år sedan hade vi två plattformsval: Kubernetes och OpenStack. Men eftersom den senare ser ganska monstruös ut (titta bara på dess arkitektur för att vara övertygad om detta), slog vi oss ner på Kubernetes. Ett annat argument till dess fördel var den relativt enkla mjukvarukontrollen, möjligheten att mer flexibelt skära till och med hårdvaru-noder efter resurser.
Parallellt med att vi behärskar själva Kubernetes studerade vi också sätt att lagra data, samtidigt som vi behöll all vår lagring i Kubernetes på vår egen hårdvara fick vi utmärkt expertis. Allt vi hade då levde på Kubernetes: statefull lagring, övervakningssystem, CI/CD. Kubernetes har blivit en allt-i-ett-plattform för oss.
Men vi ville arbeta med Kubernetes som en tjänst och inte engagera oss i dess support och utveckling. Dessutom gillade vi inte hur mycket det kostade oss att underhålla den på ren metall, och vi behövde utveckling ständigt! Till exempel var en av de första uppgifterna att integrera Kubernetes Ingress-kontroller i nätverksinfrastrukturen i vår organisation. Detta är en besvärlig uppgift, särskilt med tanke på att ingenting vid den tiden var redo för programmatisk resurshantering såsom DNS-poster eller tilldelning av IP-adresser. Senare började vi experimentera med extern datalagring. Vi kom aldrig igång med att implementera PVC-kontrollern, men redan då stod det klart att detta var ett stort arbetsområde som krävde dedikerade specialister.
Att byta till Google Cloud Platform är en tillfällig lösning
Vi insåg att detta inte kunde fortsätta och flyttade vår data från ren metall till Google Cloud Platform. Faktum är att det vid den tiden inte fanns många intressanta alternativ för ett ryskt företag: förutom Google Cloud Platform erbjöd bara Amazon en liknande tjänst, men vi bestämde oss ändå för lösningen från Google. Sedan verkade det för oss mer ekonomiskt lönsamt, närmare Upstream, för att inte tala om det faktum att Google i sig är ett slags PoC Kubernetes i produktion.
Det första stora problemet dök upp vid horisonten när vår kundbas växte. När vi hade ett behov av att lagra personuppgifter stod vi inför ett val: antingen arbetar vi med Google och bryter mot ryska lagar, eller så letar vi efter ett alternativ i Ryska federationen. Valet var på det hela taget förutsägbart. 🙂
Hur vi såg den perfekta molntjänsten
I början av sökningen visste vi redan vad vi ville få från den framtida molnleverantören. Vilken tjänst sökte vi:
- Snabb och flexibel. Sådant att vi snabbt kan lägga till en ny nod eller distribuera något när som helst.
- Billig. Vi var mycket oroade över den ekonomiska frågan, eftersom vi var begränsade i resurser. Vi visste redan att vi ville arbeta med Kubernetes, och nu var uppgiften att minimera dess kostnader för att öka eller åtminstone bibehålla effektiviteten i att använda denna lösning.
- automatiserad. Vi planerade att arbeta med tjänsten genom API:t, utan chefer och telefonsamtal eller situationer där vi manuellt behöver höja flera dussin noder i nödläge. Eftersom de flesta av våra processer är automatiserade förväntade vi oss detsamma från molntjänsten.
- Med servrar i Ryska federationen. Naturligtvis planerade vi att följa rysk lagstiftning och samma 152-FZ.
På den tiden fanns det få Kubernetes aaS-leverantörer i Ryssland, och när vi valde leverantör var det viktigt för oss att inte kompromissa med våra prioriteringar. Mail.ru Cloud Solutions-teamet, som vi började arbeta med och fortfarande samarbetar med, försåg oss med en helautomatisk tjänst, med API-stöd och en bekväm kontrollpanel som inkluderar Horizon – med den kunde vi snabbt öka ett godtyckligt antal noder.
Hur vi lyckades migrera till MCS på två timmar
I sådana rörelser möter många företag svårigheter och motgångar, men i vårt fall fanns det inga. Vi hade tur: eftersom vi redan arbetade med Kubernetes innan migreringen började korrigerade vi helt enkelt tre filer och lanserade våra tjänster på den nya molnplattformen MCS. Låt mig påminna dig om att vi vid den tiden äntligen hade lämnat bar metal och levt på Google Cloud Platform. Därför tog själva flytten inte mer än två timmar, plus att lite mer tid (ungefär en timme) gick åt till att kopiera data från våra enheter. Då använde vi redan Spinnaker (en CD-tjänst med flera moln för att tillhandahålla kontinuerlig leverans). Vi lade också snabbt till det i det nya klustret och fortsatte att arbeta som vanligt.
Tack vare automatiseringen av utvecklingsprocesser och CI/CD hanteras Kubernetes på URUS av en specialist (och det är jag). I något skede arbetade en annan systemadministratör med mig, men då visade det sig att vi redan hade automatiserat all huvudrutin och det blev fler och fler uppgifter från vår huvudprodukts sida och det var vettigt att styra resurser till detta.
Vi fick vad vi förväntade oss av molnleverantören, sedan vi inledde samarbetet utan illusioner. Om det inträffade några incidenter var de mestadels tekniska och de som lätt kunde förklaras av tjänstens relativa fräschör. Huvudsaken är att MCS-teamet snabbt eliminerar brister och snabbt svarar på frågor i meddelanden.
Om jag jämför min erfarenhet med Google Cloud Platform, i deras fall visste jag inte ens var feedbackknappen var, eftersom det helt enkelt inte fanns något behov av den. Och om några problem uppstod skickade Google själv ut meddelanden ensidigt. Men i fallet med MCS tror jag att den stora fördelen är att de är så nära ryska kunder som möjligt – både geografiskt och mentalt.
Hur vi ser på att arbeta med moln i framtiden
Nu är vårt arbete nära knutet till Kubernetes, och det passar oss helt ur synvinkeln av infrastrukturuppgifter. Därför planerar vi inte att migrera från det någonstans, även om vi ständigt introducerar nya metoder och tjänster för att förenkla rutinuppgifter och automatisera nya, öka stabiliteten och tillförlitligheten hos tjänster... Vi lanserar nu tjänsten Chaos Monkey (specifikt , vi använder chaoskube, men detta ändrar inte konceptet: ), som ursprungligen skapades av Netflix. Chaos Monkey gör en enkel sak: den tar bort en slumpmässig Kubernetes-pod vid en slumpmässig tidpunkt. Detta är nödvändigt för att vår tjänst ska leva normalt med antalet instanser n–1, så vi tränar oss för att vara beredda på eventuella problem.
Nu ser jag användningen av tredjepartslösningar – samma molnplattformar – som det enda rätta för unga företag. Vanligtvis, i början av sin resa, är de begränsade i resurser, både mänskliga och ekonomiska, och att bygga och underhålla ett eget moln eller datacenter är för dyrt och arbetskrävande. Molnleverantörer tillåter dig att minimera dessa kostnader; du kan snabbt få de resurser som krävs för driften av tjänster här och nu från dem och betala för dessa resurser i efterhand. När det gäller URUS-företaget kommer vi att förbli trogna Kubernetes i molnet tills vidare. Men vem vet, vi kanske måste expandera geografiskt, eller implementera lösningar baserade på någon specifik utrustning. Eller så kanske mängden resurser som förbrukas rättfärdigar egna Kubernetes på barmetall, som på den gamla goda tiden. 🙂
Vad vi lärde oss av att arbeta med molntjänster
Vi började använda Kubernetes på bar metall, och även där var det bra på sitt sätt. Men dess styrkor avslöjades just som en aaS-komponent i molnet. Om du sätter ett mål och automatiserar allt så mycket som möjligt kommer du att kunna undvika inlåsning av leverantörer och att flytta mellan molnleverantörer kommer att ta ett par timmar och nervcellerna finns kvar hos oss. Vi kan ge råd till andra företag: om du vill lansera din egen (moln)tjänst, med begränsade resurser och maximal hastighet för utveckling, börja redan nu med att hyra molnresurser och bygg ditt datacenter efter att Forbes skrivit om dig.
Källa: will.com