Compania URUS a încercat Kubernetes sub diferite forme: implementare independentă pe bare metal, în Google Cloud, apoi și-a transferat platforma în cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin povestește cum au ales un nou furnizor de cloud și cum au reușit să migreze la el într-un record de două ore (), administrator senior de sistem 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 prietenos cu mediul. Exact la asta lucrează compania URUS - Smart Digital Services. Aici implementează soluții care ajută întreprinderile să monitorizeze indicatori importanți de mediu și să reducă impactul lor negativ asupra mediului. Senzorii colectează date despre compoziția aerului, nivelul de zgomot și alți parametri, apoi le trimit platformei unificate URUS-Ekomon pentru analiză și recomandări.
Cum funcționează URUS din interior
Un client tipic al URUS este o companie situată în sau în apropierea unei zone rezidențiale. Aceasta ar putea fi o fabrică, un port, un depozit feroviar sau orice altă instalație. Dacă clientul nostru a primit deja un avertisment, a fost amendat pentru poluarea mediului sau dorește să facă mai puțin zgomot, să reducă cantitatea de emisii nocive, el vine la noi, iar noi îi oferim deja o soluție gata făcută pentru monitorizarea mediului.
Graficul de monitorizare a concentrației de H2S arată emisiile regulate pe timp de noapte de la o fabrică din apropiere
Dispozitivele pe care le folosim la URUS conțin mai mulți senzori care colectează informații despre conținutul anumitor gaze, niveluri de zgomot și alte date pentru a evalua situația mediului. 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, stâlpilor și altor locuri arbitrare. Fiecare astfel de dispozitiv colectează informații, le agregează și le trimite către gateway-ul de primire a datelor. Acolo salvăm datele pentru stocare pe termen lung și le preprocesăm pentru analize ulterioare. Cel mai simplu exemplu de ceea ce obținem în urma analizei este indicele de calitate a aerului, cunoscut și sub numele de AQI.
În paralel, multe alte servicii funcționează pe platforma noastră, dar sunt în principal de natură de servicii. De exemplu, serviciul de notificare trimite notificări clienților dacă oricare dintre parametrii monitorizați (de exemplu, conținutul de CO2) depășește valoarea permisă.
Cum stocăm datele. Povestea lui Kubernetes pe bare metal
Proiectul de monitorizare a mediului URUS are mai multe depozite de date. Într-una păstrăm datele „brute” - ceea ce am primit direct de la dispozitivele în sine. Acest stocare este o bandă „magnetică”, ca pe casetele vechi, cu un istoric al tuturor indicatorilor. Al doilea tip de stocare este utilizat pentru date preprocesate - date de la dispozitive, îmbogățite cu metadate despre conexiunile dintre senzori și citirile dispozitivelor în sine, afilierea cu organizații, locații etc. Aceste informații vă permit să evaluați dinamic modul în care un anumit indicator a avut schimbat într-o anumită perioadă de timp. Folosim stocarea de date „brută”, printre altele, ca rezervă și pentru restaurarea datelor preprocesate, dacă apare o astfel de nevoie.
Când căutam să ne rezolvăm problema de stocare în urmă cu câțiva ani, aveam două opțiuni de platformă: Kubernetes și OpenStack. Dar din moment ce acesta din urmă arată destul de monstruos (doar uitați-vă la arhitectura sa pentru a vă convinge de asta), ne-am hotărât pe Kubernetes. Un alt argument în favoarea sa a fost controlul software relativ simplu, capacitatea de a tăia mai flexibil chiar și nodurile hardware în funcție de resurse.
În paralel cu stăpânirea Kubernetes în sine, am studiat și modalități de stocare a datelor, în timp ce ne-am păstrat toată stocarea în Kubernetes pe propriul hardware, am primit o expertiză excelentă. Tot ce aveam atunci trăiam pe Kubernetes: stocare completă, sistem de monitorizare, CI/CD. Kubernetes a devenit o platformă all-in-one pentru noi.
Dar am vrut să lucrăm cu Kubernetes ca serviciu și să nu ne angajăm în sprijinul și dezvoltarea acestuia. În plus, nu ne-a plăcut cât de mult ne-a costat să-l menținem pe metal gol și aveam nevoie de dezvoltare constant! De exemplu, una dintre primele sarcini a fost integrarea controlerelor Kubernetes Ingress în infrastructura de rețea a organizației noastre. Aceasta este o sarcină greoaie, mai ales având în vedere că la acel moment nimic nu era pregătit pentru gestionarea resurselor programatice, cum ar fi înregistrările DNS sau alocarea de adrese IP. Mai târziu am început să experimentăm cu stocarea externă a datelor. Nu am apucat niciodată să implementăm controlerul PVC, dar chiar și atunci a devenit clar că acesta era un domeniu mare de lucru care necesita specialiști dedicați.
Trecerea la Google Cloud Platform este o soluție temporară
Ne-am dat seama că acest lucru nu poate continua și ne-am mutat datele din bare metal pe Google Cloud Platform. De fapt, la acea vreme nu prea existau opțiuni interesante pentru o companie rusă: pe lângă Google Cloud Platform, doar Amazon oferea un serviciu similar, dar ne-am hotărât totuși pe soluția de la Google. Atunci ni s-a părut mai profitabil din punct de vedere economic, mai aproape de Upstream, ca să nu mai vorbim de faptul că Google însuși este un fel de PoC Kubernetes în Producție.
Prima problemă majoră a apărut la orizont pe măsură ce baza noastră de clienți creștea. 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, fie căutăm o alternativă în Federația Rusă. Alegerea, în general, a fost previzibilă. 🙂
Cum am văzut serviciul cloud ideal
Până la începutul căutării, știam deja ce dorim să obținem de la viitorul furnizor de cloud. Ce serviciu cautam:
- Rapid și flexibil. Astfel încât să putem adăuga rapid un nou nod sau să implementăm ceva în orice moment.
- Ieftin. Eram foarte îngrijorați de problema financiară, din moment ce aveam resurse limitate. Știam deja că vrem să lucrăm cu Kubernetes, iar acum sarcina era să-i minimizăm costul pentru a crește sau măcar a menține eficiența utilizării acestei soluții.
- automatizate. Ne-am propus să lucrăm cu serviciul prin API, fără manageri și apeluri telefonice sau situații în care trebuie să ridicăm manual câteva zeci de noduri în modul de urgență. Deoarece majoritatea proceselor noastre sunt automatizate, ne așteptam la același lucru de la serviciul cloud.
- Cu servere în Federația Rusă. Desigur, am plănuit să respectăm legislația rusă și același 152-FZ.
La acea vreme, în Rusia erau puțini furnizori Kubernetes aaS, iar atunci când ne alegem un furnizor, era important pentru noi să nu ne compromitem prioritățile. Echipa Mail.ru Cloud Solutions, cu care am început să lucrăm și colaborăm în continuare, ne-a oferit un serviciu complet automatizat, cu suport API și un panou de control convenabil care include Horizon - cu acesta am putea ridica rapid un număr arbitrar de noduri.
Cum am reușit să migrăm la MCS în două ore
În astfel de mișcări, multe companii se confruntă cu dificultăți și eșecuri, dar în cazul nostru nu au existat. Am avut noroc: deoarece lucram deja pe Kubernetes înainte de începerea migrației, pur și simplu am corectat trei fișiere și am lansat serviciile pe noua platformă cloud, MCS. Permiteți-mi să vă reamintesc că până atunci am părăsit în sfârșit bare metal și am trăit pe Google Cloud Platform. Prin urmare, mutarea în sine nu a durat mai mult de două ore, plus puțin mai mult timp (aproximativ o oră) a fost petrecut pentru copierea datelor de pe dispozitivele noastre. Pe atunci folosim deja Spinnaker (un serviciu de CD multi-cloud pentru a oferi Livrare Continuă). De asemenea, l-am adăugat rapid la noul cluster și am continuat să funcționăm ca de obicei.
Datorită automatizării proceselor de dezvoltare și CI/CD, Kubernetes la URUS este gestionat de un singur specialist (și ăsta sunt eu). La un moment dat, un alt administrator de sistem a lucrat cu mine, dar apoi s-a dovedit că am automatizat deja toată rutina principală și erau tot mai multe sarcini din partea produsului nostru principal și era logic să direcționăm resursele către asta.
Am primit ceea ce ne așteptam de la furnizorul de cloud, de când am început cooperarea fără iluzii. Dacă au existat incidente, acestea au fost în mare parte tehnice și care puteau fi explicate cu ușurință prin prospețimea relativă a serviciului. Principalul lucru este că echipa MCS elimină rapid deficiențele și răspunde rapid la întrebările din mesageri.
Dacă îmi compar experiența cu Google Cloud Platform, în cazul lor nici măcar nu știam unde este butonul de feedback, deoarece pur și simplu nu era nevoie de el. Și dacă au apărut probleme, Google însuși a trimis notificări unilateral. Dar în cazul MCS cred că marele avantaj este că sunt cât mai aproape de clienții ruși – atât geografic, cât și psihic.
Cum vedem lucrul cu norii în viitor
Acum munca noastră este strâns legată de Kubernetes și ni se potrivește complet din punctul de vedere al sarcinilor de infrastructură. Prin urmare, nu intenționăm să migrăm nicăieri de pe acesta, deși introducem constant noi practici și servicii pentru a simplifica sarcinile de rutină și a automatiza altele noi, a crește stabilitatea și fiabilitatea serviciilor... Acum lansăm serviciul Chaos Monkey (în special , folosim chaoskube, dar acest lucru nu schimbă conceptul: ), care a fost creat inițial de Netflix. Chaos Monkey face un lucru simplu: șterge un pod Kubernetes aleatoriu la un moment dat. Acest lucru este necesar pentru ca serviciul nostru să trăiască normal cu numărul de instanțe n–1, așa că ne antrenăm să fim pregătiți pentru orice problemă.
Acum văd utilizarea soluțiilor terțe - aceleași platforme cloud - ca fiind singurul lucru potrivit pentru companiile tinere. De obicei, la începutul călătoriei lor, ei sunt limitati în resurse, atât umane, cât și financiare, iar construirea și întreținerea propriului cloud sau centru de date este prea costisitoare și necesită multă muncă. Furnizorii de cloud vă permit să minimizați aceste costuri; puteți obține rapid de la ei resursele necesare funcționării serviciilor aici și acum și să plătiți pentru aceste resurse după fapt. În ceea ce privește compania URUS, deocamdată vom rămâne fideli lui Kubernetes în cloud. Dar cine știe, ar putea fi nevoiți să ne extindem geografic sau să implementăm soluții bazate pe anumite echipamente specifice. Sau poate cantitatea de resurse consumate va justifica propriul Kubernetes pe bare-metal, ca pe vremurile bune. 🙂
Ce am învățat din lucrul cu serviciile cloud
Am început să folosim Kubernetes pe bare metal și chiar și acolo a fost bun în felul său. Dar punctele sale forte au fost dezvăluite tocmai ca o componentă aaS în cloud. Dacă stabiliți un obiectiv și automatizați totul cât mai mult posibil, veți putea evita blocarea furnizorilor și mutarea între furnizorii de cloud va dura câteva ore, iar celulele nervoase vor rămâne cu noi. Vă putem sfătui alte companii: dacă doriți să vă lansați propriul serviciu (cloud), având resurse limitate și viteză maximă de dezvoltare, începeți chiar acum prin a închiria resurse cloud și construiți-vă centrul de date după ce Forbes scrie despre dvs.
Sursa: www.habr.com