{"id":38075,"date":"2019-10-31T22:21:32","date_gmt":"2019-10-31T19:21:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa\/"},"modified":"2019-10-31T22:21:32","modified_gmt":"2019-10-31T19:21:32","slug":"kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","title":{"rendered":"Hvordan man migrerer til skyen p\u00e5 to timer med Kubernetes og automatisering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvordan
\n
\nVirksomheden \u00abURUS\u00bb har pr\u00f8vet Kubernetes p\u00e5 forskellige m\u00e5der: selvst\u00e6ndig deployment p\u00e5 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\u00e5 rekordtid, fort\u00e6ller Igor Shishkin (t3ran<\/a><\/noindex>), senior systemadministrator hos \u00abURUS\u00bb.
\n<\/a><\/noindex><\/p>\n

Hvad laver \u00abURUS\u00bb <\/h2>\n

\nDer er mange m\u00e5der at forbedre kvaliteten af det urbane milj\u00f8 p\u00e5, og en af dem er at g\u00f8re det milj\u00f8venligt. Pr\u00e6cis dette arbejder firmaet \u00abURUS \u2014 Smarte digitale tjenester\u00bb p\u00e5. Her implementeres l\u00f8sninger, der hj\u00e6lper virksomheder med at overv\u00e5ge vigtige milj\u00f8m\u00e6ssige indikatorer og reducere den negative indvirkning p\u00e5 milj\u00f8et. Sensorer indsamler data om luftens sammens\u00e6tning, lydniveau og andre parametre og sender dem derefter til en central platform \u00abURUS \u2014 Ecomon\u00bb til analyse og udarbejdelse af anbefalinger. <\/p>\n

Hvordan \u00abURUS\u00bb fungerer fra indersiden<\/h2>\n

\nDen typiske kunde hos \u00abURUS\u00bb er en virksomhed, der er placeret i en boligzone eller t\u00e6t p\u00e5 en. Det kan v\u00e6re en fabrik, en havn, et jernbanedepot eller en anden type anl\u00e6g. Hvis vores kunde allerede har modtaget en advarsel, er blevet b\u00f8debelagt for forurening af milj\u00f8et, eller \u00f8nsker at udlede mindre st\u00f8j og reducere m\u00e6ngden af skadelige emissioner, henvender han sig til os, og vi tilbyder ham en klar l\u00f8sning til milj\u00f8overv\u00e5gning.<\/p>\n

\"Hvordan
\nGrafen der overv\u00e5ger koncentrationen af H2S viser regelm\u00e6ssige nattelige emissioner fra den n\u00e6rliggende virksomhed<\/i><\/p>\n

De enheder, vi bruger i \u00abURUS\u00bb, indeholder flere sensorer, der indsamler information om indholdet af bestemte gasser, lydniveau og andre data til vurdering af den milj\u00f8m\u00e6ssige situation. Det pr\u00e6cise antal sensorer bestemmes altid af den specifikke opgave.<\/p>\n

\"Hvordan
\nAfh\u00e6ngig af m\u00e5lingernes karakter kan enheder med sensorer placeres p\u00e5 bygningsv\u00e6gge, stolper og andre vilk\u00e5rlige steder. Hver s\u00e5dan enhed indsamler information, aggregerer den og sender den til dataindsamlingsgatewayen. Her gemmer vi dataene til langtidslagring og forbehandler dem til efterf\u00f8lgende analyse. Et simpelt eksempel p\u00e5, hvad vi f\u00e5r ud af analysen, er luftkvalitetsindekset, ogs\u00e5 kaldet AQI.<\/p>\n

Samtidig k\u00f8rer mange andre tjenester p\u00e5 vores platform, men de har hovedsageligt en supportfunktion. For eksempel sender notifikationsservicen beskeder til kunderne, hvis nogen af de overv\u00e5gede parametre (lad os sige CO2-indholdet) overstiger den acceptable gr\u00e6nse.<\/p>\n

Hvordan vi opbevarer data. Historien om Kubernetes p\u00e5 bare metal.<\/h2>\n

\nI projektet for \u00f8kmonitorering 'URUS' findes der flere datalagre. I det ene opbevarer vi de 'r\u00e5' data - det, vi har f\u00e5et direkte fra enhederne. Dette lager fungerer som et 'magnetb\u00e5nd', ligesom de gamle kassetteb\u00e5nd, med historien om alle m\u00e5linger. Den anden type lager bruges til forbehandlede data - data fra enheder, beriget med metadata om sensorernes relationer og selve enhedernes m\u00e5linger, tilknytning til organisationer, beliggenhed osv. Disse oplysninger g\u00f8r det muligt at vurdere, hvordan en bestemt m\u00e5ling har \u00e6ndret sig over en given tidsperiode. Vi bruger lageret af 'r\u00e5' data ogs\u00e5 som backup og til at gendanne de forbehandlede data, hvis der skulle opst\u00e5 behov for det.<\/p>\n

Da vi for flere \u00e5r siden s\u00f8gte efter en l\u00f8sning til lagringsproblemet, havde vi to muligheder for valg af platform: Kubernetes og OpenStack. Men da den sidstn\u00e6vnte ser temmelig monstr\u00f8s ud (bare se p\u00e5 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. <\/p>\n

Samtidig med at vi blev fortrolige med Kubernetes, studerede vi ogs\u00e5 metoder til datalagring. Da vi holdt alle vores lagre i Kubernetes p\u00e5 eget udstyr, opn\u00e5ede vi fremragende ekspertise. Alt, hvad vi havde dengang, k\u00f8rte p\u00e5 Kubernetes: stateful-lagring, overv\u00e5gningssystem, CI\/CD. Kubernetes blev for os en all-in-one platform. <\/p>\n

Men vi \u00f8nskede at arbejde med Kubernetes som en service og ikke skulle h\u00e5ndtere vedligeholdelse og udvikling. Derudover kunne vi ikke lide de omkostninger, det medf\u00f8rte at k\u00f8re det p\u00e5 bare metal, og der var konstant behov for udvikling! For eksempel blev en af de f\u00f8rste opgaver at integrere Kubernetes Ingress-controllere i vores organisations netv\u00e6rksinfrastruktur. Dette var en omfattende opgave, is\u00e6r n\u00e5r man t\u00e6nker p\u00e5, at der p\u00e5 det tidspunkt ikke var noget klar til programmatisk styring af ressourcer som DNS-poster eller tildeling. IP-adresser<\/a>. Senere begyndte vi at eksperimentere med eksterne datalagringsl\u00f8sninger. Vi n\u00e5ede aldrig at implementere PVC-controlleren, men vi inds\u00e5 allerede dengang, at det var et stort arbejdsmateriale, for hvilket vi skulle afs\u00e6tte specialister.<\/p>\n

Overgangen til Google Cloud Platform \u2014 en midlertidig l\u00f8sning<\/h2>\n

\nVi inds\u00e5, at dette ikke kunne forts\u00e6tte, og vi overf\u00f8rte vores data fra bare metal til Google Cloud Platform. Faktisk var der dengang ikke s\u00e5 mange interessante muligheder for et russisk firma: udover Google Cloud Platform tilb\u00f8d kun Amazon en lignende service, men vi valgte alligevel Googles l\u00f8sning. Det virkede mere \u00f8konomisk fordelagtigt, t\u00e6ttere p\u00e5 Upstream, for ikke at n\u00e6vne, at Google i sig selv er en slags PoC Kubernetes i produktion.<\/p>\n

Det f\u00f8rste 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\u00e6der russisk lovgivning, eller s\u00f8ger vi efter et alternativ i Rusland. Valget var i bund og grund forudsigeligt. \ud83d\ude42<\/p>\n

S\u00e5dan forestillede vi os den ideelle cloud-service<\/h2>\n

\nVed begyndelsen af vores s\u00f8gen vidste vi allerede, hvad vi \u00f8nskede at f\u00e5 fra den fremtidige cloud-udbyder. Hvilken service s\u00f8gte vi:<\/p>\n