L'empresa URUS va provar Kubernetes de diferents formes: desplegament independent sobre metall nu, a Google Cloud, i després va transferir la seva plataforma al núvol Mail.ru Cloud Solutions (MCS). Igor Shishkin explica com van triar un nou proveïdor de núvol i com van aconseguir migrar-hi en dues hores rècord (), administrador sènior de sistemes a URUS.
Què fa URUS?
Hi ha moltes maneres de millorar la qualitat de l'entorn urbà, i una d'elles és fer-lo respectuós amb el medi ambient. Això és exactament en el que treballa l'empresa URUS - Smart Digital Services. Aquí implementen solucions que ajuden les empreses a controlar indicadors ambientals importants i reduir el seu impacte negatiu sobre el medi ambient. Els sensors recullen dades sobre la composició de l'aire, el nivell de soroll i altres paràmetres, i després les envien a la plataforma unificada URUS-Ekomon per analitzar-les i fer recomanacions.
Com funciona URUS des de dins
Un client típic d'URUS és una empresa situada dins o prop d'una zona residencial. Pot ser una fàbrica, un port, un dipòsit ferroviari o qualsevol altra instal·lació. Si el nostre client ja ha rebut un avís, ha estat multat per contaminació ambiental, o vol fer menys soroll, reduir la quantitat d'emissions nocives, ve a nosaltres i ja li oferim una solució preparada per a la vigilància ambiental.
El gràfic de control de la concentració d'H2S mostra les emissions nocturnes regulars d'una planta propera
Els dispositius que utilitzem a URUS contenen diversos sensors que recullen informació sobre el contingut de determinats gasos, nivells de soroll i altres dades per avaluar la situació ambiental. El nombre exacte de sensors sempre ve determinat per la tasca específica.
Depenent de les especificitats de les mesures, els dispositius amb sensors es poden localitzar a les parets d'edificis, pals i altres llocs arbitraris. Cadascun d'aquests dispositius recull informació, l'agrega i l'envia a la passarel·la de recepció de dades. Allà desem les dades per a l'emmagatzematge a llarg termini i les preprocessem per a una anàlisi posterior. L'exemple més senzill del que obtenim com a resultat de l'anàlisi és l'índex de qualitat de l'aire, també conegut com AQI.
Paral·lelament, molts altres serveis operen a la nostra plataforma, però principalment són de naturalesa de servei. Per exemple, el servei de notificacions envia notificacions als clients si algun dels paràmetres supervisats (per exemple, el contingut de CO2) supera el valor permès.
Com emmagatzemem les dades. La història de Kubernetes sobre metall nu
El projecte de vigilància ambiental URUS disposa de diversos magatzems de dades. En un, guardem dades "crues": el que rebem directament dels propis dispositius. Aquest emmagatzematge és una cinta "magnètica", com en les cintes de casset antigues, amb un historial de tots els indicadors. El segon tipus d'emmagatzematge s'utilitza per a dades preprocessades: dades dels dispositius, enriquides amb metadades sobre les connexions entre sensors i les lectures dels propis dispositius, afiliació amb organitzacions, ubicacions, etc. Aquesta informació permet avaluar de manera dinàmica com ha tingut un determinat indicador. canviat durant un període de temps determinat. Utilitzem l'emmagatzematge de dades "crues", entre altres coses, com a còpia de seguretat i per restaurar les dades preprocessades, si és necessari.
Quan estàvem buscant resoldre el nostre problema d'emmagatzematge fa uns quants anys, teníem dues opcions de plataforma: Kubernetes i OpenStack. Però com que aquest últim sembla força monstruós (només cal mirar la seva arquitectura per estar convençuts d'això), ens vam establir per Kubernetes. Un altre argument al seu favor va ser el control de programari relativament senzill, la capacitat de tallar de manera més flexible fins i tot els nodes de maquinari segons els recursos.
Paral·lelament al domini de Kubernetes, també hem estudiat maneres d'emmagatzemar dades, mentre que manteníem tot el nostre emmagatzematge a Kubernetes en el nostre propi maquinari, vam rebre una experiència excel·lent. Tot el que havíem viscut llavors a Kubernetes: emmagatzematge complet, sistema de monitorització, CI/CD. Kubernetes s'ha convertit en una plataforma tot en un per a nosaltres.
Però volíem treballar amb Kubernetes com a servei i no participar en el seu suport i desenvolupament. A més, no ens va agradar quant ens va costar mantenir-lo sobre metall nu, i necessitàvem desenvolupament constantment! Per exemple, una de les primeres tasques va ser integrar els controladors Kubernetes Ingress a la infraestructura de xarxa de la nostra organització. Aquesta és una tasca feixuga, sobretot tenint en compte que en aquell moment no hi havia res preparat per a la gestió de recursos programàtics com els registres DNS o l'assignació d'adreces IP. Més tard vam començar a experimentar amb l'emmagatzematge de dades extern. Mai vam arribar a implementar el controlador de PVC, però fins i tot llavors va quedar clar que es tractava d'una gran àrea de treball que requeria especialistes dedicats.
Canviar a Google Cloud Platform és una solució temporal
Ens vam adonar que això no podia continuar i vam traslladar les nostres dades del bare metal a Google Cloud Platform. De fet, en aquell moment no hi havia moltes opcions interessants per a una empresa russa: a més de Google Cloud Platform, només Amazon oferia un servei semblant, però encara ens vam conformar amb la solució de Google. Aleshores ens va semblar més rendible econòmicament, més proper a Upstream, sense oblidar el fet que el propi Google és una mena de PoC Kubernetes en producció.
El primer gran problema va aparèixer a l'horitzó a mesura que creixia la nostra base de clients. Quan vam tenir la necessitat d'emmagatzemar dades personals, ens vam enfrontar a una opció: o treballem amb Google i infringim les lleis russes, o busquem una alternativa a la Federació Russa. L'elecció, en general, era previsible. 🙂
Com vam veure el servei al núvol ideal
Al començament de la cerca, ja sabíem què volíem obtenir del futur proveïdor de núvol. Quin servei buscàvem:
- Ràpid i flexible. De manera que podem afegir ràpidament un nou node o desplegar alguna cosa en qualsevol moment.
- De baix cost. Estàvem molt preocupats pel tema financer, ja que teníem recursos limitats. Ja sabíem que volíem treballar amb Kubernetes, i ara la tasca era minimitzar-ne el cost per tal d'augmentar o almenys mantenir l'eficiència d'utilitzar aquesta solució.
- Automatitzat. Teníem previst treballar amb el servei a través de l'API, sense gestors i trucades telefòniques o situacions en què calgués elevar manualment diverses desenes de nodes en mode d'emergència. Com que la majoria dels nostres processos estan automatitzats, esperàvem el mateix del servei al núvol.
- Amb servidors a la Federació Russa. Per descomptat, teníem previst complir la legislació russa i el mateix 152-FZ.
En aquell moment, hi havia pocs proveïdors aaS de Kubernetes a Rússia i, a l'hora de triar un proveïdor, era important que no comprometéssim les nostres prioritats. L'equip de Mail.ru Cloud Solutions, amb qui vam començar a treballar i seguim col·laborant, ens va proporcionar un servei totalment automatitzat, amb suport d'API i un còmode panell de control que inclou Horizon: amb ell podríem augmentar ràpidament un nombre arbitrari de nodes.
Com hem aconseguit migrar a MCS en dues hores
En aquests moviments, moltes empreses s'enfronten a dificultats i contratemps, però en el nostre cas no n'hi ha hagut cap. Vam tenir sort: com que ja estàvem treballant en Kubernetes abans de començar la migració, simplement vam corregir tres fitxers i vam llançar els nostres serveis a la nova plataforma al núvol, MCS. Permeteu-me que us recordi que en aquell moment finalment havíem deixat el metall nu i vivíem a Google Cloud Platform. Per tant, el moviment en si no va trigar més de dues hores, a més d'una mica més de temps (aproximadament una hora) es va dedicar a copiar dades dels nostres dispositius. Aleshores ja estàvem utilitzant Spinnaker (un servei de CD multinúvol per oferir lliurament continu). També el vam afegir ràpidament al nou clúster i vam continuar treballant com sempre.
Gràcies a l'automatització dels processos de desenvolupament i CI/CD, Kubernetes a URUS està gestionat per un especialista (i jo sóc). En algun moment, un altre administrador del sistema va treballar amb mi, però després va resultar que ja havíem automatitzat tota la rutina principal i que cada cop hi havia més tasques per part del nostre producte principal i tenia sentit dirigir els recursos a això.
Vam rebre el que esperàvem del proveïdor de núvol, ja que vam començar la cooperació sense il·lusions. Si hi ha hagut incidències, eren majoritàriament tècniques i que fàcilment s'explicaven per la relativa frescor del servei. El més important és que l'equip MCS elimina ràpidament les mancances i respon ràpidament a les preguntes dels missatgers.
Si comparo la meva experiència amb Google Cloud Platform, en el seu cas ni tan sols sabia on era el botó de comentaris, ja que simplement no hi havia necessitat. I si es produïa algun problema, el mateix Google enviava notificacions unilateralment. Però en el cas de MCS, crec que el gran avantatge és que estan el més a prop possible dels clients russos, tant geogràficament com mentalment.
Com veiem treballar amb núvols en el futur
Ara la nostra feina està molt lligada a Kubernetes, i ens convé totalment des del punt de vista de les tasques d'infraestructura. Per tant, no tenim previst migrar-ne enlloc, tot i que contínuament estem introduint noves pràctiques i serveis per simplificar les tasques rutinàries i automatitzar-ne de noves, augmentar l'estabilitat i la fiabilitat dels serveis... Ara estem posant en marxa el servei Chaos Monkey (concretament). , fem servir chaoskube, però això no canvia el concepte: ), que va ser creat originalment per Netflix. Chaos Monkey fa una cosa senzilla: elimina una beina de Kubernetes aleatòria en un moment aleatori. Això és necessari perquè el nostre servei visqui amb normalitat amb el nombre d'instàncies n–1, de manera que ens entrenem per estar preparats per a qualsevol problema.
Ara veig l'ús de solucions de tercers (les mateixes plataformes al núvol) com l'únic correcte per a les empreses joves. Normalment, al començament del seu viatge, tenen recursos limitats, tant humans com financers, i construir i mantenir el seu propi núvol o centre de dades és massa car i requereix mà d'obra. Els proveïdors de núvol us permeten minimitzar aquests costos, podeu obtenir d'ells ràpidament els recursos necessaris per al funcionament dels serveis aquí i ara, i pagar aquests recursos després del fet. Pel que fa a l'empresa URUS, de moment romandrem fidels a Kubernetes al núvol. Però qui sap, potser haurem d'ampliar-nos geogràficament, o implementar solucions basades en algun equipament específic. O potser la quantitat de recursos consumits justificarà el propi Kubernetes en metall nu, com en els bons vells temps. 🙂
El que hem après treballant amb serveis al núvol
Vam començar a utilitzar Kubernetes en metall nu, i fins i tot allà era bo a la seva manera. Però els seus punts forts es van revelar precisament com a component aaS al núvol. Si us fixeu un objectiu i ho automatitzeu tot tant com sigui possible, podreu evitar el bloqueig de proveïdors i moureu-vos entre proveïdors de núvol trigarà un parell d'hores i les cèl·lules nervioses romandran amb nosaltres. Podem aconsellar a altres empreses: si voleu llançar el vostre propi servei (núvol), amb recursos limitats i màxima velocitat de desenvolupament, comenceu ara mateix llogant recursos al núvol i creeu el vostre centre de dades després que Forbes escrigui sobre vosaltres.
Font: www.habr.com