Compania «URUS» a experimentat Kubernetes în diverse forme: implementare independentă pe bare metal, în Google Cloud, și apoi a mutat platforma sa în cloud-ul Mail.ru Cloud Solutions (MCS). Igor Shishkin povestește despre cum au ales noul furnizor de cloud și cum au reușit migrarea în doar două ore.), administrator de sistem senior la «URUS».
Ce face «URUS»
Există multe modalități de a îmbunătăți calitatea mediului urban, iar una dintre ele este de a-l face ecologic sigur. Exactly la asta lucrează compania «URUS — Servicii Digitale Inteligente». Aici sunt implementate soluții care ajută întreprinderile să controleze indicatorii ecologici importanti și să reducă impactul negativ asupra mediului înconjurător. Senzorii colectează date despre compoziția aerului, nivelul zgomotului și altele, apoi le trimite către platforma unificată «URUS — Ecomon» pentru analiză și formularea de recomandări.
Cum funcționează «URUS» din interior
Clientul tipic al «URUS» este o companie situată într-o zonă rezidențială sau în apropierea acesteia. Poate fi o fabrică, un port, o gară feroviară sau orice alt obiect. Dacă clientul nostru a primit deja un avertisment, a fost amendat pentru poluarea mediului sau vrea să reducă zgomotul și emisiile dăunătoare, el vine la noi, iar noi îi oferim o soluție gata făcută pentru monitorizarea ecologică.
Pe graficul de monitorizare a concentrației de H2S, se observă emisiile regulate de noapte ale întreprinderii din apropiere.
Dispozitivele pe care le folosim în «URUS» conțin mai mulți senzori care colectează informații despre conținutul anumitor gaze, nivelul zgomotului și alte date pentru evaluarea stării de mediu. Numărul exact de senzori este întotdeauna determinat de sarcina specifică.
În funcție de specificul măsurătorilor, dispozitivele cu senzori pot fi amplasate pe pereții clădirilor, pe stâlpi și în alte locuri arbitrare. Fiecare astfel de dispozitiv colectează informații, le agregă și le trimite la un gateway de recepție a datelor. Acolo salvăm datele pentru stocare pe termen lung și le prelucrăm pentru analiza ulterioară. Un exemplu simplu a ceea ce obținem la ieșire după analiză este indicele calității aerului, cunoscut și sub denumirea de AQI.
Pe platforma noastră funcționează simultan multe alte servicii, dar în principal acestea au un caracter de suport. De exemplu, serviciul de notificare trimite clienților alerte dacă unul dintre parametrii urmăriți (de exemplu, conținutul de CO2) depășește valoarea acceptabilă.
Cum stocăm datele. Povestea cu Kubernetes pe bare metal
În proiectul de ecomonitoring „URUS” există mai multe depozite de date. În unul păstrăm datele „neprelucrate” - ceea ce am obținut direct de la dispozitive. Acest depozit este ca un band magnetic, similar cu casetele vechi, având o istorie a tuturor indicatorilor. Al doilea tip de depozit este folosit pentru datele prelucrate - datele de la dispozitive, îmbogățite cu metadate despre relațiile dintre senzori și citirile dispozitivelor, apartenența la organizații, locurile de amplasare etc. Aceste informații permit evaluarea dinamică a modului în care un anumit indicator s-a schimbat într-o anumită perioadă de timp. Depozitul de date „neprelucrate” este folosit, de asemenea, ca backup și pentru recuperarea datelor prelucrate, dacă va apărea o necesitate.
Când acum câțiva ani căutam modalitatea de a rezolva problema stocării, aveam două opțiuni pentru a alege platforma: Kubernetes și OpenStack. Dar cum ultima opțiune pare destul de monstruoasă (doar priviți arhitectura sa pentru a vă convinge), ne-am oprit asupra Kubernetes-ului. Un alt argument în favoarea sa a fost gestionarea programatică relativ simplă, precum și posibilitatea de a aloca mai flexibil chiar și nodurile fizice în funcție de resurse.
Paralel cu învățarea Kubernetes-ului, am studiat și modalitățile de stocare a datelor; în timp ce toate depozitele noastre erau păstrate în Kubernetes pe hardware-ul nostru, am obținut o expertiză excelentă. Tot ceea ce aveam atunci trăia exact pe Kubernetes: depozit stateful, sistem de monitorizare, CI/CD. Kubernetes a devenit pentru noi o platformă all-in-one.
Dar ne ne-am dorit să lucrăm cu Kubernetes ca serviciu, ci să ne ocupăm de suportul și dezvoltarea sa. În plus, nu ne plăcea cât de costisitor era să-l menținem pe bare metal, iar dezvoltarea era necesară constant! De exemplu, una dintre primele noastre sarcini a fost să integrăm controlerele Ingress Kubernetes în infrastructura noastră de rețea. Aceasta este o sarcină complexă, mai ales dacă ne gândim că în acel moment nu exista nimic pregătit pentru gestionarea programatică a resurselor, cum ar fi înregistrările DNS sau alocarea. adreselor IP. Mai târziu, am început să experimentăm cu stocarea externă de date. Nu am ajuns niciodată la implementarea PVC-controller-ului, dar deja atunci a fost clar că este un mare volum de muncă pentru care trebuie să alocăm specialiști separați.
Trecerea pe Google Cloud Platform — o soluție temporară
Ne-am dat seama că așa nu mai poate continua și ne-am transferat datele de pe bare metal pe Google Cloud Platform. De fapt, atunci pentru o companie rusă nu existau prea multe opțiuni interesante: în afară de Google Cloud Platform, un serviciu similar oferea doar Amazon, dar ne-am oprit totuși asupra soluției de la Google. La acea vreme, ni s-a părut mai economic, mai apropiat de Upstream, fără a mai vorbi de faptul că Google este el însuși o formă de PoC Kubernetes în producție.
Prima problemă serioasă a apărut pe fundal în paralel cu creșterea bazei noastre de clienți. Când am avut nevoie să stocăm date personale, ne-am confruntat cu o alegere: fie lucrăm cu Google și încălcăm legile rusești, fie căutăm o alternativă în Federația Rusă. Alegerea, în general, a fost previzibilă. 🙂
Cum ne-am imaginat serviciul cloud ideal
La începutul căutărilor, știam deja ce vrem să obținem de la viitorul nostru furnizor de cloud. Ce serviciu căutam:
- Rapid și flexibil. Unul care să ne permită să adăugăm rapid o nouă nod sau să desfășurăm ceva în orice moment.
- Accesibil. Ne preocupa foarte mult aspectul financiar, deoarece aveam resurse limitate. Știam deja că vrem să lucrăm cu Kubernetes și acum provocarea era să minimizăm costurile acestuia pentru a crește sau, măcar, a menține eficiența utilizării acestei soluții.
- Automatizat. Am planificat să lucrăm cu serviciul prin API, fără manageri și apeluri telefonice sau situații în care trebuie să ridicăm manual zeci de noduri în regim de urgență. Deoarece majoritatea proceselor noastre sunt automatizate, același lucru l-am așteptat de la serviciul cloud.
- Cu servere în RF. Desigur, am planificat să respectăm legislația rusă și celebrul 152-FZ.
La vremea respectivă, furnizorii de Kubernetes în modelul aaS din Rusia erau puțini, iar alegând un furnizor, era important pentru noi să nu renunțăm la prioritățile noastre. Echipa Mail.ru Cloud Solutions, cu care am început să colaborăm și colaborăm și acum, ne-a oferit un serviciu complet automatizat, cu suport API și un panou de control convenabil, care include Horizon — cu acesta am putut ridica rapid un număr arbitrar de noduri.
Cum am reușit să migram în MCS în două ore
În astfel de migrări, multe companii se confruntă cu dificultăți și eșecuri, dar în cazul nostru nu a fost așa. Ne-a fost noroc: deoarece înainte de migrare lucram deja pe Kubernetes, am corectat doar trei fișiere și ne-am lansat serviciile pe noua platformă cloud, în MCS. Vreau să reamintesc că la acea vreme ne-am retras complet de pe bare metal și activam pe Google Cloud Platform. Așadar, migrarea în sine nu a durat mai mult de două ore, iar timpul suplimentar (aproximativ o oră) a fost necesar pentru copierea datelor de pe dispozitivele noastre. Atunci foloseam deja Spinnaker (un serviciu CD multi-cloud pentru asigurarea Continous Delivery). Acesta l-am adăugat rapid în noul cluster și am continuat să lucrăm în mod obișnuit.
Datorită automatizării proceselor de dezvoltare și CI/CD, în «УРУС» se ocupă un specialist (și anume eu). La un moment dat, am avut un alt administrator de sistem care lucra cu mine, dar apoi s-a dovedit că tot programul de rutină a fost deja automatizat și din partea produsului nostru principal cerințele au crescut, așa că are sens să direcționăm resursele spre asta.
Am primit de la furnizorul cloud ceea ce ne-am așteptat, deoarece am început colaborarea fără iluzii. Dacă au fost incidente, acestea au fost în principal tehnice și ușor explicabile prin relativitatea nouă a serviciului. Cel mai important, echipa MCS remediază rapid neajunsurile și răspunde prompt la întrebările din mesagerii.
Comparând experiența cu Google Cloud Platform, în cazul lor nici măcar nu știam unde se află butonul de feedback, deoarece pur și simplu nu era nevoie de el. Iar dacă apăreau probleme, Google trimitea singur notificări unilaterale. Însă în cazul MCS, un avantaj mare este că se află cât mai aproape de clienții ruși — atât din punct de vedere teritorial, cât și mental.
Cum vedem viitorul muncii cu serviciile cloud
În prezent, munca noastră este strâns legată de Kubernetes, iar acesta ne satisface complet din punct de vedere al sarcinilor infrastructurale. Așadar, nu plănuim să migram undeva, deși introducem constant noi practici și servicii pentru a simplifica sarcinile de rutină și a automatiza altele noi, pentru a îmbunătăți stabilitatea și fiabilitatea serviciilor... Acum lansăm serviciul Chaos Monkey (de fapt utilizăm chaoskube, dar conceptul rămâne același :), care a fost creat inițial la Netflix. Chaos Monkey face un singur lucru simplu: șterge aleator un pod din Kubernetes la un moment dat. Acest lucru este necesar pentru ca serviciul nostru să funcționeze normal cu un număr de instanțe n–1, astfel ne obișnuim să fim pregătiți pentru orice defecțiuni.
Acum văd utilizarea soluțiilor externe — aceleași platforme cloud — ca fiind singura alegere corectă pentru companiile tinere. De obicei, la început, acestea sunt limitate în resurse, atât umane, cât și financiare, iar a construi și întreține un cloud propriu sau un centru de date este prea costisitor și consumator de resurse. Furnizorii de cloud permit minimizarea acestor costuri, resursele necesare pentru funcționarea serviciilor putând fi obținute rapid, plătind efectiv pentru ele. În ceea ce privește compania „УРУС”, momentan vom rămâne loiali Kubernetes în cloud. Dar cine știe, poate va trebui să ne extindem geografic sau să implementăm soluții pe baza unui echipament specific. Sau, poate, cantitatea de resurse consumate va justifica un Kubernetes propriu pe bare-metal, ca în vremurile de altă dată. 🙂
Ce am învățat din experiența cu serviciile cloud
Am început să folosim Kubernetes pe bare metal și chiar și acolo a fost bun în felul său. Însă, punctele sale forte au fost cu adevărat valorificate în cadrul unui component aaS în cloud. Dacă ne stabilim un obiectiv și automatizăm totul cât mai mult posibil, putem evita vendor lock-in, iar migrarea între furnizorii de cloud va dura câteva ore, lăsându-ne nervii intacti. Altora le putem recomanda: doriți să lansați propriul serviciu (în cloud), având resurse limitate și o maximă viteză de dezvoltare? Începeți chiar acum cu închirierea de resurse cloud, iar centrul de date să-l construiți după ce Forbes vă va scrie.
Sursa: habr.com
