L'azienda «УРУС» ha provato Kubernetes in diverse modalità: deploy autonomo su bare metal, in Google Cloud, per poi trasferire la propria piattaforma nel cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin racconta come hanno scelto un nuovo provider cloud e come sono riusciti a migrare in un record di due ore.), senior system administrator di «УРУС».
Cosa fa «УРУС»
Ci sono molti modi per migliorare la qualità dell'ambiente urbano, e uno di questi è renderlo ecologicamente sicuro. È proprio su questo che lavora l'azienda «УРУС — Servizi Digitali Intelligenti». Qui vengono implementate soluzioni che aiutano le imprese a monitorare indicatori ecologici importanti e ridurre l'impatto negativo sull'ambiente. I sensori raccolgono dati sulla composizione dell'aria, sul livello di rumore e altri parametri, per poi inviarli alla piattaforma unica «УРУС — Ecomon» per analisi e raccomandazioni.
Come funziona «УРУС» dall'interno
Il cliente tipico di «УРУС» è un'azienda situata in una zona residenziale o nelle vicinanze. Può trattarsi di una fabbrica, un porto, un deposito ferroviario o qualsiasi altra struttura. Se il nostro cliente ha già ricevuto un avviso, è stato multato per inquinamento ambientale o desidera ridurre il rumore e le emissioni nocive, si rivolge a noi e noi offriamo una soluzione pronta per il monitoraggio ambientale.
Nel grafico di monitoraggio della concentrazione di H2S si vedono emissioni notturne regolari dell'impianto vicino.
I dispositivi che utilizziamo in «УРУС» contengono diversi sensori che raccolgono informazioni sulla concentrazione di determinati gas, sul livello di rumore e altri dati per valutare la situazione ambientale. Il numero esatto di sensori è sempre determinato dal compito specifico.
A seconda della natura delle misurazioni, i dispositivi con sensori possono essere collocati sulle pareti degli edifici, sui pali e in altri luoghi casuali. Ogni dispositivo raccoglie informazioni, le aggrega e le invia a un gateway di ricezione dati. Qui conserviamo i dati per lungo tempo e li pretrattiamo per ulteriori analisi. Un esempio semplice di cosa otteniamo in uscita dopo l'analisi è l'indice di qualità dell'aria, noto anche come AQI.
Parallelamente, sulla nostra piattaforma operano molti altri servizi, ma questi di solito hanno un carattere di supporto. Ad esempio, il servizio di notifica invia avvisi ai clienti se uno dei parametri monitorati (ad esempio, il contenuto di CO2) supera i valori consentiti.
Come conserviamo i dati. Una storia con Kubernetes su bare metal.
Nel progetto di monitoraggio ecologico "URUS" ci sono diversi archivi di dati. In uno conserviamo i dati "grezzi" - cioè quelli che abbiamo ricevuto direttamente dai dispositivi stessi. Questo archivio funge da "nastro" magnetico, come nelle vecchie cassette, con la cronologia di tutte le misurazioni. Il secondo tipo di archivio è utilizzato per i dati pre-elaborati - dati provenienti dai dispositivi, arricchiti da metadati relativi alle connessioni dei sensori e alle letture dei dispositivi, nonché all'appartenenza a organizzazioni, luoghi di ubicazione, ecc. Queste informazioni consentono di valutare nel tempo come è cambiato un determinato parametro in un intervallo di tempo definito. Utilizziamo l'archivio di dati "grezzi" anche come backup e per ripristinare i dati pre-elaborati, se necessario.
Quando alcuni anni fa stavamo cercando di risolvere il problema dello storage, avevamo due opzioni per la scelta della piattaforma: Kubernetes e OpenStack. Ma dato che quest'ultimo appare piuttosto mostruoso (basta guardare la sua architettura per convincersene), abbiamo optato per Kubernetes. Un altro argomento a favore di Kubernetes è stato il suo relativamente semplice controllo software, che consente una gestione più flessibile anche delle nodi hardware.
Parallelamente all'acquisizione di competenze su Kubernetes, esploravamo anche i modi di archiviare dati. Mentre tenevamo tutti i nostri archivi in Kubernetes sul nostro hardware, abbiamo acquisito una grande esperienza. Tutto ciò che avevamo all'epoca viveva proprio su Kubernetes: archiviazione stateful, sistema di monitoraggio, CI/CD. Kubernetes è diventato per noi una piattaforma all-in-one.
Ma volevamo lavorare con Kubernetes come un servizio, piuttosto che occuparci del suo supporto e sviluppo. Inoltre, non ci piaceva il costo di mantenerlo su bare metal, e lo sviluppo era necessario continuamente! Ad esempio, uno dei primi compiti è stato integrare i controller Ingress di Kubernetes nell'infrastruttura di rete della nostra organizzazione. Questo è un compito complesso, soprattutto considerando che al momento non c'era nulla di pronto per la gestione programmata delle risorse come i record DNS o l'allocazione. indirizzi IP. In seguito abbiamo iniziato a sperimentare con lo storage esterno. Non siamo mai riusciti a implementare il controller PVC, ma è già chiaro che si tratta di un grande carico di lavoro che richiede specialisti dedicati.
La migrazione a Google Cloud Platform è stata una soluzione temporanea.
Ci siamo resi conto che non potevamo continuare in questo modo e abbiamo trasferito i nostri dati da bare metal a Google Cloud Platform. In realtà, all'epoca per una compagnia russa non c'erano molte opzioni interessanti: oltre a Google Cloud Platform, solo Amazon offriva un servizio simile, ma alla fine abbiamo scelto la soluzione di Google. Ci è sembrata economicamente più vantaggiosa, più vicina all'Upstream, per non parlare del fatto che Google è esso stesso un tipo di PoC Kubernetes in produzione.
Il primo serio problema è emerso parallelamente alla crescita della nostra base clienti. Quando abbiamo avuto bisogno di conservare dati personali, ci siamo trovati di fronte a una scelta: lavorare con Google e violare le leggi russe, oppure cercare un'alternativa in Russia. La scelta, in fin dei conti, era prevedibile. 🙂
Come immaginavamo il servizio cloud ideale.
All'inizio delle ricerche, sapevamo già cosa volevamo dal futuro provider cloud. Quale servizio stavamo cercando:
- Veloce e flessibile.. Uno che ci permettesse di aggiungere rapidamente un nuovo nodo o di distribuire qualcosa in qualsiasi momento.
- Economico.. La questione finanziaria ci preoccupava molto, poiché eravamo limitati nelle risorse. Sapevamo già che volevamo lavorare con Kubernetes e ora l'obiettivo era minimizzare i suoi costi per aumentare, o quanto meno mantenere, l'efficacia di utilizzo di questa soluzione.
- Automatizzato.. Avevamo pianificato di lavorare con il servizio tramite API, senza manager e telefonate o situazioni in cui era necessario attivare manualmente diverse decine di nodi in modalità emergenza. Poiché gran parte dei nostri processi è automatizzata, ci aspettavamo lo stesso dal servizio cloud.
- Con server in RF. Naturalmente, avevamo pianificato di rispettare la legislazione russa e il 152-FZ.
All'epoca, i fornitori di Kubernetes in Russia con il modello aaS erano pochi, e nella scelta del fornitore, era importante per noi non compromettere le nostre priorità. Il team di Mail.ru Cloud Solutions, con cui abbiamo iniziato a lavorare e collaboriamo ancora, ci ha fornito un servizio completamente automatizzato, con supporto API e un'interfaccia utente comoda, in cui c'è Horizon — con esso potevamo attivare rapidamente un numero arbitrario di nodi.
Come siamo riusciti a migrare a MCS in due ore
In tali trasferimenti molte aziende affrontano difficoltà e fallimenti, ma nel nostro caso non ci sono stati. Siamo stati fortunati: poiché prima della migrazione stavamo già lavorando su Kubernetes, abbiamo semplicemente modificato tre file e avviato i nostri servizi sulla nuova piattaforma cloud, in MCS. Ricordo che a quel tempo eravamo completamente passati da bare metal a Google Cloud Platform. Quindi il trasferimento stesso ha richiesto non più di due ore, più un po' di tempo (circa un'ora) per copiare i dati dai nostri dispositivi. A quel punto stavamo già utilizzando Spinnaker (un servizio multi-cloud di CD per garantire la Continuous Delivery). Anche questo l'abbiamo rapidamente aggiunto al nuovo cluster e abbiamo continuato a lavorare in modalità normale.
Grazie all'automazione dei processi di sviluppo e CI/CD, in 'URUS' si occupa di Kubernetes un solo specialista (ed è il sottoscritto). A un certo punto, un altro amministratore di sistema ha lavorato con me, ma poi si è scoperto che tutta la routine principale era già automatizzata e che per il nostro prodotto principale le attività aumentavano, rendendo sensato concentrare le risorse su questo.
Abbiamo ricevuto dal fornitore di servizi cloud ciò che ci aspettavamo, poiché abbiamo iniziato la collaborazione senza illusioni. Se ci sono stati incidenti, erano per lo più tecnici e facilmente spiegabili con la relativa novità del servizio. La cosa principale è che il team di MCS risolve rapidamente i problemi e risponde tempestivamente alle domande nei messaggeri.
Se paragoniamo l'esperienza con Google Cloud Platform, nel loro caso non ho nemmeno saputo dove si trovasse il pulsante di contatto, poiché non c'era semplicemente bisogno. E se ci fossero stati problemi, Google inviava notifiche in modo unilaterale. Ma nel caso di MCS, considero un grande vantaggio il fatto che siano molto vicini ai clienti russi, sia territorialmente che mentalmente.
Come vediamo il lavoro con il cloud in futuro
Attualmente il nostro lavoro è strettamente legato a Kubernetes, e ci soddisfa completamente in termini di questioni infrastrutturali. Pertanto, non abbiamo intenzione di migrare altrove, anche se introduciamo continuamente nuove pratiche e servizi per semplificare le attività quotidiane e automatizzare le nuove, aumentando la stabilità e l'affidabilità dei servizi... Attualmente stiamo lanciando il servizio Chaos Monkey (specificamente utilizziamo chaoskube, ma il concetto non cambia :), originariamente creato in Netflix. Chaos Monkey esegue una semplice operazione: a un orario casuale elimina un pod casuale in Kubernetes. Questo è necessario per garantire che il nostro servizio funzioni normalmente con un numero di istanze n–1, così ci abituiamo a essere pronti a qualsiasi malfunzionamento.
Ora vedo l'uso di soluzioni esterne — delle stesse piattaforme cloud — come l'unica scelta giusta per le giovani aziende. Di solito, all'inizio del percorso, sono limitate in risorse, sia umane che finanziarie, e costruire e mantenere un proprio cloud o data center è troppo costoso e laborioso. I fornitori di cloud permettono di ridurre al minimo questi costi, fornendo rapidamente le risorse necessarie per far funzionare i servizi qui e ora, e pagando queste risorse in base all'uso. Per quanto riguarda l'azienda «УРУС», per ora rimarremo fedeli a Kubernetes nel cloud. Ma chi lo sa, forse dovremo espanderci geograficamente, o implementare soluzioni basate su qualche attrezzatura specifica. O, magari, la quantità di risorse utilizzate giustificherà un proprio Kubernetes su bare-metal, come ai vecchi tempi. 🙂
Cosa abbiamo appreso dall'esperienza con i servizi cloud
Abbiamo iniziato a utilizzare Kubernetes su bare metal, e anche in quel contesto si è rivelato efficace. Tuttavia, le sue migliori potenzialità sono emerse come componente aaS nel cloud. Se si pone un obiettivo e si automatizza il più possibile, si può evitare il vendor lock-in e il trasferimento tra fornitori cloud richiederà solo poche ore, risparmiando le nostre cellule nervose. Possiamo consigliare ad altre aziende: se desiderate avviare il vostro servizio (cloud) con risorse limitate e la massima velocità nello sviluppo, iniziate subito affittando risorse cloud, mentre costruire il vostro data center potete farlo dopo che Forbes avrà scritto di voi.
Fonte: habr.com
