L'azienda URUS ha provato Kubernetes in diverse forme: implementazione indipendente su bare metal, in Google Cloud, per poi trasferire la sua piattaforma sul cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin racconta come hanno scelto un nuovo fornitore di servizi cloud e come sono riusciti a migrarvi in un tempo record di due ore (), amministratore di sistema senior presso URUS.
Cosa fa URUS?
Esistono molti modi per migliorare la qualità dell’ambiente urbano e uno di questi è renderlo rispettoso dell’ambiente. Questo è esattamente ciò su cui sta lavorando la società URUS - Smart Digital Services. Qui implementano soluzioni che aiutano le imprese a monitorare importanti indicatori ambientali e a ridurre il loro impatto negativo sull'ambiente. I sensori raccolgono dati sulla composizione dell'aria, sul livello di rumore e altri parametri, quindi li inviano alla piattaforma unificata URUS-Ekomon per l'analisi e la formulazione di raccomandazioni.
Come funziona URUS dall'interno
Un tipico cliente di URUS è un'azienda situata all'interno o nelle vicinanze di una zona residenziale. Potrebbe trattarsi di una fabbrica, di un porto, di un deposito ferroviario o di qualsiasi altra struttura. Se il nostro cliente ha già ricevuto un avvertimento, è stato multato per inquinamento ambientale, oppure vuole fare meno rumore, ridurre la quantità di emissioni nocive, viene da noi e noi gli offriamo già una soluzione già pronta per il monitoraggio ambientale.
Il grafico del monitoraggio della concentrazione di H2S mostra le regolari emissioni notturne provenienti da un impianto vicino
I dispositivi che utilizziamo in URUS contengono diversi sensori che raccolgono informazioni sul contenuto di determinati gas, livelli di rumore e altri dati per valutare la situazione ambientale. Il numero esatto di sensori è sempre determinato dall'attività specifica.
A seconda delle specifiche delle misurazioni, i dispositivi con sensori possono essere posizionati sui muri di edifici, pali e altri luoghi arbitrari. Ciascuno di questi dispositivi raccoglie informazioni, le aggrega e le invia al gateway di ricezione dati. Lì salviamo i dati per l'archiviazione a lungo termine e li pre-elaboriamo per la successiva analisi. L’esempio più semplice di ciò che otteniamo come risultato dell’analisi è l’indice di qualità dell’aria, noto anche come AQI.
Parallelamente, sulla nostra piattaforma operano molti altri servizi, ma sono principalmente di natura di servizio. Ad esempio, il servizio di notifica invia notifiche ai clienti se uno qualsiasi dei parametri monitorati (ad esempio il contenuto di CO2) supera il valore consentito.
Come memorizziamo i dati. La storia di Kubernetes su bare metal
Il progetto di monitoraggio ambientale URUS dispone di diversi data warehouse. In uno conserviamo i dati "grezzi", ovvero ciò che abbiamo ricevuto direttamente dai dispositivi stessi. Questa memoria è un nastro "magnetico", come sulle vecchie cassette, con una cronologia di tutti gli indicatori. Il secondo tipo di archiviazione viene utilizzato per i dati preelaborati: dati provenienti dai dispositivi, arricchiti con metadati sulle connessioni tra sensori e letture dei dispositivi stessi, affiliazione con organizzazioni, luoghi, ecc. Queste informazioni consentono di valutare dinamicamente come ha avuto un particolare indicatore cambiato in un certo periodo di tempo. Utilizziamo l'archiviazione dei dati "grezzi" tra l'altro come backup e per ripristinare i dati preelaborati, se necessario.
Quando cercavamo di risolvere il nostro problema di storage diversi anni fa, avevamo due scelte di piattaforma: Kubernetes e OpenStack. Ma poiché quest'ultimo sembra piuttosto mostruoso (basta guardare la sua architettura per esserne convinti), abbiamo optato per Kubernetes. Un altro argomento a suo favore era il controllo software relativamente semplice, la capacità di tagliare in modo più flessibile anche i nodi hardware in base alle risorse.
Parallelamente alla padronanza di Kubernetes stesso, abbiamo anche studiato modi per archiviare i dati, mentre manteniamo tutto il nostro spazio di archiviazione in Kubernetes sul nostro hardware, abbiamo acquisito un'eccellente competenza. Tutto quello che allora vivevamo su Kubernetes: storage statefull, sistema di monitoraggio, CI/CD. Kubernetes è diventata per noi una piattaforma all-in-one.
Ma volevamo lavorare con Kubernetes come servizio e non impegnarci nel suo supporto e sviluppo. Inoltre, non ci piaceva quanto ci costava mantenerlo sul bare metal, e avevamo bisogno di uno sviluppo costante! Ad esempio, uno dei primi compiti è stato integrare i controller Kubernetes Ingress nell'infrastruttura di rete della nostra organizzazione. Si tratta di un compito ingombrante, soprattutto considerando che a quel tempo non c’era nulla di pronto per la gestione programmatica delle risorse come i record DNS o l’assegnazione degli indirizzi IP. Successivamente abbiamo iniziato a sperimentare l'archiviazione esterna dei dati. Non siamo mai riusciti a implementare il controller PVC, ma anche allora è diventato chiaro che si trattava di un vasto ambito di lavoro che richiedeva specialisti dedicati.
Il passaggio a Google Cloud Platform è una soluzione temporanea
Ci siamo resi conto che ciò non poteva continuare e abbiamo spostato i nostri dati dal bare metal a Google Cloud Platform. In effetti, a quel tempo non c'erano molte opzioni interessanti per un'azienda russa: oltre a Google Cloud Platform, solo Amazon offriva un servizio simile, ma noi abbiamo comunque optato per la soluzione di Google. Poi ci è sembrato economicamente più vantaggioso, più vicino a Upstream, senza contare il fatto che Google stessa è una sorta di PoC Kubernetes in Production.
Il primo grosso problema è apparso all'orizzonte man mano che la nostra base clienti cresceva. Quando abbiamo avuto bisogno di archiviare dati personali, ci siamo trovati di fronte a una scelta: o lavoriamo con Google e violiamo le leggi russe, oppure stiamo cercando un'alternativa nella Federazione Russa. La scelta, tutto sommato, era prevedibile. 🙂
Come abbiamo visto il servizio cloud ideale
Già all’inizio della ricerca sapevamo cosa volevamo ottenere dal futuro fornitore di servizi cloud. Che servizio stavamo cercando:
- Veloce e flessibile. In modo tale da poter aggiungere rapidamente un nuovo nodo o distribuire qualcosa in qualsiasi momento.
- Poco costoso. Eravamo molto preoccupati per la questione finanziaria, poiché le nostre risorse erano limitate. Sapevamo già che volevamo lavorare con Kubernetes e ora il compito era ridurne al minimo i costi per aumentare o almeno mantenere l'efficienza dell'utilizzo di questa soluzione.
- automatizzato. Abbiamo pianificato di lavorare con il servizio tramite API, senza gestori e telefonate o situazioni in cui dobbiamo sollevare manualmente diverse dozzine di nodi in modalità di emergenza. Poiché la maggior parte dei nostri processi sono automatizzati, ci aspettavamo lo stesso dal servizio cloud.
- Con server nella Federazione Russa. Naturalmente, abbiamo pianificato di rispettare la legislazione russa e lo stesso 152-FZ.
A quel tempo in Russia c’erano pochi fornitori di Kubernetes aaS e nella scelta di un fornitore era importante per noi non compromettere le nostre priorità. Il team Mail.ru Cloud Solutions, con il quale abbiamo iniziato a lavorare e stiamo ancora collaborando, ci ha fornito un servizio completamente automatizzato, con supporto API e un comodo pannello di controllo che include Horizon: con esso potremmo rapidamente aumentare un numero arbitrario di nodi.
Come siamo riusciti a migrare a MCS in due ore
In tali iniziative molte aziende si trovano ad affrontare difficoltà e battute d’arresto, ma nel nostro caso non ce ne sono state. Siamo stati fortunati: poiché lavoravamo su Kubernetes già prima dell'inizio della migrazione, abbiamo semplicemente corretto tre file e lanciato i nostri servizi sulla nuova piattaforma cloud MCS. Lascia che ti ricordi che a quel punto avevamo finalmente abbandonato il bare metal e vivevamo sulla Google Cloud Platform. Pertanto, lo spostamento in sé non ha richiesto più di due ore, più un po' più di tempo (circa un'ora) è stato dedicato alla copia dei dati dai nostri dispositivi. Allora utilizzavamo già Spinnaker (un servizio CD multi-cloud per fornire la consegna continua). Lo abbiamo anche aggiunto rapidamente al nuovo cluster e abbiamo continuato a lavorare come al solito.
Grazie all'automazione dei processi di sviluppo e CI/CD, Kubernetes in URUS è gestito da uno specialista (e quello sono io). Ad un certo punto, un altro amministratore di sistema ha lavorato con me, ma poi si è scoperto che avevamo già automatizzato tutta la routine principale e c'erano sempre più compiti da parte del nostro prodotto principale ed era logico indirizzare le risorse a questo.
Abbiamo ricevuto ciò che ci aspettavamo dal fornitore di servizi cloud, poiché abbiamo iniziato una collaborazione senza illusioni. Se si sono verificati incidenti, si trattava per lo più di carattere tecnico e facilmente spiegabili con la relativa freschezza del servizio. La cosa principale è che il team MCS elimina rapidamente le carenze e risponde rapidamente alle domande nei messenger.
Se confronto la mia esperienza con Google Cloud Platform, nel loro caso non sapevo nemmeno dove fosse il pulsante di feedback, semplicemente non ce n’era bisogno. E se si verificavano problemi, Google stessa inviava notifiche unilateralmente. Ma nel caso di MCS, penso che il grande vantaggio sia che sono il più vicino possibile ai clienti russi, sia geograficamente che mentalmente.
Come vediamo il lavoro con i cloud in futuro
Ora il nostro lavoro è strettamente legato a Kubernetes e ci si adatta perfettamente dal punto di vista dei compiti infrastrutturali. Pertanto, non prevediamo di migrare da nessuna parte, anche se introduciamo costantemente nuove pratiche e servizi per semplificare le attività di routine e automatizzarne di nuove, aumentare la stabilità e l'affidabilità dei servizi... Stiamo ora lanciando il servizio Chaos Monkey (nello specifico , usiamo caoskube, ma questo non cambia il concetto: ), originariamente creato da Netflix. Chaos Monkey fa una cosa semplice: elimina un pod Kubernetes casuale in un momento casuale. Ciò è necessario affinché il nostro servizio possa convivere normalmente con il numero di istanze n–1, quindi ci alleniamo per essere preparati a qualsiasi problema.
Ora vedo l'utilizzo di soluzioni di terze parti - le stesse piattaforme cloud - come l'unica cosa giusta per le giovani aziende. Di solito, all’inizio del loro viaggio, hanno risorse limitate, sia umane che finanziarie, e costruire e mantenere il proprio cloud o data center è troppo costoso e richiede molta manodopera. I fornitori di servizi cloud ti consentono di ridurre al minimo questi costi; puoi ottenere rapidamente da loro le risorse necessarie per il funzionamento dei servizi qui e ora e pagare queste risorse a posteriori. Per quanto riguarda l'azienda URUS, per ora rimarremo fedeli a Kubernetes nel cloud. Ma chissà, forse dovremo espanderci geograficamente o implementare soluzioni basate su attrezzature specifiche. O forse la quantità di risorse consumate giustificherà il proprio Kubernetes su bare metal, come ai vecchi tempi. 🙂
Cosa abbiamo imparato lavorando con i servizi cloud
Abbiamo iniziato a utilizzare Kubernetes su bare metal, e anche lì è andato bene a modo suo. Ma i suoi punti di forza si sono rivelati proprio come componente aaS nel cloud. Se stabilisci un obiettivo e automatizzi tutto il più possibile, sarai in grado di evitare il vincolo del fornitore e il passaggio da un provider cloud all'altro richiederà un paio d'ore e le cellule nervose rimarranno con noi. Possiamo consigliare altre aziende: se vuoi lanciare il tuo servizio (cloud), con risorse limitate e massima velocità di sviluppo, inizia subito noleggiando risorse cloud e costruisci il tuo data center dopo che Forbes avrà scritto di te.
Fonte: habr.com