Kompania 'URUS' e provoi Kubernetes në forma të ndryshme: implementim të pavarur në bare metal, në Google Cloud dhe më pas transfertën e platformës së saj në cloud-in Mail.ru Cloud Solutions (MCS). Si e zgjodhën ofruesin e ri të shërbimeve cloud dhe si ia dolën të migronin brenda një kohe rekord prej dy orësh, tregon Igor Shishkin (), administrator i lartë i sistemeve 'URUS'.
ĂfarĂ« bĂ«n 'URUS'
Ka shumë mënyra për të përmirësuar cilësinë e ambientit urban, dhe njëra prej tyre është ta bësh atë ekologjikisht të sigurt. Pikërisht për këtë punon kompania 'URUS - Shërbimet digjitale të mençura'. Aty aplikohet zgjidhje që ndihmojnë bizneset të monitorojnë treguesit e rëndësishëm ekologjik dhe të zvogëlojnë ndikimin negativ në mjedis. Sensorët mbledhin të dhëna mbi përbërjen e ajrit, nivelin e zhurmës dhe parametra të tjerë, dhe më pas i dërgojnë në platformën e përbashkët 'URUS - Ekomon' për analizë dhe përpilim rekomandimesh.
Si funksionon 'URUS' nga brenda
Klienti tipik i 'URUS' është një kompani që ndodhet në një zonë banimi ose pranë saj. Kjo mund të jetë një fabrikë, port, depo hekurudhore ose çdo objekt tjetër. Nëse klienti ynë ka marrë tashmë paralajmërime, është gjobitur për ndotjen e mjedisit, ose dëshiron të emitojë më pak zhurma dhe të reduktojë sasinë e emetimeve të dëmshme, ai vjen te ne, dhe ne tashmë i ofrojmë një zgjidhje të gatshme për monitorimin ekologjik.
Në grafikun e monitorimit të përqendrimit të H2S-së duken shpërthimet e rregullta natën nga një kompani që ndodhet pranë.
Dispozitivet që ne përdorim në 'URUS' përmbajnë disa sensorë që mbledhin informacion mbi përmbajtjen e gazrave të caktuar, nivelin e zhurmës dhe të dhëna të tjera për vlerësimin e situatës ekologjike. Sasia e saktë e sensorëve përcaktohet gjithmonë nga detyra specifike.
NĂ« varĂ«si tĂ« specifikĂ«s sĂ« matjeve, pajisjet me sensore mund tĂ« vendosen nĂ« muret e ndĂ«rtesave, shtylla dhe nĂ« vendet e tjera tĂ« rastĂ«sishme. Ădo pajisje e tillĂ« mbledh informacion, e agregon atĂ« dhe e dĂ«rgon nĂ« portin e marrjes sĂ« tĂ« dhĂ«nave. Aty ne ruajmĂ« tĂ« dhĂ«nat pĂ«r njĂ« periudhĂ« tĂ« gjatĂ« dhe i pĂ«rpunojmĂ« pĂ«r analizĂ«n e mĂ«vonshme. NjĂ« shembull i thjeshtĂ« tĂ« asaj qĂ« ne marrim nĂ« dalje pas analizĂ«s Ă«shtĂ« indeksi i cilĂ«sisĂ« sĂ« ajrit, i njohur gjithashtu si AQI.
Në mënyrë paralele, shumë shërbime të tjera funksionojnë në platformën tonë, por kryesisht ato janë shërbime mbështetëse. Për shembull, shërbimi i njoftimit dërgon klientëve njoftime nëse ndonjë nga parametrat e ndjekur (p.sh., përqindja e CO2) ka tejkaluar vlerën e lejuar.
Si i ruajmë të dhënat. Historia me Kubernetes në bare metal
Në projektin e ekomonitorimit "URUS" ka disa depo të të dhënave. Në një nga to ne ruajmë të dhënat "e papërpunuara" - ato që kemi marrë drejtpërdrejt nga pajisjet vetë. Kjo depo përfaqëson një "bandë" magnetike, siç ishin kasetat e vjetra, me historikun e të gjithë treguesve. Lloji i dytë i depozitës përdoret për të dhënat e përpunuara paraprakisht - të dhëna nga pajisjet, të pasuruara me metadata rreth lidhjeve të sensorëve dhe leximeve të pajisjeve vetë, përkatësinë ndaj organizatave, vendndodhjeve etj. Kjo informacion na lejon të vlerësojmë dinamikisht se si ka ndryshuar një tregues i caktuar gjatë një periudhe të caktuar kohe. Depoja e të dhënave "e papërpunuara" përdoret gjithashtu si një backup dhe për rikuperimin e të dhënave të përpunuara paraprakisht, nëse ndonjëherë do të ketë nevojë për të.
Kur disa vite më parë kërkuam një zgjidhje për problemin e ruajtjes, kishim dy mundësi për të zgjedhur platformën: Kubernetes dhe OpenStack. Por pasi që e dyta duket mjaft monstruoze (thjesht shikoni arkitekturën e saj për t'u bindur për këtë), ne vendosëm të përdorim pikërisht Kubernetes. Një argument tjetër në favor të saj ishte menaxhimi mjaft i lehtë programatik, mundësia për të ndarë më fleksibël edhe nodet harduerike sipas burimeve.
Paralelisht me mĂ«simin e Kubernetes vetĂ«, ne studiuam edhe mĂ«nyrat e ruajtjes sĂ« tĂ« dhĂ«nave. NdĂ«rsa ruanim tĂ« gjitha depozitat tona nĂ« Kubernetes nĂ« pajisjet tona, fituam njĂ« pĂ«rvojĂ« shumĂ« tĂ« mirĂ«. Ădo gjĂ« qĂ« kishim atĂ«herĂ« jetonte pikĂ«risht nĂ« Kubernetes: depozita stateful, sistemi i monitorimit, CI/CD. Kubernetes u bĂ« pĂ«r ne njĂ« platformĂ« all-in-one.
Por na pëlqente të punonim me Kubernetes si një shërbim, e jo të merreshim me mbështetje dhe zhvillim të tij. Gjithashtu, nuk na pëlqente kostoja e mbajtjes së tij në bare metal, dhe zhvillimi kërkohej vazhdimisht! Për shembull, një nga detyrat e para ishte të integrojmë Ingress-controllerat e Kubernetes në infrastrukturën rrjetore të organizatës tonë. Kjo është një detyrë e madhe, sidomos nëse imagjinojmë se në atë kohë nuk kishte asgjë të gatshme për menaxhimin programatik të burimeve si regjistrimet DNS ose ndarjet. IP-adresat. Më vonë filluam të eksperimentojmë me depozita ekstërne të të dhënave. Nuk arritëm të zbatojmë controllerin PVC, por atëherë u kuptua që ky ishte një front i madh punësh, për të cilin duhej të angazhoheshin specialistë të veçantë.
Kalimi në Google Cloud Platform - një zgjidhje temporary.
Kuptuam se kështu nuk mund të vazhdohej dhe transferuam të dhënat tona nga bare metal në Google Cloud Platform. Në të vërtetë, atëherë për një kompani ruse nuk kishte shumë mundësi interesante: përveç Google Cloud Platform, një shërbim të ngjashëm ofronte vetëm Amazon, por ne zgjodhëm zgjidhjen nga Google. Atëherë na dukej më ekonomikisht e favorshme, më afër Upstream, për të mos përmendur se Google vetë është një lloj PoC Kubernetes në Production.
Problemi i parĂ« serioz doli nĂ« horizont paralelisht me rritjen e bazĂ«s sonĂ« tĂ« klientĂ«ve. Kur na u nevojit tĂ« ruanim tĂ« dhĂ«na personale, u paraqit nevoja pĂ«r tĂ« zgjedhur: ose punojmĂ« me Google dhe shkelim ligjet ruse, ose kĂ«rkojmĂ« njĂ« alternativĂ« nĂ« RF. Zgjedhja, nĂ« pĂ«rgjithĂ«si, ishte e parashikueshme. đ
Si e shihnim ne shërbimin ideal të cloud.
MĂ« fillim tĂ« kĂ«rkimeve, ne tashmĂ« e dinim se çfarĂ« dĂ«shironim tĂ« merrnim nga ofruesi i ardhshĂ«m tĂ« cloud. ĂfarĂ« shĂ«rbimi po kĂ«rkonim:
- I shpejtë dhe fleksibël.. Një që do të na lejonte të shtonim nxjerrjen e re ose të zhvillonim diçka në çdo moment.
- Nuk është i shtrenjtë.. Na na shqetësonte shumë çështja financiare, pasi ishim të kufizuar me burime. Ne e dinim tashmë se dëshironim të punonim me Kubernetes, dhe tani na duhej të minimizonim kostot e tij, për të rritur ose të paktën të ruanim efikasitetin e përdorimit të këtij zgjidhjeje.
- Të automatizuar. Ne planifikonim të punonim me shërbimin përmes API-t, pa menaxherë dhe telefonata ose situata kur duhej të ngriheshin manual disa dhjetëra nodë në mënyrë të nxituar. Pasi shumica e proceseve tona ishin të automatizuara, të njëjtën gjë e prisnim edhe nga shërbimi në re.
- Me serverët në RF. Sigurisht, planifikonim të respektonim legjislacionin rus dhe atë të njohur 152-FZ.
Në atë kohë, ofruesit e Kubernetes në modelin aaS në Rusi ishin të pakët, por kur zgjodhëm ofruesin, ishte e rëndësishme për ne të mos hiqnim dorë nga prioritetet tona. Ekipi i Mail.ru Cloud Solutions, me të cilin filluam të punonim dhe bashkëpunojmë ende, na ofroi një shërbim plotësisht të automatizuar, me mbështetje API dhe një panel menaxhimi të lehtë për t'u përdorur, ku ishte Horizon - me të mundëm të ngremë shpejt një numër të caktuar nodësh.
Si arritëm të migrojmë në MCS për dy orë
Në këto lëvizje, shumë kompani përballen me vështirësi dhe dështime, por në rastin tonë nuk pati asnjë. Na qenka fat: pasi para fillimit të migrimit kishim punuar tashmë me Kubernetes, thjesht rregulluam tre dosje dhe nisa shërbimet tona në platformën e re në re, në MCS. Kujtoj se në atë kohë ne kishim larguar përfundimisht nga bare metal dhe jetonim në Google Cloud Platform. Prandaj, vetë lëvizja zgjati jo më shumë se dy orë, plus edhe pak kohë (rreth një orë) u harxhua për kopjimin e të dhënave nga pajisjet tona. Atëherë ne kishim filluar të përdornim Spinnaker (shërbimi multi-re për sigurimin e Continous Delivery). Edhe atë e shtuam shpejt në klasterin e ri dhe vazhduam të punonim si zakonisht.
Falë automatizimit të proceseve të zhvillimit dhe CI/CD, Kubernetes'i në 'URUS' merret nga një specialist (dhe kjo jam unë). Në një moment, me mua punonte një administrator tjetër sistemi, por pastaj doli se të gjitha rutinat kryesore i kishim automatizuar dhe nga ana e produktit tonë kryesor, detyrat po bëheshin gjithnjë e më të shumta dhe kishte kuptim të drejtonim burimet në këtë drejtim.
Kemi kemi nga ofruesi i shërbimeve cloud atë që prisnim, pasi filluam bashkëpunimin pa iluzione. Nëse kishte ndonjë incident, ato ishin kryesisht teknike dhe ndodhnin për shkak të freskisë relative të shërbimit. E rëndësishme është që ekipi i MCS arrin të korrigjojë shpejt gabimet dhe përgjigjet shpejt në pyetje në mesazherët.
NĂ« krahasim me pĂ«rvojĂ«n time me Google Cloud Platform, nĂ« rastin e tyre as nuk dija se ku ndodhej butoni i feedback-ut, sepse nuk kishte nevojĂ« pĂ«r tĂ«. Dhe nĂ«se ndodhnin ndonjĂ« problem, Google vetĂ« dĂ«rgonte njoftime nĂ« mĂ«nyrĂ« einĂ«ve. Por nĂ« rastin e MCS, njĂ« pĂ«rparĂ«si e madhe e shoh se Ă«shtĂ« qĂ« ata janĂ« sa mĂ« afĂ«r klientĂ«ve rusĂ« â dhe teritorialisht, dhe mentalisht.
Si e shohim punën me cloud-in në të ardhmen
Tani puna jonĂ« Ă«shtĂ« duke u lidhur ngushtĂ« me Kubernetes-in, dhe ai na plotĂ«son plotĂ«sisht nga pikĂ«pamja e detyrave infrastrukturore. Prandaj nuk planifikojmĂ« tĂ« migrojmĂ« diku tjetĂ«r, ndonĂ«se vazhdimisht po prezantojmĂ« praktikĂ« dhe shĂ«rbime tĂ« reja pĂ«r tĂ« thjeshtuar detyrat rutinĂ« dhe pĂ«r tĂ« automatizuar tĂ« reja, duke rritur stabilitetin dhe besueshmĂ«rinĂ« e shĂ«rbimeve⊠Tani po nisemi me shĂ«rbimin Chaos Monkey (nĂ« tĂ« vĂ«rtetĂ« po pĂ«rdorim chaoskube, por kjo nuk e ndryshon konceptin :), i cili u krijua fillimisht nĂ« Netflix. Chaos Monkey bĂ«n njĂ« gjĂ« tĂ« thjeshtĂ«: nĂ« çdo moment tĂ« rastit, heq njĂ« pod tĂ« rastĂ«sishĂ«m nĂ« Kubernetes. Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« siguruar qĂ« shĂ«rbimi ynĂ« tĂ« funksionojĂ« normalisht me numrin e instancave nâ1, kĂ«shtu qĂ« po e trajnojmĂ« veten qĂ« tĂ« jemi tĂ« gatshĂ«m pĂ«r çdo problemin.
Tani tani po shoh pĂ«rdorimin e zgjidhjeve tĂ« jashtme â tĂ« njĂ«jtit platforma tĂ« cloud â si e vetmja mundĂ«si e saktĂ« pĂ«r kompanitĂ« e reja. Zakonisht nĂ« fillim tĂ« rrugĂ«s ato janĂ« tĂ« kufizuara nĂ« burime, si nga ana e punonjĂ«sve ashtu edhe nga ajo financiare, dhe ndĂ«rtimi dhe mbajtja e njĂ« cloud-i ose njĂ« qendre tĂ« dhĂ«nash Ă«shtĂ« shumĂ« e shtrenjtĂ« dhe e lodhshme. Ofruesit e cloud lejojnĂ« minimizimin e kĂ«tyre shpenzimeve, duke siguruar shpejt burimet e nevojshme pĂ«r tĂ« punuar kĂ«tu dhe tani, pĂ«rveç kĂ«saj, duke paguar kĂ«to resurse sipas pĂ«rdorimit. Sa i pĂ«rket kompanisĂ« "URUS", ne do tĂ« vazhdojmĂ« tĂ« jemi besnikĂ« ndaj Kubernetes nĂ« cloud. Por kush e di, ndoshta do tĂ« na nevojitet tĂ« zgjerohemi gjeografikisht, ose tĂ« zbatojmĂ« zgjidhje mbi ndonjĂ« pajisje specifike. Apo ndoshta, sasia e burimeve tĂ« konsumuar do tĂ« justifikojĂ« Kubernetes-in tonĂ« mbi bare-metal, si nĂ« ditĂ«t e vjetra. đ
ĂfarĂ« nxorĂ«m nga pĂ«rvoja e punĂ«s me shĂ«rbimet e cloud
Filluam tĂ« pĂ«rdorim Kubernetes mbi bare metal, dhe madje edhe aty ai ishte nĂ« mĂ«nyrĂ«n e tij tĂ« mirĂ«. Por forcat e tij tĂ« forta u zbuluan pikĂ«risht si njĂ« komponent aaS nĂ« cloud. NĂ«se vendosni njĂ« qĂ«llim dhe tĂ« automatizoni gjithçka sa mĂ« shumĂ«, do tĂ« arrini tĂ« shmangni vendor lock-in dhe kalimi mes ofruesve tĂ« cloud do tĂ« zgjasĂ« disa orĂ«, ndĂ«rsa qelizat nervore do tĂ« mbeten me ne. KompanitĂ« e tjera mund tĂ« kĂ«shillojmĂ«: nĂ«se dĂ«shironi tĂ« nisni shĂ«rbimin tuaj (cloud), duke pasur burime tĂ« kufizuara dhe velocitet maksimal pĂ«r zhvillimin â filloni tani me qiranĂ« e burimeve tĂ« cloud, ndĂ«rsa ndĂ«rtimi i qendrĂ«s suaj tĂ« dhĂ«nash bĂ«jeni pasi Forbes tĂ« shkruaj pĂ«r ju.
Burimi: habr.com
