Kuidas tänu Kubernetesile ja automatiseerimisele kahe tunniga pilve rännata

Kuidas tänu Kubernetesile ja automatiseerimisele kahe tunniga pilve rännata

Ettevõte URUS proovis Kubernetest erinevates vormides: iseseisev juurutamine paljal metallil, Google Cloudis ja seejärel viis oma platvormi Mail.ru Cloud Solutionsi (MCS) pilve. Igor Šiškin räägib, kuidas nad valisid uue pilveteenuse pakkuja ja kuidas neil õnnestus sellele üle minna rekordilise kahe tunniga (t3ran), URUS-e vanemsüsteemiadministraator.

Mida URUS teeb?

Linnakeskkonna kvaliteedi parandamiseks on palju võimalusi ja üks neist on muuta see keskkonnasõbralikuks. See on täpselt see, mille kallal ettevõte URUS – Smart Digital Services töötab. Siin rakendavad nad lahendusi, mis aitavad ettevõtetel jälgida olulisi keskkonnanäitajaid ja vähendada nende negatiivset mõju keskkonnale. Andurid koguvad andmeid õhu koostise, mürataseme ja muude parameetrite kohta ning saadavad need analüüsiks ja soovituste tegemiseks ühtsele URUS-Ekomoni platvormile.

Kuidas URUS seestpoolt toimib

URUSe tüüpiline klient on elamurajoonis või selle läheduses asuv ettevõte. See võib olla tehas, sadam, raudteedepoo või mõni muu rajatis. Kui meie klient on juba saanud hoiatuse, saanud trahvi keskkonnareostuse eest või soovib teha vähem müra, vähendada kahjulike emissioonide hulka, tuleb ta meie juurde ja me pakume talle juba valmislahendust keskkonnaseireks.

Kuidas tänu Kubernetesile ja automatiseerimisele kahe tunniga pilve rännata
H2S kontsentratsiooni monitooringu graafik näitab regulaarseid öiseid heitmeid lähedalasuvast tehasest

Seadmed, mida URUSes kasutame, sisaldavad mitmeid andureid, mis koguvad infot teatud gaaside sisalduse, müratasemete ja muude andmete kohta keskkonnaolukorra hindamiseks. Andurite täpse arvu määrab alati konkreetne ülesanne.

Kuidas tänu Kubernetesile ja automatiseerimisele kahe tunniga pilve rännata
Sõltuvalt mõõtmiste spetsiifikast võivad anduritega seadmed paikneda hoonete seintel, postidel ja muudes suvalistes kohtades. Iga selline seade kogub teavet, koondab selle ja saadab andmete vastuvõtmise lüüsi. Seal salvestame andmed pikaajaliseks säilitamiseks ja eeltöötleme neid järgnevaks analüüsiks. Lihtsaim näide sellest, mida analüüsi tulemusel saame, on õhukvaliteedi indeks, tuntud ka kui AQI.

Paralleelselt toimivad meie platvormil paljud teised teenused, kuid need on peamiselt teenust iseloomustavad. Näiteks saadab teavitusteenus klientidele teateid, kui mõni jälgitav parameeter (näiteks CO2 sisaldus) ületab lubatud väärtuse.

Kuidas me andmeid salvestame. Kubernetese lugu paljal metallil

URUS keskkonnaseire projektis on mitu andmeladu. Ühes hoiame toorandmeid - seda, mida saime otse seadmetelt endilt. See salvestus on "magnet" lint, nagu vanadel kassettlintidel, millel on kõigi indikaatorite ajalugu. Teist tüüpi salvestusruumi kasutatakse eeltöödeldud andmete jaoks – seadmete andmed, mis on rikastatud metaandmetega anduritevaheliste ühenduste ja seadmete endi näitude, organisatsioonide, asukohtade jms kohta. See teave võimaldab teil dünaamiliselt hinnata, kuidas konkreetne indikaator toimib. teatud aja jooksul muutunud. “Toorandmete” salvestusruumi kasutame muuhulgas varukoopiana ja eeltöödeldud andmete taastamiseks, kui selline vajadus peaks tekkima.

Kui otsisime mitu aastat tagasi oma salvestusprobleemi lahendamist, oli meil kaks platvormivalikut: Kubernetes ja OpenStack. Kuid kuna viimane näeb üsna koletu välja (selles veendumiseks vaadake lihtsalt selle arhitektuuri), otsustasime Kubernetese poole. Teine argument selle kasuks oli suhteliselt lihtne tarkvaraline juhtimine, võimalus vastavalt ressurssidele paindlikumalt lõigata isegi riistvaralisi sõlmi.

Paralleelselt Kubernetese enda meisterdamisega uurisime ka andmete salvestamise viise, samal ajal kui hoidsime kogu Kubernetese salvestusruumi enda riistvara peal, saime suurepäraseid teadmisi. Kõik, mida me siis Kubernetesis elasime: täielik salvestusruum, jälgimissüsteem, CI/CD. Kubernetesest on saanud meie jaoks kõik-ühes platvorm.

Kuid me tahtsime Kubernetesega koostööd teha teenusena, mitte tegeleda selle toetamise ja arendamisega. Lisaks ei meeldinud meile, kui palju selle paljal metallil hooldamine meile maksma läks ja vajasime pidevalt arendust! Näiteks oli üks esimesi ülesandeid Kubernetes Ingressi kontrollerite integreerimine meie organisatsiooni võrguinfrastruktuuri. See on tülikas ülesanne, eriti kui arvestada, et sel ajal polnud veel midagi valmis programmiliseks ressursside haldamiseks, nagu DNS-kirjed või IP-aadresside eraldamine. Hiljem hakkasime katsetama välise andmesalvestusega. Me ei jõudnud kunagi PVC-kontrolleri juurutamiseni, kuid juba siis sai selgeks, et see on suur töövaldkond, mis nõuab pühendunud spetsialiste.

Google Cloud Platformile üleminek on ajutine lahendus

Mõistsime, et see ei saa jätkuda, ja teisaldasime oma andmed metallist Google Cloud Platformi. Tegelikult ei olnud sel ajal Venemaa ettevõtte jaoks palju huvitavaid võimalusi: peale Google Cloud Platformi pakkus sarnast teenust ainult Amazon, kuid me leppisime siiski Google'i lahendusega. Siis tundus see meile majanduslikult tulusam, Upstreamile lähemal, rääkimata sellest, et Google ise on tootmises omamoodi PoC Kubernetes.

Esimene suurem probleem ilmnes silmapiiril, kui meie kliendibaas kasvas. Kui meil tekkis vajadus isikuandmeid salvestada, seisime valiku ees: kas teeme koostööd Google'iga ja rikume Venemaa seadusi või otsime alternatiivi Vene Föderatsioonist. Valik oli üldiselt etteaimatav. 🙂

Kuidas me nägime ideaalset pilveteenust

Otsingu alguseks teadsime juba, mida tulevaselt pilvepakkujalt saada tahame. Millist teenust me otsisime:

  • Kiire ja paindlik. Selline, et saame igal ajal kiiresti uue sõlme lisada või midagi juurutada.
  • Odav. Olime väga mures finantsprobleemi pärast, kuna meil olid ressursid piiratud. Teadsime juba varem, et tahame Kubernetesega koostööd teha ja nüüd oli ülesandeks minimeerida selle maksumus, et selle lahenduse kasutamise efektiivsust tõsta või vähemalt säilitada.
  • automatiseeritud. Teenusega plaanisime töötada API kaudu, ilma juhtide ja telefonikõnedeta või olukordadeta, kus on vaja mitukümmend sõlme käsitsi hädarežiimis tõsta. Kuna suurem osa meie protsessidest on automatiseeritud, ootasime sama ka pilveteenuselt.
  • Vene Föderatsiooni serveritega. Loomulikult plaanisime järgida Venemaa seadusi ja seda sama 152-FZ.

Sel ajal oli Venemaal Kubernetes aaS pakkujaid vähe ja pakkuja valikul oli meie jaoks oluline mitte teha kompromisse oma prioriteetides. Mail.ru pilvelahenduste meeskond, kellega alustasime koostööd ja teeme siiani koostööd, pakkus meile täielikult automatiseeritud teenust, API-tuge ja mugavat juhtpaneeli, mis sisaldab Horisonti – sellega saaksime kiiresti tõsta suvalise arvu sõlme.

Kuidas meil õnnestus kahe tunniga MCS-i migreeruda

Selliste käikude puhul seisavad paljud ettevõtted silmitsi raskuste ja tagasilöökidega, kuid meie puhul neid polnud. Meil vedas: kuna töötasime Kubernetesega juba enne migratsiooni algust, parandasime lihtsalt kolm faili ja käivitasime oma teenused uuel pilveplatvormil MCS. Tuletan meelde, et selleks ajaks olime lõpuks metallist lahkunud ja elanud Google Cloud Platformil. Seetõttu ei kestnud kolimine rohkem kui kaks tundi, pluss veidi rohkem aega (umbes tund) kulus meie seadmetest andmete kopeerimisele. Siis kasutasime juba Spinnakerit (mitme pilvega CD-teenus pideva kohaletoimetamise pakkumiseks). Lisasime selle ka kiiresti uude klastrisse ja jätkasime tavapäraselt tööd.

Tänu arendusprotsesside automatiseerimisele ja CI/CD-le tegeleb Kubernetesega URUSes üks spetsialist (ja see olen mina). Mingil etapil töötas minuga koos veel üks süsteemiadministraator, aga siis selgus, et olime juba kogu põhirutiini automatiseerinud ja meie põhitoote ülesandeid oli järjest rohkem ja ressursse oli mõttekas sellesse suunata.

Saime seda, mida pilveteenuse pakkujalt ootasime, kuna alustasime koostööd illusioonideta. Kui juhtus ka intsidente, olid need enamasti tehnilised ja sellised, mida võib kergesti seletada teenuse suhtelise värskusega. Peaasi, et MCS-i meeskond kõrvaldab kiiresti puudused ja vastab kiiresti sõnumitoojate küsimustele.

Kui ma võrdlen oma kogemust Google Cloud Platformiga, siis nende puhul ma isegi ei teadnud, kus see tagasiside nupp asub, kuna selleks polnud lihtsalt vajadust. Ja kui probleeme tekkis, saatis Google ise teated ühepoolselt välja. Aga MCS-i puhul pean suureks plussiks seda, et nad on Venemaa klientidele võimalikult lähedal – nii geograafiliselt kui ka vaimselt.

Kuidas me näeme tulevikus pilvedega töötamist

Nüüd on meie töö Kubernetesega tihedalt seotud ja see sobib meile infrastruktuuriülesannete seisukohast igati. Seetõttu ei plaani me sealt kuhugi migreerida, kuigi juurutame pidevalt uusi praktikaid ja teenuseid, et lihtsustada rutiinseid ülesandeid ja automatiseerida uusi, tõsta teenuste stabiilsust ja töökindlust... Nüüd käivitame Chaos Monkey teenuse (täpsemalt , kasutame chaoskube'i, kuid see ei muuda kontseptsiooni: ), mille algselt lõi Netflix. Chaos Monkey teeb ühe lihtsa asja: see kustutab juhuslikult valitud Kubernetese kausta. See on vajalik, et meie teenus toimiks normaalselt eksemplaride arvuga n–1, seega treenime end probleemideks valmis olema.

Nüüd näen kolmandate osapoolte lahenduste – samade pilveplatvormide – kasutamist noorte ettevõtete jaoks ainuõigena. Tavaliselt on nad oma teekonna alguses piiratud ressurssidega, nii inim- kui ka rahaliste vahenditega ning oma pilve- või andmekeskuse ehitamine ja ülalpidamine on liiga kulukas ja töömahukas. Pilvepakkujad võimaldavad teil neid kulusid minimeerida, neilt saate kiiresti hankida siin ja praegu teenuste toimimiseks vajalikud ressursid ning nende eest tagantjärele tasuda. Mis puutub ettevõttesse URUS, siis jääme praegu pilves Kubernetesele truuks. Kuid kes teab, võib-olla peame geograafiliselt laienema või rakendama lahendusi, mis põhinevad mõnel konkreetsel seadmel. Või võib kulutatud ressursside hulk õigustada Kubernetese omamist paljasmetallil, nagu vanadel headel aegadel. 🙂

Mida õppisime pilveteenustega töötades

Hakkasime Kubernetes kasutama palja metalli peal ja sealgi oli see omamoodi hea. Kuid selle tugevused ilmnesid täpselt pilves oleva aaS-i komponendina. Kui seate eesmärgi ja automatiseerite kõike nii palju kui võimalik, saate vältida hankijate lukku ja pilvepakkujate vahel liikumine võtab paar tundi aega ning närvirakud jäävad meile. Saame nõustada teisi ettevõtteid: kui soovite käivitada oma (pilve)teenuse, millel on piiratud ressurss ja maksimaalne arenduskiirus, alustage kohe pilveressursside rentimisest ja ehitage oma andmekeskus pärast seda, kui Forbes teist kirjutab.

Allikas: www.habr.com

Lisa kommentaar