Podjetje URUS je preizkusilo Kubernetes v različnih oblikah: neodvisno uvajanje na golo kovino, v Google Cloud, nato pa svojo platformo preneslo v oblak Mail.ru Cloud Solutions (MCS). Igor Šiškin pripoveduje, kako so izbrali novega ponudnika oblaka in kako jim je uspel prehod nanj v rekordnih dveh urah (), višji sistemski skrbnik na URUS.
Kaj počne URUS?
Obstaja veliko načinov za izboljšanje kakovosti mestnega okolja in eden od njih je, da ga naredimo okolju prijaznega. Prav na tem se ukvarja podjetje URUS - Pametne digitalne storitve. Tu izvajajo rešitve, ki podjetjem pomagajo spremljati pomembne okoljske kazalce in zmanjšati njihov negativni vpliv na okolje. Senzorji zbirajo podatke o sestavi zraka, ravni hrupa in drugih parametrih ter jih nato pošiljajo na enotno platformo URUS-Ekomon za analizo in pripravo priporočil.
Kako URUS deluje od znotraj
Tipičen naročnik URUS-a je podjetje, ki se nahaja v ali v bližini stanovanjskega naselja. To je lahko tovarna, pristanišče, železniško skladišče ali kateri koli drug objekt. Če je naša stranka že prejela opozorilo, bila kaznovana zaradi onesnaževanja okolja ali želi manj hrupa, zmanjšati količino škodljivih izpustov, pride k nam, mi pa ji ponudimo že pripravljeno rešitev za monitoring okolja.
Graf spremljanja koncentracije H2S prikazuje redne nočne emisije iz bližnjega obrata
Naprave, ki jih uporabljamo v URUS-u, vsebujejo več senzorjev, ki zbirajo informacije o vsebnosti določenih plinov, ravni hrupa in druge podatke za oceno okoljske situacije. Točno število senzorjev je vedno določeno s specifično nalogo.
Glede na specifiko meritev lahko naprave s senzorji postavimo na stene zgradb, stebre in druga poljubna mesta. Vsaka taka naprava zbira informacije, jih združuje in pošilja v prehod za sprejem podatkov. Tam shranimo podatke za dolgoročno hrambo in jih predhodno obdelamo za kasnejšo analizo. Najenostavnejši primer tega, kar dobimo kot rezultat analize, je indeks kakovosti zraka, znan tudi kot AQI.
Vzporedno na naši platformi delujejo številne druge storitve, ki pa so predvsem storitvene narave. Storitev obveščanja na primer pošilja obvestila odjemalcem, če kateri od spremljanih parametrov (na primer vsebnost CO2) presega dovoljeno vrednost.
Kako hranimo podatke. Zgodba o Kubernetesu na goli kovini
Projekt okoljskega monitoringa URUS ima več podatkovnih skladišč. V enem hranimo »surove« podatke – tiste, ki smo jih prejeli neposredno od samih naprav. Ta shramba je "magnetni" trak, kot na starih kasetah, z zgodovino vseh indikatorjev. Druga vrsta shranjevanja se uporablja za predprocesirane podatke – podatke iz naprav, obogatene z metapodatki o povezavah med senzorji in odčitki samih naprav, pripadnosti organizacijam, lokacijah ipd. Te informacije vam omogočajo dinamično ocenjevanje delovanja določenega indikatorja. spreminjal v določenem časovnem obdobju. »Surovo« shrambo podatkov uporabljamo med drugim kot varnostno kopijo in za obnovitev predprocesiranih podatkov, če se pojavi potreba po tem.
Ko smo pred nekaj leti želeli rešiti problem shranjevanja, smo imeli na izbiro dve platformi: Kubernetes in OpenStack. A ker je slednja videti precej pošastna (v to se lahko prepričate le po njeni arhitekturi), smo se odločili za Kubernetes. Drugi argument v prid je bil razmeroma preprost programski nadzor, zmožnost bolj prilagodljivega rezanja celo strojnih vozlišč glede na vire.
Vzporedno z obvladovanjem samega Kubernetesa smo preučevali tudi načine shranjevanja podatkov, medtem ko smo vso svojo shrambo v Kubernetesu hranili na lastni strojni opremi, smo dobili odlično strokovno znanje. Vse, kar smo takrat živeli na Kubernetesu: shranjevanje s polnim stanjem, nadzorni sistem, CI/CD. Kubernetes je za nas postal platforma vse v enem.
Vendar smo želeli sodelovati s Kubernetesom kot storitvijo in ne sodelovati pri njegovi podpori in razvoju. Poleg tega nam ni bilo všeč, koliko nas je stalo vzdrževanje na goli kovini, in nenehno smo potrebovali razvoj! Ena od prvih nalog je bila na primer integracija krmilnikov Kubernetes Ingress v omrežno infrastrukturo naše organizacije. To je okorno opravilo, še posebej če upoštevamo, da takrat še ni bilo nič pripravljenega za programsko upravljanje virov, kot so zapisi DNS ali dodeljevanje naslovov IP. Kasneje smo začeli eksperimentirati z zunanjim shranjevanjem podatkov. Nismo nikoli prišli do implementacije PVC krmilnika, vendar je že takrat postalo jasno, da je to veliko področje dela, ki zahteva predane strokovnjake.
Prehod na Google Cloud Platform je začasna rešitev
Ugotovili smo, da se to ne more nadaljevati, in svoje podatke prenesli iz gole kovine v Google Cloud Platform. Pravzaprav takrat ni bilo veliko zanimivih možnosti za rusko podjetje: poleg Google Cloud Platform je podobno storitev ponujal le Amazon, vendar smo se vseeno odločili za Googlovo rešitev. Takrat se nam je zdel bolj ekonomsko donosen, bližje Upstreamu, da ne omenjam dejstva, da je sam Google nekakšen PoC Kubernetes in Production.
Prvi večji problem se je pojavil na obzorju, ko se je naša baza strank povečala. Ko smo imeli potrebo po shranjevanju osebnih podatkov, smo bili postavljeni pred izbiro: ali delamo z Googlom in kršimo ruske zakone ali pa iščemo alternativo v Ruski federaciji. Izbira je bila na splošno predvidljiva. 🙂
Kako smo videli idealno storitev v oblaku
Na začetku iskanja smo že vedeli, kaj želimo dobiti od bodočega ponudnika oblaka. Katero storitev smo iskali:
- Hitro in prilagodljivo. Tako, da lahko kadar koli hitro dodamo novo vozlišče ali nekaj razmestimo.
- Poceni. Zelo nas je skrbelo finančno vprašanje, saj smo bili omejeni z sredstvi. Že prej smo vedeli, da želimo delati s Kubernetesom, zdaj pa je bila naloga minimizirati njegove stroške, da bi povečali ali vsaj ohranili učinkovitost uporabe te rešitve.
- avtomatizirano. Načrtovali smo delo s storitvijo prek API-ja, brez upraviteljev in telefonskih klicev ali situacij, ko moramo ročno dvigniti več deset vozlišč v nujnem načinu. Ker je večina naših procesov avtomatiziranih, smo enako pričakovali tudi od storitve v oblaku.
- S strežniki v Ruski federaciji. Seveda smo načrtovali upoštevanje ruske zakonodaje in istega 152-FZ.
Takrat je bilo v Rusiji malo ponudnikov Kubernetes aaS in pri izbiri ponudnika nam je bilo pomembno, da ne ogrozimo svojih prioritet. Ekipa Mail.ru Cloud Solutions, s katero smo začeli sodelovati in še vedno sodelujemo, nam je zagotovila popolnoma avtomatizirano storitev, s podporo za API in priročno nadzorno ploščo, ki vključuje Horizon - z njo smo lahko hitro dvignili poljubno število vozlišč.
Kako nam je uspelo preiti na MCS v dveh urah
Pri takšnih potezah se marsikatero podjetje srečuje s težavami in padci, pri nas pa jih ni bilo. Imeli smo srečo: ker smo na Kubernetesu delali že pred začetkom selitve, smo preprosto popravili tri datoteke in zagnali naše storitve na novi oblačni platformi MCS. Naj vas spomnim, da smo do takrat končno zapustili golo kovino in živeli na Google Cloud Platform. Zato sama selitev ni trajala več kot dve uri, poleg tega pa je nekaj več časa (približno eno uro) porabil za kopiranje podatkov iz naših naprav. Takrat smo že uporabljali Spinnaker (storitev CD v več oblakih za zagotavljanje neprekinjene dostave). Prav tako smo ga hitro dodali v novo gručo in nadaljevali z delom kot običajno.
Zahvaljujoč avtomatizaciji razvojnih procesov in CI/CD, za Kubernetes pri URUS skrbi en specialist (in to sem jaz). Na neki stopnji je z menoj delal še en sistemski skrbnik, potem pa se je izkazalo, da smo že avtomatizirali vso glavno rutino in je bilo nalog na strani našega glavnega produkta vse več in je bilo smiselno sredstva usmeriti v to.
Od ponudnika oblaka smo prejeli tisto, kar smo pričakovali, saj smo se sodelovanja lotili brez utvar. Če je prišlo do kakšnih incidentov, so bili večinoma tehnični in taki, ki jih je zlahka razložiti z relativno svežino storitve. Glavna stvar je, da ekipa MCS hitro odpravi pomanjkljivosti in hitro odgovori na vprašanja v glasnikih.
Če primerjam svojo izkušnjo z Google Cloud Platform, v njihovem primeru sploh nisem vedel, kje je gumb za povratne informacije, saj ga enostavno ni bilo potrebno. In če je prišlo do težav, je Google sam poslal enostranska obvestila. Toda v primeru MCS se mi zdi velika prednost ta, da so čim bližje ruskim strankam – tako geografsko kot mentalno.
Kako vidimo delo z oblaki v prihodnosti
Zdaj je naše delo tesno povezano s Kubernetesom in nam z vidika infrastrukturnih nalog povsem ustreza. Zato ne nameravamo nikamor migrirati z nje, čeprav nenehno uvajamo nove prakse in storitve za poenostavitev rutinskih opravil in avtomatizacijo novih, povečanje stabilnosti in zanesljivosti storitev ... Sedaj lansiramo storitev Chaos Monkey (natančneje , uporabljamo chaoskube, vendar to ne spremeni koncepta: ), ki ga je prvotno ustvaril Netflix. Chaos Monkey naredi eno preprosto stvar: ob naključnem času izbriše naključni pod Kubernetes. To je potrebno, da naša storitev normalno živi s številom instanc n–1, zato se urimo, da smo pripravljeni na morebitne težave.
Zdaj se mi zdi uporaba rešitev tretjih oseb - istih oblačnih platform - edina prava stvar za mlada podjetja. Običajno so na začetku svoje poti omejeni z viri, tako človeškimi kot finančnimi, izgradnja in vzdrževanje lastnega oblaka ali podatkovnega centra pa je predrago in delovno zahtevno. Ponudniki v oblaku vam omogočajo, da te stroške minimizirate, od njih lahko hitro pridobite vire, ki so potrebni za delovanje storitev tukaj in zdaj, in te vire plačate naknadno. Pri podjetju URUS pa bomo zaenkrat ostali zvesti Kubernetesu v oblaku. A kdo ve, morda se bomo morali geografsko razširiti ali implementirati rešitve na podlagi kakšne specifične opreme. Ali pa bo morda količina porabljenih virov upravičila lastni Kubernetes na goli kovini, kot v dobrih starih časih. 🙂
Kaj smo se naučili pri delu s storitvami v oblaku
Kubernetes smo začeli uporabljati na goli kovini in tudi tam je bil po svoje dober. Toda njegove prednosti so bile razkrite prav kot komponenta aaS v oblaku. Če si zastavite cilj in vse skupaj čim bolj avtomatizirate, se boste lahko izognili vendor lock-in in prehajanje med ponudniki v oblaku bo trajalo nekaj ur, živčne celice pa bodo ostale pri nas. Drugim podjetjem lahko svetujemo: če želite zagnati lastno (oblačno) storitev z omejenimi sredstvi in največjo hitrostjo razvoja, začnite takoj z najemom oblačnih virov in zgradite svoj podatkovni center, ko Forbes piše o vas.
Vir: www.habr.com