{"id":38075,"date":"2019-10-31T22:21:32","date_gmt":"2019-10-31T19:21:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa\/"},"modified":"2019-10-31T22:21:32","modified_gmt":"2019-10-31T19:21:32","slug":"kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","title":{"rendered":"Come migrare nel cloud in due ore grazie a Kubernetes e all'automazione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nL'azienda \u00ab\u0423\u0420\u0423\u0421\u00bb ha testato Kubernetes in diverse modalit\u00e0: implementazione autonoma su bare metal, in Google Cloud, e poi ha trasferito la propria piattaforma nel cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin,t3ran<\/a><\/noindex>, amministratore di sistema senior di \u00ab\u0423\u0420\u0423\u0421\u00bb, racconta come hanno scelto il nuovo fornitore di cloud e come sono riusciti a migrare in un record di due ore.
\n<\/a><\/noindex><\/p>\n

Cosa fa \u00ab\u0423\u0420\u0423\u0421\u00bb <\/h2>\n

\nCi sono molti modi per migliorare la qualit\u00e0 dell'ambiente urbano, e uno di questi \u00e8 renderlo ecologicamente sicuro. Proprio a questo sta lavorando l'azienda \u00ab\u0423\u0420\u0423\u0421 \u2014 Servizi digitali intelligenti\u00bb. 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 \u00ab\u0423\u0420\u0423\u0421 \u2014 Ecomon\u00bb per l'analisi e la formulazione di raccomandazioni. <\/p>\n

Come funziona \u00ab\u0423\u0420\u0423\u0421\u00bb dall'interno<\/h2>\n

\nIl cliente tipico di \u00ab\u0423\u0420\u0423\u0421\u00bb \u00e8 un'azienda situata in una zona residenziale o nei suoi pressi. Pu\u00f2 trattarsi di una fabbrica, un porto, un deposito ferroviario o qualsiasi altro tipo di struttura. Se il nostro cliente ha gi\u00e0 ricevuto avvisi, \u00e8 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.<\/p>\n

\"Come
\nNel grafico di monitoraggio delle concentrazioni di H2S si notano regolari emissioni notturne dell'impianto situato nelle vicinanze.<\/i><\/p>\n

I dispositivi che utilizziamo in \u00ab\u0423\u0420\u0423\u0421\u00bb 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 \u00e8 sempre determinato in base all'obiettivo specifico.<\/p>\n

\"Come
\nA 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\u00f2 che otteniamo in uscita dopo l'analisi \u00e8 l'indice di qualit\u00e0 dell'aria, noto anche come AQI.<\/p>\n

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.<\/p>\n

Come conserviamo i dati. Storia con Kubernetes su bare metal<\/h2>\n

\nNel progetto di monitoraggio ambientale \"URUS\" ci sono diversi archivi di dati. In uno di essi conserviamo i dati \"grezzi\" \u2014 cio\u00e8 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 \u00e8 utilizzato per i dati preelaborati \u2014 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 \u00e8 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\u00e0.<\/p>\n

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 \u00e8 stata la sua gestione programmabile relativamente semplice, che ci ha permesso di gestire in modo pi\u00f9 flessibile anche le risorse delle unit\u00e0 hardware. <\/p>\n

Parallelamente all'apprendimento di Kubernetes, esploravamo anche le modalit\u00e0 di archiviazione dei dati. Mentre tutte le nostre soluzioni di storage erano mantenute in Kubernetes sul nostro hardware, abbiamo acquisito ottima esperienza. Tutto ci\u00f2 che avevamo allora viveva su Kubernetes: storage stateful, sistema di monitoraggio, CI\/CD. Kubernetes \u00e8 diventata per noi una piattaforma all-in-one. <\/p>\n

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 \u00e8 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<\/a>. Successivamente, abbiamo iniziato a sperimentare con uno storage esterno. Non siamo mai arrivati a implementare il controller PVC, ma gi\u00e0 allora era chiaro che si trattava di un grande lavoro, per il quale era necessario dedicare specialisti specifici.<\/p>\n

La transizione alla Google Cloud Platform \u00e8 una soluzione temporanea.<\/h2>\n

\nAbbiamo capito che non potevamo continuare cos\u00ec 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\u00f9 vantaggiosa, pi\u00f9 vicina a Upstream, per non parlare del fatto che Google di per s\u00e9 \u00e8 una sorta di PoC Kubernetes in produzione.<\/p>\n

Il primo serio problema si \u00e8 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. \ud83d\ude42<\/p>\n

Come immaginavamo il servizio cloud ideale<\/h2>\n

\nAll'inizio della ricerca sapevamo gi\u00e0 cosa volevamo dal futuro fornitore di servizi cloud. Quale servizio cercavamo:<\/p>\n