A «URUS» cég különböző formáit próbálta ki a Kubernetes-nek: önálló telepítést bare metalra, a Google Cloud-ban, majd a platformját a Mail.ru Cloud Solutions (MCS) felhőbe helyezte át. Igor Shishkin (), a «URUS» vezető rendszergazdája mesél arról, hogyan választották az új felhőszolgáltatót, és hogyan sikerült rekordidő alatt, mindössze két óra alatt migrálni hozzá.
Mivel foglalkozik a «URUS»
Sokféle mód létezik a városi környezet minőségének javítására, és az egyik ilyen az ökológiai biztonság növelése. Ezen dolgozik a «URUS – Okos digitális szolgáltatások» cég. Olyan megoldásokat vezetnek be, amelyek segítenek a vállalatoknak nyomon követni a fontos környezeti mutatókat és csökkenteni a környezetre gyakorolt negatív hatást. Az érzékelők adatokat gyűjtenek a levegő összetételéről, a zajszintről és egyéb paraméterekről, majd egyetlen platformra, az «URUS – Ekomon»-ra küldik azokat elemzésre és ajánlások kidolgozására.
Hogyan működik a «URUS» belülről
A «URUS» tipikus ügyfele olyan cég, amely lakóövezetben vagy annak közelében található. Ez lehet egy gyár, kikötő, vasúti depó vagy bármilyen más létesítmény. Ha ügyfelünk már kapott figyelmeztetést, bírságot róttak ki rá a környezet szennyezése miatt, vagy csökkenteni akarja a zajszintet, illetve a káros kibocsátásokat, akkor hozzánk fordul, és mi kész megoldást kínálunk az ökológiai monitorozásra.
A H2S koncentráció monitoring grafikonján láthatóak az éjszakai, rendszeres kibocsátások a közelben lévő létesítménytől
A «URUS»-ban használt eszközök több érzékelőt tartalmaznak, amelyek információt gyűjtenek bizonyos gázok jelenlétéről, a zajszintről és egyéb adatokról a környezeti állapot felméréséhez. Az érzékelők pontos száma mindig a konkrét feladattól függ.
Mérési sajátosságoktól függően, a szenzoros eszközök falakon, oszlopokon és más véletlenszerű helyeken helyezkedhetnek el. Minden ilyen eszköz információt gyűjt, aggregálja azt, és elküldi az adatok fogadókapujára. Ott hosszú távú tárolásra mentjük az adatokat és előkészítjük a további elemzéshez. Az elemzés után kapható legáltalánosabb példa a levegő minőségi index, az AQI.
Párhuzamosan sok más szolgáltatás is működik platformunkon, de főként támogató jellegűek. Például a mobil értesítési szolgáltatás ügyfeleinknek küld értesítéseket, ha valamelyik figyelt paraméter (például a CO2 szint) meghaladja a megengedett értéket.
Hogyan tároljuk az adatokat. Történet a Kubernetesről bare metal környezetben
Az "URUS" ökomonitoring projektben több adattároló található. Az egyikben a "nyers" adatokat tároljuk – azt, amit közvetlenül az eszközöktől kaptunk. Ez a tároló olyan, mint a régi kazetták „mágneses” szalagével, amely az összes mutatót tartalmazza. A második típusú tároló előkezelt adatok tárolására szolgál – az eszközök adatai, amelyek metainformációkkal vannak gazdagítva a szenzorok közötti kapcsolatokkal, maguknak az eszközöknek a mérésével, valamint a szervezetekhez, helyszínekhez való tartozással stb. kapcsolatosan. Ez az információ lehetővé teszi, hogy dinamikusan felmérjük, hogyan változott egy adott mutató egy meghatározott időszak alatt. A nyers adatokat tartalmazó tárolót egyebek mellett biztonsági mentésként használjuk és a feldolgozott adatok helyreállításához, ha arra szükség lenne.
Amikor néhány évvel ezelőtt megoldást kerestünk a tárolás problémájára, két platformválasztási lehetőségünk volt: Kubernetes és OpenStack. Azonban mivel az utóbbi meglehetősen monstrózusnak tűnt (csak nézze meg az architektúráját, hogy megbizonyosodjon róla), végül a Kubernetes mellett döntöttünk. Egy másik érv mellette a viszonylag egyszerű programozási kezelés volt, valamint a lehetőség, hogy még a fizikai node-okat is rugalmasan feloszthassuk erőforrásaik szerint.
A Kubernetes megismerésével párhuzamosan tanulmányoztuk az adatkezelés módszereit, míg minden tárolónkat a saját hardverünkön belül tartottuk Kubernetes-en, nagyszerű szakértelmet szereztünk. Minden, amink akkor volt, éppen Kubernetes-en élt: stateful tárolás, monitoring rendszer, CI/CD. A Kubernetes számunkra egy all-in-one platform lett.
De szeretnénk, ha a Kubernetes-t szolgáltatásként használnánk, nem pedig annak karbantartásával és fejlesztésével foglalkoznánk. Plusz nem tetszett, mennyibe kerül a bare metal környezet fenntartása, miközben folyamatosan szükség volt a fejlesztésre! Például az egyik első feladatunk az volt, hogy integráljuk a Kubernetes Ingress kontrollereket a szervezetünk hálózati infrastruktúrájába. Ez egy nehézkes feladat, különösen, ha figyelembe vesszük, hogy abban az időszakban semmi sem volt előkészítve a DNS rekordokhoz vagy kiemeltekhez hasonló erőforrások programozott kezeléséhez. IP-címek. Később elkezdtünk kísérletezni külső adatkezelő rendszerekkel. A PVC vezérlő megvalósítására soha nem jutottunk el, de már ekkor világossá vált, hogy ez egy nagy munka, amelyhez külön szakembereket kell kijelölni.
A Google Cloud Platform-ra való áttérés - átmeneti megoldás.
Megértettük, hogy így tovább nem mehet, és az adatainkat a bare metal-ról a Google Cloud Platform-ra helyeztük át. Valójában akkoriban nem sok érdekes lehetőség állt rendelkezésre orosz cégek számára: a Google Cloud Platform mellett az Amazon kínált hasonló szolgáltatást, de végül a Google megoldásánál maradtunk. Akkor gazdaságilag kedvezőbbnek tűnt, és közelebb állt az Upstream-hez, nem is beszélve arról, hogy a Google maga egyfajta PoC Kubernetes a Production-hoz.
Az első komoly probléma egyidőben bontakozott ki, ahogy nőtt az ügyfélkörünk. Amikor szükségessé vált a személyes adatok tárolása, egy választás előtt álltunk: vagy a Google-val dolgozunk, megsértve az orosz törvényeket, vagy alternatívát keresünk Oroszországban. A választás alapvetően kiszámítható volt. 🙂
Hogyan képzeltük el az ideális felhőszolgáltatást
A keresés kezdetére már tudtuk, mit szeretnénk kapni a jövőbeli felhőszolgáltatótól. Milyen szolgáltatást kerestünk:
- Gyors és rugalmas. Olyan, hogy bármikor gyorsan tudjunk új csomópontot hozzáadni vagy valamit telepíteni.
- Költséghatékony. Nagyon aggódtunk a pénzügyi kérdések miatt, mivel korlátozott erőforrásokkal dolgoztunk. Már tudtuk, hogy Kubernetes-szel szeretnénk dolgozni, és most az volt a feladat, hogy minimalizáljuk a költségeit, hogy növeljük vagy legalább megőrizzük ennek a megoldásnak a hatékonyságát.
- Automatizált. A szolgáltatást API-n keresztül terveztük használni, menedzserek és telefonhívások nélkül, elkerülve azokat a helyzeteket, amikor manuálisan kell felállítani több tucat csomópontot sürgős esetekben. Mivel a legtöbb folyamatunk automatizált, ugyanezt vártuk a felhőszolgáltatástól.
- Oroszországban lévő szerverekkel. Természetesen terveztük, hogy betartjuk az orosz jogszabályokat és a 152-FZ-t.
Abban az időben Oroszországban nagyon kevés Kubernetes szolgáltató működött aaaS modellben, és fontos volt számunkra, hogy ne mondjunk le a prioritásainkról a szolgáltató kiválasztásakor. A Mail.ru Cloud Solutions csapata, akikkel elkezdtük a munkát és azóta is együttműködünk, egy teljesen automatizált szolgáltatást kínált számunkra, API-támogatással és egy felhasználóbarát vezérlőpulttal, amelyben megtalálható a Horizon – ezzel gyorsan létrehozhattunk tetszőleges számú csomópontot.
Hogyan sikerült két óra alatt migrálnunk az MCS-be
Az ilyen áttelepítések során sok vállalat nehézségekkel és kudarcokkal néz szembe, de esetünkben ez nem történt meg. Szerencsénk volt: mivel a migráció előtt már dolgoztunk Kubernetes-en, csak három fájlt kellett módosítanunk, és elindítani a szolgáltatásainkat az új felhőplatformon, az MCS-en. Emlékeztetnék arra, hogy addigra már végleg elhagytuk a bare metal-t, és Google Cloud Platformon éltünk. Így az áttelepítés nem tartott tovább két óránál, plusz még egy kis idő (körülbelül egy óra) elment az adataink másolására az eszközeinkről. Akkor már használtuk a Spinnakert (multifelhős CD-szolgáltatás a folyamatos szállítás biztosítására). Ezt is gyorsan hozzáadtuk az új klaszterhez, és folytattuk a munkát a megszokott módon.
A fejlesztési és CI/CD folyamatok automatizálásának köszönhetően az 'URUS'-ban egy szakember foglalkozik Kubernetes-szel (és ez én vagyok). Egy időben még egy rendszergazda is dolgozott velem, de aztán kiderült, hogy az összes fő rutinfeladatot már automatizáltuk, és a fő termékünkkel kapcsolatos feladatok egyre növekvő száma miatt érdemes inkább ott terelni a forrásokat.
A felhőszolgáltatótól azt kaptuk, amire számítottunk, mivel a kapcsolatfelvételt illúziók nélkül kezdtük. Ha voltak is valamilyen incidensek, azok többsége technikai jellegű volt, és könnyen magyarázható a szolgáltatás viszonylagos frissességével. A legfontosabb az, hogy az MCS csapata gyorsan javítja a hibákat, és hamar reagál a kérdésekre a messengeren.
Ha összehasonlítom a Google Cloud Platform tapasztalataimat, akkor ott még a visszajelzés gomb helyét sem tudtam, mivel egyszerűen nem volt rá szükség. Ha pedig valamilyen probléma merült fel, a Google egyoldalúan értesítéseket küldött. De az MCS esetében nagy előnynek tartom, hogy a lehető legközelebb vannak az orosz ügyfelekhez – térben és mentálisan is.
Hogyan látjuk a felhők jövőbeli működését
Jelenleg a munkánk szorosan kapcsolódik a Kuberneteshez, amely teljes mértékben kielégít minket az infrastruktúra feladataiban. Így nem tervezünk migrálni máshová, bár folyamatosan új módszereket és szolgáltatásokat vezetünk be a rutinfeladatok egyszerűsítése és az új feladatok automatizálása, valamint a szolgáltatások stabilitásának és megbízhatóságának növelése érdekében… Jelenleg a Chaos Monkey szolgáltatást indítjuk (konkrétan a chaoskube-ot használjuk, de a koncepció nem változik :), amelyet eredetileg a Netflix hozott létre. A Chaos Monkey egy egyszerű dolgot csinál: véletlenszerű időpontokban eltávolít egy véletlen podot a Kubernetesben. Erre azért van szükség, hogy a szolgáltatásunk normálisan működjön az n–1 példány szám mellett, ezzel szoktatva magunkat a váratlan hibák kezelésére.
Jelenleg a külső megoldások — beleértve a felhőplatformokat — használatát tartom a fiatal cégek számára a legjobb megoldásnak. Általában az út elején korlátozva vannak erőforrásaik, mind munkaerő, mind pénzügyi szempontból, és túl drága és időigényes egy saját felhő vagy adatközpont kiépítése és fenntartása. A felhőszolgáltatók lehetővé teszik ezen költségek minimalizálását, gyorsan hozzáférhetünk a szolgáltatások működéséhez szükséges erőforrásokhoz, és azokat a felhasználás alapján fizethetjük. Az „URUS” cég esetében továbbra is ragaszkodunk a Kuberneteshez a felhőben. De ki tudja, lehet, hogy földrajzilag terjeszkednünk kell, vagy olyan specifikus berendezésekre építő megoldásokat kell bevezetnünk. Vagy talán a felhasznált erőforrások mennyisége igazolja a saját Kubernetesét bare-metal környezetben, mint a régi szép időkben. 🙂
Mit tanultunk a felhőszolgáltatásokkal kapcsolatos tapasztalatainkból
Kezdtünk bare metal környezetben Kubernetes-t használni, és ott is megvolt a maga előnye. De az igazi erőssége kifejezetten aaS komponensként a felhőben bontakozott ki. Ha célokat állítunk fel és mindent maximálisan automatizálunk, elkerülhetjük a szolgáltatói zárolást, és a felhőszolgáltatók közötti átállás csak néhány órát vesz igénybe, míg idegrendszerünk épen marad. Más cégeknek azt tudjuk tanácsolni: ha korlátozott erőforrásokkal és maximális fejlesztési sebességgel szeretnél saját (felhő) szolgáltatást indítani, kezdd el most az erőforrások bérlésével, a saját adatközpontodat pedig építsd meg, miután a Forbes ír rólad.
Forrás: habr.com
