Cos'è Kubernetes?

Cos'è Kubernetes? E qual è la sua architettura?

La containerizzazione ha tagliato il cavo tra gli sviluppatori di software e l'ambiente di produzione. Non nel senso che non hai affatto un sistema di produzione, ma non devi preoccuparti della specificità dell'ambiente di produzione.

Le app sono ora in bundle con le dipendenze di cui hanno bisogno, in un contenitore leggero anziché in una VM. È grandioso! Tuttavia, non fornisce immunità da guasti del sistema, guasti alla rete o guasti al disco. Ad esempio, se il data center, in cui i server sono in esecuzione, è in manutenzione, l'applicazione andrà offline.

Kubernetes entra in foto per risolvere questi problemi. Ci vuole l'idea dei contenitori e lo estende per funzionare su più nodi di calcolo (che potrebbero essere una macchina virtuale ospitata da cloud o server metallici nudi). L'idea è di avere un sistema distribuito per le applicazioni containerizzate su.

Perché Kubernetes?

Ora, perché dovresti avere un ambiente distribuito in primo luogo?

Per molteplici motivi, in primo luogo è alta disponibilità. Vuoi che il tuo sito Web di e-commerce rimanga online 24 ore su 24, 7 giorni su 7, oppure perderai affari, utilizzerai Kubernetes per questo. Il secondo è la scalabilità, dove vuoi ridimensionare ". Il ridimensionamento qui prevede l'aggiunta di più nodi di calcolo per dare alla tua crescente applicazione più spazio per le gambe per operare.

Design e architettura

Come ogni sistema distribuito, un cluster Kubernetes ha un nodo principale e quindi un sacco di nodi lavorativi che è dove le tue applicazioni sarebbero effettivamente eseguite. Il master è responsabile della pianificazione delle attività, della gestione dei carichi di lavoro e dell'aggiunta in modo sicuro nuovi nodi al cluster.

Ora, ovviamente, il nodo principale stesso può fallire e portare con sé l'intero cluster, quindi Kubernetes ti consente di avere più nodi principali per la ridondanza.

Una vista a volo d'uccello di una tipica distribuzione di Kubernetes

Kubernetes Master

Il Master Kubernetes è ciò con cui il team DevOps interagisce e utilizza per il provisioning di nuovi nodi, distribuendo nuove app e monitoraggio e gestione delle risorse. L'attività più semplice del nodo principale è di programma Il carico di lavoro in modo efficiente tra tutti i nodi del lavoratore per massimizzare l'utilizzo delle risorse, migliorare le prestazioni e seguire varie politiche scelte dal team DevOps per il loro particolare carico di lavoro.

Un altro componente importante è il ecc che è un demone che tiene traccia dei nodi del lavoratore e mantiene un database memorizzazione dello stato dell'intero cluster. È un archivio dati di valore chiave, che può anche funzionare su un ambiente distribuito su più nodi principali. Il contenuto di etcd fornisce tutti i dati pertinenti sull'intero cluster. Un nodo lavoratore esaminerebbe di tanto in tanto il contenuto di ETCD per determinare come dovrebbe comportarsi.

Controller è l'entità che prenderebbe le istruzioni dal server API (che tratteremo in seguito) ed eseguirà azioni necessarie come la creazione, la cancellazione e l'aggiornamento di applicazioni e pacchetti.

IL Server API Espone l'API di Kubernetes, che utilizza carichi di utili JSON su HTTPS, per comunicare con l'interfaccia utente con cui i team degli sviluppatori o il personale DevOps alla fine finirebbero per interagire. Sia l'interfaccia utente Web che la CLI consumano questa API per interagire con il cluster Kubernetes.

Il server API è anche responsabile della comunicazione tra i nodi del lavoratore e vari componenti del nodo principale come ecc.

Il nodo principale non è mai esposto all'utente finale in quanto rischiare la sicurezza dell'intero cluster.

Nodi Kubernetes

Una macchina (fisica o virtuale) avrebbe bisogno di alcuni componenti importanti che una volta installati e impostati correttamente possono quindi trasformare quel server in un membro del cluster Kubernetes.

La prima cosa di cui avrai bisogno è un runtime del contenitore, come Docker, installato e in esecuzione su di esso. Sarà responsabile per la rotazione e la gestione dei contenitori, ovviamente.

Insieme al runtime di Docker, abbiamo anche bisogno del Kubelet demone. Comunica con i nodi principali, tramite il server API e interroga l'ETCD, e fornisce informazioni sulla salute e sull'utilizzo sui pod che sono in esecuzione su quel nodo.

Tuttavia, i contenitori sono piuttosto limitati da soli, quindi Kubernetes ha una maggiore astrazione costruita sopra una raccolta di contenitori, nota come Baccelli.

Perché inventare i baccelli?

Docker ha una politica di esecuzione di un'applicazione per container. Spesso descritto come il "Un processo per contenitore" politica. Ciò significa che se hai bisogno di un sito WordPress, sei incoraggiato ad avere due contenitori uno per il database da eseguire e un altro per il server Web. Bundling tali componenti correlati di un'applicazione in un pod assicura che ogni volta che si scala, i due contenitori inter-dipendenti coesistono sempre sullo stesso nodo e quindi si parlano rapidamente e facilmente.

I pod sono l'unità fondamentale di distribuzione in Kubernetes. Quando si ridimensiona, aggiungi più baccelli al cluster. A ogni pod viene dato il proprio indirizzo IP univoco all'interno della rete interna del cluster.

Torna al nodo Kubernetes

Ora un nodo può eseguire più pod e ci possono essere molti di questi nodi. Va tutto bene finché non pensi di provare a comunicare con il mondo esterno. Se hai un semplice servizio basato sul Web come punteresti il ​​tuo nome di dominio a questa raccolta di pod con molti indirizzi IP?

Non puoi e non è necessario! Kube-Proxy è l'ultimo pezzo del puzzle che consente agli operatori di esporre alcuni pod su Internet. Ad esempio, il tuo front-end può essere reso pubblicamente accessibile e Kube-Proxy distribuirebbe il traffico tra tutti i vari pod che sono responsabili dell'hosting del front-end. Il tuo database, tuttavia, non deve essere reso pubblico e Kube-Proxy consentirebbe solo la comunicazione interna per tali carichi di lavoro correlati al back-end.

Hai bisogno di tutto questo?

Se hai appena iniziato come hobbista o studente, usare Kubernetes per una semplice applicazione sarebbe effettivamente inefficiente. L'intero rigmarole consumerebbe più risorse della tua effettiva applicazione e aggiungerebbe più confusione per un singolo individuo.

Tuttavia, se hai intenzione di lavorare con un grande team e distribuire le tue app per un uso commerciale serio, Kubernetes vale la pena aggiunta. Puoi impedire alle cose di diventare caotico. Fai spazio alla manutenzione senza tempi di inattività. Imposta le condizioni di test A/B Nifty e ridimensiona gradualmente senza spendere troppo sull'infrastruttura in anticipo.