URUS įmonė išbandė Kubernetes įvairiomis formomis: nepriklausomą diegimą ant pliko metalo, „Google Cloud“, o tada perkėlė savo platformą į „Mail.ru Cloud Solutions“ (MCS) debesį. Igoris Šiškinas pasakoja, kaip jie pasirinko naują debesų paslaugų teikėją ir kaip per rekordines dvi valandas pavyko pereiti prie jo (), vyresnysis sistemos administratorius URUS.
Ką veikia URUS?
Miesto aplinkos kokybei gerinti yra daug būdų, vienas iš jų – padaryti ją draugišką aplinkai. Būtent prie to ir dirba URUS – išmaniųjų skaitmeninių paslaugų įmonė. Čia jie diegia sprendimus, padedančius įmonėms stebėti svarbius aplinkosaugos rodiklius ir sumažinti jų neigiamą poveikį aplinkai. Jutikliai renka duomenis apie oro sudėtį, triukšmo lygį ir kitus parametrus, o vėliau siunčia juos į vieningą URUS-Ekomon platformą analizei ir rekomendacijoms teikti.
Kaip URUS veikia iš vidaus
Tipiškas URUS klientas yra įmonė, įsikūrusi gyvenamajame rajone arba šalia jo. Tai gali būti gamykla, uostas, geležinkelio depas ar bet koks kitas objektas. Jeigu mūsų klientas jau gavo įspėjimą, buvo nubaustas už aplinkos teršimą arba nori mažiau triukšmauti, sumažinti kenksmingų emisijų kiekį, jis atvyksta pas mus, o mes jam jau siūlome paruoštą aplinkos monitoringo sprendimą.
H2S koncentracijos stebėjimo grafikas rodo reguliarius nakties išmetimus iš netoliese esančios gamyklos
Įrenginiuose, kuriuos naudojame URUS, yra keli jutikliai, kurie renka informaciją apie tam tikrų dujų kiekį, triukšmo lygį ir kitus duomenis aplinkos situacijai įvertinti. Tikslų jutiklių skaičių visada lemia konkreti užduotis.
Atsižvelgiant į matavimų specifiką, prietaisai su jutikliais gali būti išdėstyti ant pastatų sienų, stulpų ir kitose savavališkose vietose. Kiekvienas toks įrenginys renka informaciją, sujungia ją ir siunčia į duomenų priėmimo šliuzą. Ten išsaugome duomenis ilgalaikiam saugojimui ir iš anksto apdorojame juos vėlesnei analizei. Paprasčiausias pavyzdys, ką gauname atlikę analizę, yra oro kokybės indeksas, dar žinomas kaip AQI.
Lygiagrečiai mūsų platformoje veikia daug kitų paslaugų, tačiau jos daugiausia yra paslaugų pobūdžio. Pavyzdžiui, pranešimų paslauga siunčia pranešimus klientams, jei kuris nors iš stebimų parametrų (pavyzdžiui, CO2 kiekis) viršija leistiną vertę.
Kaip mes saugome duomenis. Kubernetes istorija ant pliko metalo
URUS aplinkos monitoringo projektas turi keletą duomenų saugyklų. Viename saugome „neapdorotus“ duomenis – tai, ką gavome tiesiai iš pačių įrenginių. Ši saugykla yra „magnetinė“ juosta, kaip ir senose kasetinėse juostose, su visų indikatorių istorija. Antrasis saugyklos tipas naudojamas iš anksto apdorotiems duomenims – duomenims iš įrenginių, praturtintiems metaduomenimis apie ryšius tarp jutiklių ir pačių įrenginių rodmenis, ryšį su organizacijomis, vietomis ir pan. Ši informacija leidžia dinamiškai įvertinti, kaip konkretus rodiklis veikia. pasikeitė per tam tikrą laikotarpį. „Neapdorotų“ duomenų saugyklą, be kita ko, naudojame kaip atsarginę kopiją ir iš anksto apdorotų duomenų atkūrimui, jei toks poreikis iškyla.
Kai prieš keletą metų ieškojome saugyklos problemos sprendimo, turėjome dvi platformos pasirinkimus: Kubernetes ir OpenStack. Bet kadangi pastarasis atrodo gana monstriškai (kad tuo įsitikintumėte, tiesiog pažiūrėkite į jo architektūrą), apsigyvenome Kubernetes. Kitas argumentas jo naudai buvo gana paprastas programinis valdymas, galimybė pagal resursus lanksčiau karpyti net aparatūros mazgus.
Lygiagrečiai įsisavindami patį „Kubernetes“ taip pat tyrinėjome duomenų saugojimo būdus, o visą „Kubernetes“ saugyklą laikėme savo aparatinėje įrangoje, gavome puikių žinių. Viskas, ką tada gyvenome Kubernetes: visa būsena, stebėjimo sistema, CI / CD. „Kubernetes“ mums tapo „viskas viename“ platforma.
Bet mes norėjome dirbti su Kubernetes kaip paslauga, o ne užsiimti jos palaikymu ir plėtra. Be to, mums nepatiko, kiek mums kainavo jo priežiūra ant pliko metalo, ir mums reikėjo nuolatos tobulėti! Pavyzdžiui, viena pirmųjų užduočių buvo integruoti Kubernetes Ingress valdiklius į mūsų organizacijos tinklo infrastruktūrą. Tai sudėtinga užduotis, ypač turint omenyje, kad tuo metu niekas nebuvo paruoštas programiniam išteklių valdymui, pavyzdžiui, DNS įrašams ar IP adresų paskirstymui. Vėliau pradėjome eksperimentuoti su išorine duomenų saugykla. Niekada nespėjome diegti PVC valdiklio, tačiau jau tada tapo aišku, kad tai didelė darbo sritis, kuriai reikia atsidavusių specialistų.
Perėjimas prie „Google Cloud Platform“ yra laikinas sprendimas
Supratome, kad tai negali tęstis, ir perkėlėme duomenis iš gryno metalo į „Google Cloud Platform“. Tiesą sakant, tuo metu Rusijos įmonei nebuvo daug įdomių variantų: be „Google Cloud Platform“, panašią paslaugą siūlė tik „Amazon“, tačiau vis tiek apsistojome ties „Google“ sprendimu. Tada mums atrodė ekonomiškai pelningiau, arčiau Upstream, jau nekalbant apie tai, kad pati Google yra savotiškas PoC Kubernetes in Production.
Pirmoji didelė problema iškilo horizonte, kai mūsų klientų bazė auga. Iškilus poreikiui saugoti asmens duomenis, susidūrėme su pasirinkimu: arba dirbame su Google ir pažeidžiame Rusijos įstatymus, arba ieškome alternatyvos Rusijos Federacijoje. Apskritai pasirinkimas buvo nuspėjamas. 🙂
Kaip pamatėme idealią debesies paslaugą
Paieškos pradžioje jau žinojome, ką norime gauti iš būsimojo debesų tiekėjo. Kokios paslaugos mes ieškojome:
- Greitas ir lankstus. Tokie, kad galėtume bet kada greitai pridėti naują mazgą arba ką nors įdiegti.
- Nebrangus. Mums labai rūpėjo finansinė problema, nes buvome riboti ištekliai. Jau anksčiau žinojome, kad norime dirbti su „Kubernetes“, o dabar užduotis buvo sumažinti jos sąnaudas, siekiant padidinti ar bent išlaikyti šio sprendimo naudojimo efektyvumą.
- automatizuotas. Su paslauga planavome dirbti per API, be vadybininkų ir telefono skambučių ar situacijų, kai reikia rankiniu būdu pakelti kelias dešimtis mazgų avariniu režimu. Kadangi dauguma mūsų procesų yra automatizuoti, to paties tikėjomės ir iš debesies paslaugos.
- Su serveriais Rusijos Federacijoje. Žinoma, planavome laikytis Rusijos įstatymų ir to paties 152-FZ.
Tuo metu Rusijoje „Kubernetes aaS“ tiekėjų buvo nedaug, o renkantis tiekėją mums buvo svarbu nenuleisti savo prioritetų. „Mail.ru Cloud Solutions“ komanda, su kuria pradėjome dirbti ir bendradarbiaujame iki šiol, suteikė mums visiškai automatizuotą paslaugą, API palaikymą ir patogų valdymo pultą, į kurį įeina „Horizon“ – su juo galėtume greitai pakelti savavališką skaičių mazgų.
Kaip mums pavyko persikelti į MCS per dvi valandas
Tokiais žingsniais daugelis įmonių susiduria su sunkumais ir nesėkmėmis, tačiau mūsų atveju jų nebuvo. Mums pasisekė: kadangi jau dirbome su Kubernetes prieš pradedant perkėlimą, tiesiog pataisėme tris failus ir paleidome savo paslaugas naujoje debesų platformoje MCS. Leiskite jums priminti, kad iki to laiko mes pagaliau palikome pliką metalą ir gyvenome „Google Cloud Platform“. Todėl pats perkėlimas užtruko ne daugiau nei dvi valandas, be to, šiek tiek daugiau laiko (apie valandą) sugaišome kopijuojant duomenis iš mūsų įrenginių. Tada jau naudojome „Spinnaker“ (keleto debesų kompaktinių diskų paslauga, skirta nuolatiniam pristatymui). Taip pat greitai įtraukėme jį į naują klasterį ir toliau dirbome kaip įprasta.
Dėl kūrimo procesų ir CI/CD automatizavimo Kubernetes URUS valdo vienas specialistas (ir tai aš). Kažkuriuo metu su manimi dirbo kitas sistemos administratorius, bet tada paaiškėjo, kad mes jau automatizavome visą pagrindinę rutiną ir vis daugiau užduočių iš mūsų pagrindinio produkto, todėl buvo prasminga nukreipti išteklius.
Gavome tai, ko tikėjomės iš debesų tiekėjo, nes pradėjome bendradarbiauti be iliuzijų. Jei ir buvo kokių nors incidentų, jie dažniausiai buvo techniniai ir lengvai paaiškinami santykiniu paslaugos šviežumu. Svarbiausia, kad MCS komanda greitai pašalintų trūkumus ir greitai atsakytų į pasiuntinių klausimus.
Jei lyginčiau savo patirtį su Google Cloud Platform, tai jų atveju net nežinojau, kur yra atsiliepimų mygtukas, nes jo tiesiog nereikėjo. Ir jei iškilo kokių nors problemų, pati „Google“ vienašališkai išsiuntė pranešimus. Bet MCS atveju, manau, didelis privalumas yra tai, kad jie yra kuo arčiau Rusijos klientų – tiek geografiškai, tiek psichiškai.
Kaip matome darbą su debesimis ateityje
Dabar mūsų darbas yra glaudžiai susijęs su Kubernetes ir mums visiškai tinka infrastruktūros užduočių požiūriu. Todėl niekur iš jos neplanuojame migruoti, nors nuolat diegiame naujas praktikas ir paslaugas, kurios supaprastintume įprastas užduotis ir automatizuotume naujas, padidintume paslaugų stabilumą ir patikimumą... Dabar pristatome Chaos Monkey paslaugą (konkrečiai , mes naudojame chaoskube, bet tai nekeičia koncepcijos: ), kurią iš pradžių sukūrė Netflix. „Chaos Monkey“ atlieka vieną paprastą dalyką: atsitiktiniu metu ištrina atsitiktinį „Kubernetes“ rinkinį. Tai būtina, kad mūsų paslauga normaliai veiktų su n–1 atvejų skaičiumi, todėl mokomės būti pasirengę bet kokioms problemoms.
Dabar matau trečiųjų šalių sprendimų – tų pačių debesų platformų – naudojimą kaip vienintelį teisingą dalyką jaunoms įmonėms. Paprastai savo kelionės pradžioje jie yra riboti tiek žmogiškaisiais, tiek finansiniais ištekliais, o nuosavo debesies ar duomenų centro kūrimas ir priežiūra yra per brangu ir reikalauja daug darbo. Debesijos paslaugų teikėjai leidžia minimalizuoti šias išlaidas, iš jų galite greitai gauti išteklių, reikalingų paslaugų veikimui čia ir dabar, ir sumokėti už šiuos išteklius po to. Kalbant apie URUS įmonę, kol kas liksime ištikimi Kubernetes debesyje. Bet kas žino, gali tekti plėstis geografiškai arba įgyvendinti sprendimus, pagrįstus kokia nors specifine įranga. O gal sunaudotų išteklių kiekis pateisins nuosavą „Kubernetes“ ant pliko metalo, kaip senais gerais laikais. 🙂
Ko išmokome dirbdami su debesijos paslaugomis
„Kubernetes“ pradėjome naudoti ant pliko metalo, ir net ten jis buvo savaip geras. Tačiau jo stipriosios pusės buvo atskleistos būtent kaip aaS komponentas debesyje. Jei išsikelsite tikslą ir viską maksimaliai automatizuosite, galėsite išvengti pardavėjų užsiblokavimo ir judėjimas tarp debesų tiekėjų užtruks porą valandų, o nervų ląstelės liks pas mus. Galime patarti kitoms įmonėms: jei norite paleisti savo (debesų) paslaugą, turėdami ribotus išteklius ir maksimalų plėtros greitį, pradėkite jau dabar nuo debesies išteklių nuomos ir sukurkite savo duomenų centrą po to, kai Forbes apie jus parašys.
Šaltinis: www.habr.com