L'azienda «УРУС» ha testato Kubernetes in diverse modalità: implementazione autonoma su bare metal, in Google Cloud, e poi ha trasferito la propria piattaforma nel cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin,, amministratore di sistema senior di «УРУС», racconta come hanno scelto il nuovo fornitore di cloud e come sono riusciti a migrare in un record di due ore.
Cosa fa «УРУС»
Ci sono molti modi per migliorare la qualità dell'ambiente urbano, e uno di questi è renderlo ecologicamente sicuro. Proprio a questo sta lavorando l'azienda «УРУС — Servizi digitali intelligenti». Qui vengono implementate soluzioni che aiutano le imprese a controllare importanti indicatori ecologici e ridurre l'impatto negativo sull'ambiente. I sensori raccolgono dati sulla composizione dell'aria, il livello di rumore e altri parametri, che vengono poi inviati a un'unica piattaforma «УРУС — Ecomon» per l'analisi e la formulazione di raccomandazioni.
Come funziona «УРУС» dall'interno
Il cliente tipico di «УРУС» è un'azienda situata in una zona residenziale o nei suoi pressi. Può trattarsi di una fabbrica, un porto, un deposito ferroviario o qualsiasi altro tipo di struttura. Se il nostro cliente ha già ricevuto avvisi, è stato multato per inquinamento ambientale, o desidera ridurre il rumore e le emissioni nocive, si rivolge a noi, e noi gli proponiamo una soluzione pronta per il monitoraggio ambientale.
Nel grafico di monitoraggio delle concentrazioni di H2S si notano regolari emissioni notturne dell'impianto situato nelle vicinanze.
I dispositivi che utilizziamo in «УРУС» contengono diversi sensori che raccolgono informazioni sulla concentrazione di determinati gas, sul livello di rumore e su altri dati utili per la valutazione della situazione ambientale. Il numero esatto di sensori è sempre determinato in base all'obiettivo specifico.
A seconda delle specifiche delle misurazioni, i dispositivi con sensori possono essere collocati sulle pareti degli edifici, su pali e in altri luoghi a scelta. Ogni dispositivo raccoglie informazioni, le aggrega e le invia a un gateway di ricezione dati. Qui conserviamo i dati per un lungo periodo e li preelaboriamo per successive analisi. Un semplice esempio di ciò che 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 in gran parte svolgono un ruolo di supporto. Ad esempio, il servizio di notifica invia ai clienti avvisi se uno dei parametri monitorati (ad esempio, il livello di CO2) supera il valore consentito.
Come conserviamo i dati. Storia con Kubernetes su bare metal
Nel progetto di monitoraggio ambientale "URUS" ci sono diversi archivi di dati. In uno di essi conserviamo i dati "grezzi" — cioè quelli ricevuti direttamente dai dispositivi. Questo archivio funziona come un nastro magnetico, simile a quelli delle vecchie cassette, e registra la storia di tutti i rilevamenti. Il secondo tipo di archivio è utilizzato per i dati preelaborati — dati dei dispositivi arricchiti con metadati riguardanti le relazioni tra i sensori e le letture dei dispositivi, appartenenza a organizzazioni, posizioni geografiche, ecc. Queste informazioni consentono di valutare dinamicamente come è cambiato un determinato indicatore nel corso di un certo periodo di tempo. Utilizziamo anche l'archivio dei dati "grezzi" come backup e per ripristinare i dati preelaborati, qualora si presentasse la necessità.
Quando qualche anno fa cercavamo soluzioni per il problema dello storage, avevamo due opzioni per la scelta della piattaforma: Kubernetes e OpenStack. Tuttavia, quest'ultimo sembrava piuttosto complesso (basta guardare la sua architettura per rendersene conto), quindi abbiamo optato per Kubernetes. Un altro motivo a favore di Kubernetes è stata la sua gestione programmabile relativamente semplice, che ci ha permesso di gestire in modo più flessibile anche le risorse delle unità hardware.
Parallelamente all'apprendimento di Kubernetes, esploravamo anche le modalità di archiviazione dei dati. Mentre tutte le nostre soluzioni di storage erano mantenute in Kubernetes sul nostro hardware, abbiamo acquisito ottima esperienza. Tutto ciò che avevamo allora viveva su Kubernetes: storage stateful, sistema di monitoraggio, CI/CD. Kubernetes è diventata per noi una piattaforma all-in-one.
Tuttavia, volevamo lavorare con Kubernetes come servizio, invece di dedicarci al suo supporto e sviluppo. Inoltre, non ci piaceva quanto ci costava mantenerlo su bare metal, e avevamo bisogno di un continuo sviluppo! Ad esempio, uno dei primi compiti è stato integrare gli ingress controller di Kubernetes nell'infrastruttura di rete della nostra organizzazione. Si tratta di un compito complesso, soprattutto considerando che all'epoca non c'era nulla pronto per la gestione programmatica delle risorse come i record DNS o l'allocazione. IP addresses. Successivamente, abbiamo iniziato a sperimentare con uno storage esterno. Non siamo mai arrivati a implementare il controller PVC, ma già allora era chiaro che si trattava di un grande lavoro, per il quale era necessario dedicare specialisti specifici.
La transizione alla Google Cloud Platform è una soluzione temporanea.
Abbiamo capito che non potevamo continuare così e abbiamo migrato i nostri dati da bare metal a Google Cloud Platform. In effetti, all'epoca non c'erano molte opzioni interessanti per le aziende russe: oltre a Google Cloud Platform, solo Amazon offriva un servizio simile, ma abbiamo comunque scelto la soluzione di Google. Sembrava economicamente più vantaggiosa, più vicina a Upstream, per non parlare del fatto che Google di per sé è una sorta di PoC Kubernetes in produzione.
Il primo serio problema si è presentato all'orizzonte mentre cresceva la nostra base clienti. Quando abbiamo dovuto memorizzare dati personali, ci siamo trovati di fronte a una scelta: lavorare con Google e violare le leggi russe, o cercare un'alternativa in Russia. La scelta, in generale, era prevedibile. 🙂
Come immaginavamo il servizio cloud ideale
All'inizio della ricerca sapevamo già cosa volevamo dal futuro fornitore di servizi cloud. Quale servizio cercavamo:
- Veloce e flessibile. Così che potessimo aggiungere rapidamente un nuovo nodo o dispiegare qualcosa in qualsiasi momento.
- Economico. Eravamo molto preoccupati per la questione finanziaria, poiché avevamo risorse limitate. Sapevamo già che volevamo lavorare con Kubernetes e ora dovevamo trovare un modo per ridurre i costi e aumentare, o comunque mantenere, l'efficienza dell'uso di questa soluzione.
- Automatizzato. Pianificavamo di utilizzare il servizio tramite API, senza gestori, telefonate o situazioni in cui era necessario avviare manualmente diverse decine di nodi d'emergenza. Poiché la maggior parte dei processi è automatizzata, ci aspettavamo lo stesso da un servizio cloud.
- Con server in RF. Naturalmente, intendevamo rispettare la legislazione russa e la legge 152-FZ.
All'epoca, i fornitori di Kubernetes con il modello aaS in Russia erano pochi e quando sceglievamo un 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 tuttora, ci ha fornito un servizio completamente automatizzato, con supporto API e un'interfaccia di gestione facile da usare, che include Horizon — con esso potevamo avviare rapidamente un numero qualsiasi di nodi.
Come siamo riusciti a migrare in MCS in due ore
In traslochi di questo tipo, molte aziende affrontano difficoltà e insuccessi, ma nel nostro caso non ce ne sono stati. Siamo stati fortunati: poiché prima della migrazione stavamo già lavorando su Kubernetes, ci è bastato modificare tre file e avviare i nostri servizi sulla nuova piattaforma cloud, in MCS. Ricordo che a quel punto eravamo definitivamente passati dal bare metal a Google Cloud Platform. Pertanto, 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. Allora stavamo già utilizzando Spinnaker (un servizio CD multi-cloud per garantire il Continuous Delivery). Anche questo l'abbiamo aggiunto rapidamente nel nuovo cluster e abbiamo continuato a lavorare normalmente.
Grazie all'automazione dei processi di sviluppo e CI/CD, in "URUS" si occupa di Kubernetes un solo specialista (e sono io). A un certo punto collaborava con me un altro amministratore di sistema, ma poi si è rivelato che avevamo già automatizzato gran parte della routine e, a causa del crescente numero di compiti del nostro prodotto principale, ha senso reindirizzare le risorse su questo.
Abbiamo ricevuto dal provider cloud esattamente ciò che ci aspettavamo, iniziando la collaborazione senza illusioni. Se ci sono stati alcuni incidenti, erano per lo più tecnici e facilmente spiegabili dalla relativa giovinezza del servizio. La cosa principale è che il team di MCS corregge rapidamente le inefficienze e risponde in modo tempestivo alle domande sui messaggeri.
Confrontando l'esperienza di lavoro con Google Cloud Platform, posso dire che in quel caso non sapevo neanche dove si trovasse il pulsante di feedback, poiché non ce n'era affatto bisogno. E se si verificavano dei problemi, Google inviava notifiche unilaterali. Ma nel caso di MCS, considero un grande vantaggio il fatto che siano estremamente vicini ai clienti russi, sia territorialmente che mentalmente.
Come vediamo il lavoro con i cloud in futuro
Attualmente, il nostro lavoro è strettamente legato a Kubernetes, e siamo completamente soddisfatti in termini di gestione delle infrastrutture. Pertanto, non pianifichiamo di migrare verso altre soluzioni, anche se stiamo continuamente introducendo nuove pratiche e servizi per semplificare le operazioni quotidiane e automatizzare nuovi processi, al fine di aumentare la stabilità e l'affidabilità dei servizi... Stiamo ora lanciando il servizio Chaos Monkey (in particolare stiamo utilizzando chaoskube, ma il concetto rimane invariato :), originariamente creato da Netflix. Chaos Monkey fa una cosa molto semplice: elimina un pod casuale in Kubernetes a intervalli casuali. Questo è necessario affinché il nostro servizio funzioni correttamente con un numero di istanze n-1, in modo da abituarci a essere pronti a qualsiasi malfunzionamento.
Attualmente vedo l'uso di soluzioni di terze parti, come le piattaforme cloud, come l'unica scelta sensata per le giovani aziende. All'inizio del loro percorso, di solito, hanno risorse limitate, sia in termini di personale che di finanziamenti, e costruire e mantenere un proprio cloud o data center è troppo costoso e impegnativo. I fornitori di cloud consentono di minimizzare questi costi, fornendo rapidamente le risorse necessarie per far funzionare i servizi immediatamente, e permettendo di pagare per queste risorse solo quando utilizzate. Per quanto riguarda l'azienda «УРУС», rimarremo fedeli a Kubernetes nel cloud. Ma chi può saperlo, forse dovremo espanderci geograficamente o implementare soluzioni basate su qualche hardware specifico. Oppure, 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 lì si è rivelato valido. Ma i suoi punti di forza si sono veramente manifestati come componente aaS nel cloud. Se si pone un obiettivo e si automatizza il tutto al massimo, si può evitare il vendor lock-in e il trasferimento tra i fornitori cloud richiederà solo alcune ore, senza perdere le nostre cellule nervose. Possiamo consigliare alle altre aziende: se volete avviare il vostro servizio (cloud) con risorse limitate e la massima velocità di sviluppo, iniziate subito affittando risorse cloud e costruire il vostro data center dopo che Forbes ha scritto di voi.
Fonte: habr.com
