Kubernetes: open source e specifico del fornitore

Ciao, mi chiamo Dmitry Krasnov. Da più di cinque anni amministro cluster Kubernetes e creo complesse architetture di microservizi. All'inizio di quest'anno abbiamo lanciato un servizio per la gestione dei cluster Kubernetes basato su Containerum. Cogliendo l'occasione, ti dirò cos'è Kubernetes e in che modo l'integrazione con un fornitore differisce dall'open source.

Per cominciare, cos'è kubernetes. Questo è un sistema per la gestione dei contenitori su un gran numero di host. Dal greco, a proposito, è tradotto come "pilota" o "timoniere". Sviluppato originariamente da Google e poi donato come contributo tecnologico alla Cloud Native Computing Foundation, un'organizzazione internazionale senza scopo di lucro che riunisce i principali sviluppatori, utenti finali e fornitori di tecnologia container del mondo.

Gestisci un gran numero di contenitori

Ora scopriamo che tipo di contenitori sono questi. Questa è un'applicazione con il suo intero ambiente, principalmente le librerie da cui dipende il programma. Tutto questo è confezionato in archivi e presentato sotto forma di un'immagine che può essere eseguita indipendentemente dal sistema operativo, testata e altro ancora. Ma c'è un problema: gestire i container su un gran numero di host è molto difficile. Ecco perché è stato creato Kubernetes.

Un'immagine contenitore rappresenta un'applicazione più le sue dipendenze. L'applicazione, le sue dipendenze e l'immagine del file system del sistema operativo si trovano in parti diverse dell'immagine, i cosiddetti livelli. I livelli possono essere riutilizzati per contenitori diversi. Ad esempio, tutte le applicazioni di un'azienda potrebbero utilizzare il livello base di Ubuntu. Quando si eseguono contenitori, non è necessario archiviare più copie di un singolo livello di base sull'host. Ciò consente di ottimizzare l'archiviazione e la consegna delle immagini.

Quando vogliamo eseguire un'applicazione da un contenitore, i livelli necessari vengono sovrapposti l'uno all'altro e viene formato un file system sovrapposto. Sopra viene posizionato uno strato di registrazione, che viene rimosso quando il contenitore si ferma. Ciò garantisce che quando il contenitore viene eseguito, l'applicazione avrà sempre lo stesso ambiente, che non può essere modificato. Ciò garantisce la riproducibilità dell'ambiente su diversi sistemi operativi host. Che si tratti di Ubuntu o CentOS, l'ambiente sarà sempre lo stesso. Inoltre, il contenitore è isolato dall'host utilizzando meccanismi integrati nel kernel Linux. Le applicazioni in un contenitore non vedono file, processi dell'host e contenitori vicini. Questo isolamento delle applicazioni dal sistema operativo host fornisce un ulteriore livello di sicurezza.

Sono disponibili molti strumenti per gestire i contenitori su un host. Il più popolare è Docker. Consente di fornire l'intero ciclo di vita dei contenitori. Tuttavia, funziona solo su un host. Se devi gestire container su più host, Docker può rendere la vita un inferno agli ingegneri. Ecco perché è stato creato Kubernetes.

La richiesta di Kubernetes è dovuta proprio alla capacità di gestire gruppi di contenitori su più host come una sorta di singola entità. La popolarità del sistema offre l'opportunità di creare DevOps o operazioni di sviluppo, in cui Kubernetes viene utilizzato per eseguire i processi di questo stesso DevOps.

Figura 1. Rappresentazione schematica di come funziona Kubernetes

Automazione completa

DevOps è fondamentalmente l'automazione del processo di sviluppo. In parole povere, gli sviluppatori scrivono il codice che viene caricato nel repository. Quindi questo codice può essere automaticamente raccolto immediatamente in un contenitore con tutte le librerie, testato e “spiegato” alla fase successiva - Staging, e poi immediatamente alla Produzione.

Insieme a Kubernetes, DevOps consente di automatizzare questo processo in modo che avvenga praticamente senza la partecipazione degli stessi sviluppatori. Per questo motivo, la compilazione è significativamente più veloce, poiché lo sviluppatore non deve farlo sul suo computer: scrive semplicemente un pezzo di codice, inserisce il codice nel repository, dopodiché viene avviata la pipeline, che può includere il processo di costruzione, test e implementazione. E questo accade con ogni commit, quindi i test avvengono continuamente.

Allo stesso tempo, l'utilizzo di un contenitore consente di essere sicuri che l'intero ambiente di questo programma verrà rilasciato in produzione esattamente nella forma in cui è stato testato. Cioè, non ci saranno problemi del tipo "c'erano alcune versioni in test, altre in produzione, ma quando le abbiamo installate tutto è caduto". E poiché oggi abbiamo una tendenza verso l'architettura dei microservizi, quando invece di un'enorme applicazione ce ne sono centinaia di piccole, per amministrarle manualmente sarà necessario un enorme staff di dipendenti. Ecco perché utilizziamo Kubernetes.

Professionisti, professionisti, professionisti

Se parliamo dei vantaggi di Kubernetes come piattaforma, presenta vantaggi significativi dal punto di vista della gestione dell'architettura dei microservizi.

• Gestione di più repliche. La cosa più importante è gestire i contenitori su più host. Ancora più importante, gestisci più repliche di applicazioni nei contenitori come un'unica entità. Grazie a ciò, gli ingegneri non devono preoccuparsi di ogni singolo contenitore. Se uno dei contenitori si arresta in modo anomalo, Kubernetes lo vedrà e lo riavvierà di nuovo.
• Rete di cluster. Kubernetes dispone inoltre di una cosiddetta rete cluster con un proprio spazio di indirizzi. Grazie a questo, ogni pod ha il proprio indirizzo. Per sottopod si intende l'unità strutturale minima di un cluster in cui vengono lanciati direttamente i container. Inoltre, Kubernetes dispone di funzionalità che combinano un sistema di bilanciamento del carico e Service Discovery. Ciò ti consente di eliminare la gestione manuale degli indirizzi IP e delegare questa attività a Kubernetes. Inoltre, i controlli di integrità automatici aiuteranno a rilevare i problemi e a reindirizzare il traffico ai pod funzionanti.
• Gestione della configurazione. Quando si gestiscono un numero elevato di applicazioni, diventa difficile gestire la configurazione dell'applicazione. A questo scopo Kubernetes dispone di speciali risorse ConfigMap. Consentono di archiviare centralmente le configurazioni ed esporle ai pod durante l'esecuzione delle applicazioni. Questo meccanismo ci permette di garantire la consistenza della configurazione in almeno dieci o cento repliche applicative.
• Volumi persistenti. I contenitori sono intrinsecamente immutabili e quando il contenitore viene arrestato, tutti i dati scritti nel file system verranno distrutti. Ma alcune applicazioni memorizzano i dati direttamente su disco. Per risolvere questo problema, Kubernetes dispone di una funzionalità di gestione dell'archiviazione su disco: Volumi persistenti. Questo meccanismo utilizza l'archiviazione esterna per i dati e può trasferire l'archiviazione persistente, blocco o file, in contenitori. Questa soluzione consente di archiviare i dati separatamente dai lavoratori, salvandoli in caso di guasto degli stessi lavoratori.
• Bilanciatore del carico. Anche se in Kubernetes gestiamo entità astratte come Deployment, StatefulSet, ecc., alla fine i contenitori vengono eseguiti su normali macchine virtuali o server hardware. Non sono perfetti e possono cadere in qualsiasi momento. Kubernetes lo vedrà e reindirizzerà il traffico interno ad altre repliche. Ma cosa fare con il traffico che arriva da fuori? Se indirizzi semplicemente il traffico a uno dei lavoratori, se si blocca, il servizio non sarà più disponibile. Per risolvere questo problema, Kubernetes dispone di servizi come Load Balancer. Sono progettati per configurare automaticamente un bilanciatore cloud esterno per tutti i lavoratori nel cluster. Questo bilanciatore esterno dirige il traffico esterno verso i lavoratori e ne monitora lo stato stesso. Se uno o più lavoratori non sono più disponibili, il traffico viene reindirizzato ad altri. Ciò ti consente di creare servizi ad alta disponibilità utilizzando Kubernetes.

Kubernetes funziona meglio quando si eseguono architetture di microservizi. È possibile implementare il sistema nell’architettura classica, ma è inutile. Se un'applicazione non può essere eseguita su più repliche, che differenza fa: in Kubernetes o no?

Kubernetes open source

Kubernetes open source è una gran cosa: l'ho installato e funziona. Puoi distribuirlo sui tuoi server hardware, sulla tua infrastruttura, installare master e lavoratori su cui verranno eseguite tutte le applicazioni. E, soprattutto, tutto questo è gratuito. Tuttavia, ci sono delle sfumature.

• Il primo è la richiesta di conoscenza ed esperienza da parte di amministratori e ingegneri che implementeranno e supporteranno tutto questo. Poiché il cliente riceve completa libertà d'azione nel cluster, è lui stesso responsabile dell'esecuzione del cluster. Ed è molto facile rompere tutto qui.
• Il secondo è la mancanza di integrazioni. Se esegui Kubernetes senza una piattaforma di virtualizzazione popolare, non otterrai tutti i vantaggi del programma. Come l'utilizzo di volumi persistenti e servizi di bilanciamento del carico.

Figura 2. Architettura k8s

Kubernetes dal fornitore

L'integrazione con un fornitore di servizi cloud offre due opzioni:

• In primo luogo, una persona può semplicemente fare clic sul pulsante “crea cluster” e ottenere un cluster già configurato e pronto per l’uso.
• In secondo luogo, il fornitore stesso installa il cluster e configura l'integrazione con il cloud.

Come succede qui. L'ingegnere che avvia il cluster specifica di quanti lavoratori ha bisogno e con quali parametri (ad esempio, 5 lavoratori, ciascuno con 10 CPU, 16 GB di RAM e, diciamo, 100 GB di disco). Successivamente accede al cluster già formato. In questo caso i lavoratori su cui viene lanciato il carico vengono trasferiti completamente al cliente, ma l'intero piano di gestione rimane sotto la responsabilità del venditore (se il servizio è erogato secondo il modello del servizio gestito).

Tuttavia, questo schema ha i suoi svantaggi. Dato che il piano di gestione rimane presso il fornitore, il fornitore non fornisce pieno accesso al cliente e ciò riduce la flessibilità nel lavorare con Kubernetes. A volte capita che un client voglia aggiungere alcune funzionalità specifiche a Kubernetes, ad esempio l'autenticazione tramite LDAP, ma la configurazione del piano di gestione non lo consente.

Figura 3. Esempio di un cluster Kubernetes di un fornitore di servizi cloud

Cosa scegliere: open source o fornitore

Quindi, Kubernetes è open source o specifico del fornitore? Se prendiamo Kubernetes open source, l'utente ne fa ciò che vuole. Ma c'è una grande possibilità di darti la zappa sui piedi. Con il venditore è più difficile, perché tutto è pensato e configurato per l’azienda. Il più grande svantaggio di Kubernetes open source è la necessità di specialisti. Con l'opzione venditore l'azienda si libera da questo grattacapo, ma dovrà decidere se pagare i propri specialisti o il venditore.

Bene, i pro sono evidenti, anche i contro sono noti. Una cosa è costante: Kubernetes risolve molti problemi automatizzando la gestione di molti contenitori. E quale scegliere, open source o fornitore: ognuno prende la propria decisione.

L'articolo è stato preparato da Dmitry Krasnov, architetto leader del servizio Containerum del provider #CloudMTS

Fonte: habr.com