URUS-selskapet prøvde Kubernetes i forskjellige former: uavhengig distribusjon på bart metall, i Google Cloud, og overførte deretter plattformen til Mail.ru Cloud Solutions (MCS)-skyen. Igor Shishkin forteller hvordan de valgte en ny skyleverandør og hvordan de klarte å migrere til den på rekordhøye to timer (), senior systemadministrator ved URUS.
Hva gjør URUS?
Det er mange måter å forbedre kvaliteten på bymiljøet på, og en av dem er å gjøre det miljøvennlig. Det er nettopp dette selskapet URUS - Smart Digital Services jobber med. Her implementerer de løsninger som hjelper virksomheter med å overvåke viktige miljøindikatorer og redusere deres negative påvirkning på miljøet. Sensorer samler inn data om luftsammensetning, støynivå og andre parametere, og sender dem deretter til den enhetlige URUS-Ekomon-plattformen for analyse og anbefalinger.
Hvordan URUS fungerer fra innsiden
En typisk klient til URUS er et selskap lokalisert i eller i nærheten av et boligområde. Dette kan være en fabrikk, havn, jernbanedepot eller et hvilket som helst annet anlegg. Dersom vår oppdragsgiver allerede har fått en advarsel, fått bot for miljøforurensning, eller ønsker å lage mindre støy, redusere mengden skadelige utslipp, kommer han til oss, og vi tilbyr ham allerede en ferdig løsning for miljøovervåking.
H2S-konsentrasjonsovervåkingsgrafen viser vanlige natteutslipp fra et nærliggende anlegg
Enhetene som vi bruker på URUS inneholder flere sensorer som samler informasjon om innholdet i enkelte gasser, støynivåer og andre data for å vurdere miljøsituasjonen. Det nøyaktige antallet sensorer bestemmes alltid av den spesifikke oppgaven.
Avhengig av spesifikasjonene til målingene, kan enheter med sensorer plasseres på veggene til bygninger, stolper og andre vilkårlige steder. Hver slik enhet samler inn informasjon, samler den og sender den til datamottaksporten. Der lagrer vi dataene for langtidslagring og forbehandler dem for etterfølgende analyse. Det enkleste eksemplet på hva vi får som resultat av analyse er luftkvalitetsindeksen, også kjent som AQI.
Parallelt opererer mange andre tjenester på vår plattform, men de er hovedsakelig av tjenestekarakter. For eksempel sender varslingstjenesten varsler til klienter hvis noen av de overvåkede parameterne (for eksempel CO2-innhold) overskrider den tillatte verdien.
Hvordan vi lagrer data. Historien om Kubernetes på bart metall
Miljøovervåkingsprosjektet URUS har flere datavarehus. I ett beholder vi "rå" data - det vi mottok direkte fra selve enhetene. Denne lagringen er et "magnetisk" bånd, som på gamle kassettbånd, med en historie med alle indikatorer. Den andre typen lagring brukes til forhåndsbehandlede data – data fra enheter, beriket med metadata om koblinger mellom sensorer og avlesningene til enhetene selv, tilknytning til organisasjoner, lokasjoner osv. Denne informasjonen lar deg vurdere dynamisk hvordan en bestemt indikator har endret seg over en viss tidsperiode. Vi bruker «rå» datalagringen blant annet som backup og for å gjenopprette forhåndsbehandlede data, dersom et slikt behov skulle oppstå.
Da vi var ute etter å løse lagringsproblemet vårt for flere år siden, hadde vi to plattformvalg: Kubernetes og OpenStack. Men siden sistnevnte ser ganske monstrøs ut (bare se på arkitekturen for å bli overbevist om dette), slo vi oss ned på Kubernetes. Et annet argument i sin favør var den relativt enkle programvarekontrollen, muligheten til mer fleksibelt å kutte selv maskinvarenoder i henhold til ressurser.
Parallelt med å mestre selve Kubernetes studerte vi også måter å lagre data på, mens vi holdt all lagringen vår i Kubernetes på egen maskinvare, fikk vi utmerket ekspertise. Alt vi hadde da levd på Kubernetes: statefull lagring, overvåkingssystem, CI/CD. Kubernetes har blitt en alt-i-ett-plattform for oss.
Men vi ønsket å jobbe med Kubernetes som en tjeneste, og ikke engasjere oss i støtte og utvikling. Dessuten likte vi ikke hvor mye det kostet oss å vedlikeholde det på bart metall, og vi trengte utvikling hele tiden! For eksempel var en av de første oppgavene å integrere Kubernetes Ingress-kontrollere i nettverksinfrastrukturen til organisasjonen vår. Dette er en tungvint oppgave, spesielt med tanke på at ingenting på den tiden var klart for programmatisk ressursstyring som DNS-poster eller tildeling av IP-adresser. Senere begynte vi å eksperimentere med ekstern datalagring. Vi kom aldri i gang med å implementere PVC-kontrolleren, men allerede da ble det klart at dette var et stort arbeidsområde som krevde dedikerte spesialister.
Bytte til Google Cloud Platform er en midlertidig løsning
Vi innså at dette ikke kunne fortsette, og flyttet dataene våre fra bare metall til Google Cloud Platform. Faktisk, på den tiden var det ikke mange interessante alternativer for et russisk selskap: i tillegg til Google Cloud Platform, var det bare Amazon som tilbød en lignende tjeneste, men vi slo oss likevel fast på løsningen fra Google. Da virket det for oss mer økonomisk lønnsomt, nærmere Upstream, for ikke å nevne det faktum at Google selv er en slags PoC Kubernetes i produksjon.
Det første store problemet dukket opp i horisonten ettersom kundebasen vår vokste. Da vi hadde behov for å lagre personopplysninger, sto vi overfor et valg: enten jobber vi med Google og bryter russiske lover, eller så ser vi etter et alternativ i den russiske føderasjonen. Valget var i det hele tatt forutsigbart. 🙂
Hvordan vi så den ideelle skytjenesten
Ved begynnelsen av søket visste vi allerede hva vi ønsket å få fra den fremtidige skyleverandøren. Hvilken tjeneste var vi ute etter:
- Rask og fleksibel. Slik at vi raskt kan legge til en ny node eller distribuere noe når som helst.
- Rimelig. Vi var svært bekymret for det økonomiske problemet, siden vi var begrenset i ressurser. Vi visste allerede at vi ønsket å jobbe med Kubernetes, og nå var oppgaven å minimere kostnadene for å øke eller i det minste opprettholde effektiviteten ved å bruke denne løsningen.
- Automatisert. Vi planla å jobbe med tjenesten gjennom API, uten ledere og telefonsamtaler eller situasjoner der vi manuelt må heve flere dusin noder i nødmodus. Siden de fleste av prosessene våre er automatiserte, forventet vi det samme fra skytjenesten.
- Med servere i den russiske føderasjonen. Selvfølgelig planla vi å overholde russisk lovgivning og den samme 152-FZ.
På den tiden var det få Kubernetes aaS-leverandører i Russland, og ved valg av leverandør var det viktig for oss å ikke gå på akkord med prioriteringene våre. Mail.ru Cloud Solutions-teamet, som vi begynte å jobbe med og fortsatt samarbeider med, ga oss en helautomatisert tjeneste, med API-støtte og et praktisk kontrollpanel som inkluderer Horizon – med det kunne vi raskt øke et vilkårlig antall noder.
Hvordan vi klarte å migrere til MCS på to timer
I slike trekk møter mange selskaper vanskeligheter og tilbakeslag, men i vårt tilfelle var det ingen. Vi var heldige: Siden vi allerede jobbet med Kubernetes før migreringen begynte, rettet vi ganske enkelt tre filer og lanserte tjenestene våre på den nye skyplattformen, MCS. La meg minne deg på at på den tiden hadde vi endelig forlatt bare metall og levd på Google Cloud Platform. Derfor tok selve flyttingen ikke mer enn to timer, pluss litt mer tid (ca. en time) ble brukt på å kopiere data fra enhetene våre. Den gang brukte vi allerede Spinnaker (en multisky-CD-tjeneste for å tilby kontinuerlig levering). Vi la den også raskt til den nye klyngen og fortsatte å jobbe som vanlig.
Takket være automatisering av utviklingsprosesser og CI/CD, håndteres Kubernetes ved URUS av én spesialist (og det er meg). På et tidspunkt jobbet en annen systemadministrator med meg, men så viste det seg at vi allerede hadde automatisert all hovedrutinen og det ble flere og flere oppgaver fra hovedproduktets side og det var fornuftig å lede ressurser til dette.
Vi fikk det vi forventet fra skyleverandøren, siden vi startet samarbeidet uten illusjoner. Hvis det var noen hendelser, var de for det meste tekniske og de som lett kunne forklares med den relative friskheten til tjenesten. Hovedsaken er at MCS-teamet raskt eliminerer mangler og raskt svarer på spørsmål i messengers.
Hvis jeg sammenligner min erfaring med Google Cloud Platform, i deres tilfelle visste jeg ikke engang hvor tilbakemeldingsknappen var, siden det rett og slett ikke var behov for det. Og hvis det oppsto problemer, sendte Google selv ut varsler ensidig. Men når det gjelder MCS, tror jeg den store fordelen er at de er nærmest mulig russiske klienter – både geografisk og mentalt.
Hvordan vi ser på arbeidet med skyer i fremtiden
Nå er arbeidet vårt tett knyttet til Kubernetes, og det passer oss helt med tanke på infrastrukturoppgaver. Derfor planlegger vi ikke å migrere fra det hvor som helst, selv om vi stadig introduserer ny praksis og tjenester for å forenkle rutineoppgaver og automatisere nye, øke stabiliteten og påliteligheten til tjenestene... Vi lanserer nå Chaos Monkey-tjenesten (spesifikt , vi bruker chaoskube, men dette endrer ikke konseptet: ), som opprinnelig ble laget av Netflix. Chaos Monkey gjør en enkel ting: den sletter en tilfeldig Kubernetes-pod på et tilfeldig tidspunkt. Dette er nødvendig for at tjenesten vår skal leve normalt med antall instanser n–1, så vi trener oss på å være forberedt på eventuelle problemer.
Nå ser jeg på bruk av tredjepartsløsninger – de samme skyplattformene – som det eneste riktige for unge bedrifter. Vanligvis, i begynnelsen av reisen, er de begrenset i ressurser, både menneskelige og økonomiske, og å bygge og vedlikeholde sin egen sky eller datasenter er for dyrt og arbeidskrevende. Skyleverandører lar deg minimere disse kostnadene; du kan raskt få ressursene som er nødvendige for driften av tjenestene her og nå fra dem, og betale for disse ressursene i ettertid. Når det gjelder URUS-selskapet, vil vi forbli trofaste mot Kubernetes i skyen inntil videre. Men hvem vet, vi må kanskje utvide geografisk, eller implementere løsninger basert på noe spesifikt utstyr. Eller kanskje mengden ressurser som forbrukes vil rettferdiggjøre egne Kubernetes på bare-metal, som i de gode gamle dager. 🙂
Hva vi lærte av å jobbe med skytjenester
Vi begynte å bruke Kubernetes på bart metall, og selv der var det bra på sin måte. Men styrkene ble avslørt nettopp som en aaS-komponent i skyen. Hvis du setter deg et mål og automatiserer alt så mye som mulig, vil du kunne unngå leverandørlåsing og flytting mellom skyleverandører vil ta et par timer, og nervecellene forblir hos oss. Vi kan gi råd til andre selskaper: hvis du ønsker å lansere din egen (sky)tjeneste, med begrensede ressurser og maksimal hastighet for utvikling, start allerede nå med å leie skyressurser, og bygg datasenteret ditt etter at Forbes skriver om deg.
Kilde: www.habr.com