🥇Kubernetes: open source contro vendor

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'è Kubernetes e in cosa differisce l'integrazione con il fornitore rispetto all'open source.

Per prima cosa, che cos'è Kubernetes? È un sistema per gestire container su un gran numero di host. In greco, tra l'altro, significa 'pilota' o 'helmsman'. Inizialmente sviluppato da Google, è 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.

Gestire un gran numero di container

Ora esaminiamo che cosa siano effettivamente questi container. Sono app che contengono tutto il loro ambiente – principalmente, le librerie di cui l'app ha bisogno per funzionare. Tutto questo è confezionato in archivi e presentato come un'immagine, che può essere eseguita indipendentemente dal sistema operativo, testata e non solo. Ma c'è un problema: gestire container su un gran numero di host è molto difficile. Ecco perché è stato creato Kubernetes.

L'immagine del container rappresenta un'app più 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ò utilizzare un layer di base di Ubuntu. Quando i container vengono avviati, non c'è bisogno di conservare sull'host molte copie dello stesso layer di base. Questo consente di ottimizzare lo storage e la consegna delle immagini.

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ò essere modificato. Ciò garantisce la riproducibilità dell'ambiente su diversi sistemi operativi host. Che sia Ubuntu o CentOS, l'ambiente sarà sempre lo stesso. Inoltre, il contenitore è 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.

Per gestire i contenitori sull'host ci sono molti strumenti. Il più popolare di essi è Docker. Consente di garantire un ciclo di vita completo per il lavoro con i contenitori. Tuttavia, lavora solo su un singolo host. Quando è necessario gestire contenitori su più host, Docker può trasformare la vita degli ingegneri in un incubo. È per questo che è stato creato Kubernetes.

La richiesta di Kubernetes è proprio dovuta alla possibilità di gestire gruppi di contenitori su più host come un'unica entità. La popolarità del sistema è garantita dalla possibilità di costruire DevOps o Sviluppo Operativo, nei quali Kubernetes viene utilizzato per avviare i processi di questo stesso DevOps.

Figura 1. Immagine schematica del principio di funzionamento di Kubernetes

Automazione completa

DevOps, 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ò essere automaticamente assemblato immediatamente in un contenitore con tutte le librerie, testato e "rilasciato" alla fase successiva - Staging, e poi subito in produzione.

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é 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ò includere il processo di compilazione, testing e distribuzione. E così avviene per ogni commit, quindi il testing è continuo.

Inoltre, l'uso dei container consente di essere certi che tutto l'ambiente di questo programma andrà in produzione proprio nella forma in cui è stato testato. In altre parole, non ci saranno problemi del tipo "in test c'erano certe versioni, in produzione - altre, e una volta installato – tutto è andato in crash”. Poiché 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à di personale. Ecco perché utilizziamo Kubernetes.

Vantaggi, vantaggi, vantaggi

Parlando dei vantaggi di Kubernetes come piattaforma, ha notevoli benefici in termini di gestione dell'architettura a microservizi.

Gestione di molteplici repliche. La cosa più importante è la gestione dei container su molteplici host. E ciò che è più rilevante è la gestione di molteplici repliche delle applicazioni nei container come un'unica entità. Grazie a questo, gli ingegneri non devono preoccuparsi di ogni singolo container. Se uno dei container si arresta, Kubernetes lo rileverà e lo riavvierà automaticamente.
Rete di cluster. Kubernetes ha anche una cosiddetta rete di cluster con uno spazio di indirizzamento proprio. Grazie a questo, ogni pod ha il proprio indirizzo. Un pod è considerata l'unità strutturale minima del cluster in cui vengono direttamente eseguiti i container. Inoltre, Kubernetes dispone di funzionalità che combinano un bilanciatore di carico e il Service Discovery. Questo elimina la necessità di gestire manualmente gli indirizzi IP e delega questo compito a Kubernetes. I controlli di salute automatici aiuteranno a rilevare i problemi e a reindirizzare il traffico ai pod funzionanti.
Gestione delle configurazioni. Gestire un gran numero di applicazioni rende difficile gestire la configurazione delle applicazioni. Per questo in Kubernetes ci sono risorse speciali chiamate ConfigMap. Queste consentono di memorizzare centralmente le configurazioni e di inserirle nei pod al momento dell'avvio delle applicazioni. Questo meccanismo garantisce la coerenza delle configurazioni in dieci o cento repliche delle applicazioni.
Volumi persistenti. I contenitori sono per loro natura immutabili e, quando un contenitore viene arrestato, tutti i dati scritti nel file system verranno distrutti. Tuttavia, alcune applicazioni memorizzano i dati direttamente su disco. Per risolvere questo problema, in Kubernetes è disponibile una funzionalità di gestione dello storage — Volumi Persistenti. Questo meccanismo utilizza uno storage esterno per i dati e può fornire storage persistente, blocco o file nei contenitori. Questa soluzione consente di memorizzare i dati separati dai worker, il che protegge i dati in caso di guasto di questi ultimi.
Bilanciatore di carico. Nonostante in Kubernetes gestiamo entità astratte come Deployment, StatefulSet, ecc., alla fine i contenitori vengono eseguiti su comuni macchine virtuali server fisici. Non sono ideali e possono guastarsi in qualsiasi momento. Kubernetes lo rileva e reindirizza il traffico interno ad altre repliche. Ma cosa fare con il traffico in arrivo dall'esterno? Se si reindirizza semplicemente il traffico a uno dei worker, che succede se questo fallisce e il servizio diventa non disponibile? Per risolvere questo problema, in Kubernetes ci sono servizi come il Bilanciatore di carico. Questi sono progettati per configurare automaticamente un bilanciatore di carico esterno su tutti i worker nel cluster. Questo bilanciatore esterno dirige il traffico in ingresso verso i worker e monitora il loro stato. Se uno o più worker diventano non disponibili, il traffico viene reindirizzato ad altri. Questo consente di creare servizi ad alta disponibilità utilizzando Kubernetes.

Kubernetes si manifesta al meglio durante l'esecuzione di architetture a microservizi. È possibile implementare il sistema in un'architettura classica, ma non ha senso. Se un'applicazione non può funzionare in più repliche, che differenza fa — se si utilizza Kubernetes o meno?

Kubernetes open source

Kubernetes open source è una cosa fantastica: si installa ed è pronto a funzionare. Puoi implementarlo sui tuoi server hardware, sulla tua infrastruttura, impostare master e worker, su cui verranno eseguite tutte le applicazioni. E la cosa principale è che è tutto gratuito. Tuttavia, ci sono delle complicazioni.

La prima è la richiesta di conoscenze ed esperienza degli amministratori e degli ingegneri che si occuperanno dell'implementazione e del supporto. Poiché il cliente ha la piena libertà di azione nel cluster, la responsabilità per il funzionamento del cluster ricade su di lui. E rompere qualcosa qui è molto semplice.
La seconda è l'assenza di integrazioni. Se avvii Kubernetes senza una qualche piattaforma di virtualizzazione popolare, non potrai sfruttare tutti i vantaggi del programma. Come l'uso di Persistent Volumes e dei servizi Load balancer.

Figura 2. Architettura k8s

Kubernetes fornito dal venditore

L'integrazione con un fornitore cloud offre due possibilità:

In primo luogo, l'utente può semplicemente premere il pulsante "crea cluster" e ricevere un cluster già configurato e pronto per l'uso.
In secondo luogo, il fornitore configura autonomamente il cluster e gestisce l'integrazione con il cloud.

Ecco come funziona da noi. L'ingegnere che avvia il cluster indica quanti worker sono necessari e con quali parametri (ad esempio, 5 worker, ciascuno con 10 CPU, 16 GB di RAM e, diciamo, 100 GB di disco). Dopodiché ottiene accesso al cluster già formato. A questo punto, i worker su cui viene eseguito il carico di lavoro sono completamente a disposizione del cliente, ma tutto il piano di gestione rimane sotto la responsabilità del fornitore (nel caso in cui il servizio venga fornito con il modello di managed service).

Tuttavia, questo schema ha i suoi svantaggi. Poiché il piano di gestione rimane presso il fornitore, quest'ultimo non concede accesso completo al cliente, e questo riduce la flessibilità nell'uso di Kubernetes. A volte il cliente desidera aggiungere a Kubernetes qualche funzionalità specifica, ad esempio l'autenticazione tramite LDAP, ma la configurazione del piano di gestione non lo consente.

Figura 3. Esempio di cluster Kubernetes fornito da un fornitore cloud

Cosa scegliere: open source o fornito dal venditore

Quindi, Kubernetes open source o vendor? Se si opta per Kubernetes open source, l'utente può fare ciò che desidera. Ma c'è un alto rischio di tirarsi la zappa sui piedi. Con quello vendor è più complicato, perché tutto è stato pensato e configurato dall'azienda. Il maggior svantaggio di Kubernetes open source è la richiesta di specialisti. Con il vendor, l'azienda è sollevata da questo grattacapo, ma dovrà decidere: pagare i propri specialisti o il vendor.

Bene, i vantaggi sono evidenti, i svantaggi sono noti. Una cosa rimane invariata: Kubernetes risolve una miriade di problemi automatizzando la gestione di molti contenitori. E quale scegliere, open source o vendor, è una decisione che ognuno prende per sé.