{"id":81130,"date":"2020-05-11T01:42:39","date_gmt":"2020-05-10T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo"},"modified":"2020-05-11T01:42:39","modified_gmt":"2020-05-10T23:42:39","slug":"kubernetes-open-source-protiv-vendorskogo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo","title":{"rendered":"Kubernetes: open source contro vendor lock-in","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, mi chiamo Dmitrij Krasnov. Da oltre cinque anni mi occupo dell'amministrazione di cluster Kubernetes e della costruzione di architetture microservizi complesse. All'inizio di quest'anno abbiamo lanciato un servizio di gestione dei cluster Kubernetes basato su Containerum. Approfittando dell'occasione, vorrei spiegare che cos'\u00e8 Kubernetes e in cosa differisce l'integrazione con il fornitore rispetto all'open source.<\/b><\/p>\n

Per prima cosa, che cos'\u00e8 Kubernetes<\/a><\/noindex>? \u00c8 un sistema per gestire container su un gran numero di host. In greco, tra l'altro, significa 'pilota' o 'helmsman'. Inizialmente sviluppato da Google, \u00e8 stato poi ceduto come contributo tecnologico alla Cloud Native Computing Foundation, un'organizzazione non profit internazionale che riunisce i principali sviluppatori mondiali, utenti finali e fornitori di tecnologie per container. <\/p>\n

\"Kubernetes:
\n<\/a><\/noindex><\/p>\n

Gestire un gran numero di container <\/h3>\n

\nOra esaminiamo che cosa siano effettivamente questi container. Sono app che contengono tutto il loro ambiente \u2013 principalmente, le librerie di cui l'app ha bisogno per funzionare. Tutto questo \u00e8 confezionato in archivi e presentato come un'immagine, che pu\u00f2 essere eseguita indipendentemente dal sistema operativo, testata e non solo. Ma c'\u00e8 un problema: gestire container su un gran numero di host \u00e8 molto difficile. Ecco perch\u00e9 \u00e8 stato creato Kubernetes. <\/p>\n

L'immagine del container rappresenta un'app pi\u00f9 le sue dipendenze. L'app, le sue dipendenze e l'immagine del file system OS sono distribuiti in diverse parti dell'immagine, chiamate layer. I layer possono essere riutilizzati per diversi container. Ad esempio, in tutta l'azienda si pu\u00f2 utilizzare un layer di base di Ubuntu. Quando i container vengono avviati, non c'\u00e8 bisogno di conservare sull'host molte copie dello stesso layer di base. Questo consente di ottimizzare lo storage e la consegna delle immagini.<\/p>\n

Quando vogliamo avviare un'applicazione da un contenitore, i layer necessari si sovrappongono per formare un file system overlay. Sopra si sovrappone un layer di scrittura, che viene eliminato al momento dell'arresto del contenitore. Questo garantisce che all'avvio del contenitore l'applicazione abbia sempre lo stesso ambiente, che non pu\u00f2 essere modificato. Ci\u00f2 garantisce la riproducibilit\u00e0 dell'ambiente su diversi sistemi operativi host. Che sia Ubuntu o CentOS, l'ambiente sar\u00e0 sempre lo stesso. Inoltre, il contenitore \u00e8 isolato dall'host tramite meccanismi incorporati nel kernel di Linux. Le applicazioni nel contenitore non vedono i file, i processi dell'host o dei contenitori vicini. Tale isolamento delle applicazioni rispetto al sistema operativo host fornisce un ulteriore strato di sicurezza. <\/p>\n

Per gestire i contenitori sull'host ci sono molti strumenti. Il pi\u00f9 popolare di essi \u00e8 Docker. Consente di garantire un ciclo di vita completo per il lavoro con i contenitori. Tuttavia, lavora solo su un singolo host. Quando \u00e8 necessario gestire contenitori su pi\u00f9 host, Docker pu\u00f2 trasformare la vita degli ingegneri in un incubo. \u00c8 per questo che \u00e8 stato creato Kubernetes.<\/p>\n

La richiesta di Kubernetes \u00e8 proprio dovuta alla possibilit\u00e0 di gestire gruppi di contenitori su pi\u00f9 host come un'unica entit\u00e0. La popolarit\u00e0 del sistema \u00e8 garantita dalla possibilit\u00e0 di costruire DevOps o Sviluppo Operativo, nei quali Kubernetes viene utilizzato per avviare i processi di questo stesso DevOps.<\/p>\n

\"Kubernetes:
\n
\nFigura 1. Immagine schematica del principio di funzionamento di Kubernetes<\/i><\/p>\n

Automazione completa<\/h3>\n

\nDevOps, in pratica, rappresenta l'automazione del processo di sviluppo. In parole povere, gli sviluppatori scrivono il codice, che viene caricato nel repository. Successivamente, questo codice pu\u00f2 essere automaticamente assemblato immediatamente in un contenitore con tutte le librerie, testato e \"rilasciato\" alla fase successiva - Staging, e poi subito in produzione.<\/p>\n

Insieme a Kubernetes, DevOps permette di automatizzare questo processo in modo che si svolga praticamente senza l'intervento degli sviluppatori stessi. Questo accelera notevolmente la compilazione, poich\u00e9 lo sviluppatore non deve preoccuparsi di farlo sul proprio computer: scrive semplicemente un pezzo di codice, lo carica nel repository e poi viene avviato un pipeline che pu\u00f2 includere il processo di compilazione, testing e distribuzione. E cos\u00ec avviene per ogni commit, quindi il testing \u00e8 continuo.<\/p>\n

Inoltre, l'uso dei container consente di essere certi che tutto l'ambiente di questo programma andr\u00e0 in produzione proprio nella forma in cui \u00e8 stato testato. In altre parole, non ci saranno problemi del tipo \"in test c'erano certe versioni, in produzione - altre, e una volta installato \u2013 tutto \u00e8 andato in crash\u201d. Poich\u00e9 oggi abbiamo una tendenza verso l'architettura a microservizi, dove invece di una grande applicazione ci sono centinaia di piccole, amministrarle manualmente richiederebbe una grande quantit\u00e0 di personale. Ecco perch\u00e9 utilizziamo Kubernetes.<\/p>\n

<\/p>\n

Vantaggi, vantaggi, vantaggi<\/h3>\n

<\/b>
\nParlando dei vantaggi di Kubernetes come piattaforma, ha notevoli benefici in termini di gestione dell'architettura a microservizi. <\/p>\n