Come funzionano le distribuzioni di Kubernetes
L'app di tracciamento droni include diversi componenti distribuiti separatamente. È necessario configurare le distribuzioni per questi componenti nel cluster. Si esamineranno ora alcune delle opzioni disponibili per la distribuzione di questi componenti.
Opzioni di distribuzione di pod
Sono disponibili diverse opzioni per gestire la distribuzione di pod in un cluster Kubernetes quando si usa kubectl. Le opzioni sono:
- Modelli di pod
- Controller di replica
- Set di repliche
- Deployments
Per distribuire uno o più pod, è possibile usare una di queste quattro definizioni di tipi di oggetto Kubernetes. Questi file usano YAML per descrivere lo stato previsto del pod o dei pod da distribuire.
Che cos'è un modello di pod?
Un modello di pod consente di definire la configurazione del pod che si vuole distribuire. Il modello contiene informazioni come il nome dell'immagine del contenitore e il registro contenitori da usare per recuperare le immagini. Il modello include anche informazioni di configurazione del runtime, ad esempio le porte da usare. I modelli si definiscono usando YAML, nello stesso modo in cui si creano i file Docker.
È possibile usare modelli per distribuire i pod manualmente. Un pod distribuito manualmente, tuttavia, non viene riavviato in caso di errore oppure se viene eliminato o terminato. Per gestire il ciclo di vita di un pod, è necessario creare un oggetto Kubernetes di livello superiore.
Che cos'è un controller di replica?
Un controller di replica usa i modelli di pod e definisce un numero specificato di pod che devono essere eseguiti. Il controller consente di eseguire più istanze dello stesso pod e assicura che i pod siano sempre in esecuzione in uno o più nodi del cluster. Il controller sostituisce i pod in esecuzione in questo modo con nuovi pod in caso di errore, se vengono eliminati o se vengono terminati.
Si supponga, ad esempio, di distribuire il sito Web front-end di tracciamento droni e che gli utenti inizino ad accedere al sito Web. Se, per qualsiasi motivo, nessun pod funziona correttamente, il sito Web non è disponibile per gli utenti a meno che non vengano avviati nuovi pod. Un controller di replica consente di assicurarsi che il sito Web sia sempre disponibile.
Che cos'è un set di repliche?
I set di repliche sostituiscono il controller di replica come metodo consigliato per la distribuzione delle repliche. Un set di repliche include la stessa funzionalità di un controller di repliche, ma ha un'opzione di configurazione aggiuntiva per includere un valore del selettore.
Un selettore consente al set di repliche di identificare tutti i pod in esecuzione sotto di esso. Con questa funzionalità è possibile gestire i pod etichettati con lo stesso valore del selettore, ma non creati con il set replicato.
Che cos'è una distribuzione?
Una distribuzione crea un oggetto di gestione di un livello superiore rispetto a un set di repliche e consente di distribuire e gestire gli aggiornamenti per i pod in un cluster.
Si supponga di avere a disposizione cinque istanze dell'app distribuite nel cluster. Sono disponibili cinque pod che eseguono la versione 1.0.0 dell'app.
Se si decide di aggiornare manualmente l'app, è possibile rimuovere tutti i pod, quindi avviare nuovi pod che eseguono la versione 2.0.0 dell'app. Con questa strategia, l'app riscontra tempi di inattività.
È invece preferibile eseguire un aggiornamento in sequenza in cui si avviano i pod che eseguono la nuova versione dell'app prima di rimuovere i pod con la versione precedente. Gli aggiornamenti in sequenza avviano un pod alla volta anziché arrestare tutti i pod precedenti contemporaneamente. Le distribuzioni rispettano il numero di repliche configurate nella sezione che descrive le informazioni sui set di repliche. Quando i pod precedenti vengono sostituiti da nuovi pod, viene mantenuto il numero di pod specificato nel set di repliche.
Per impostazione predefinita, le distribuzioni offrono una strategia di aggiornamento in sequenza per l'aggiornamento dei pod. È anche possibile usare una strategia di ricreazione. Questa strategia termina i pod prima di avviare nuovi pod.
Le distribuzioni offrono anche una strategia di rollback, che è possibile eseguire usando kubectl.
Le distribuzioni usano i file di definizione basati su YAML e semplificano la gestione delle distribuzioni. Tenere presente che le distribuzioni consentono di applicare eventuali modifiche al cluster. È ad esempio possibile distribuire nuove versioni di un'app, aggiornare le etichette ed eseguire altre repliche dei pod.
kubectl ha una sintassi pratica per creare automaticamente una distribuzione quando si usa il comando kubectl run per distribuire un pod. Questo comando crea una distribuzione con il set di repliche e i pod richiesti. Tuttavia, il comando non crea un file di definizione. La procedura consigliata consiste nel gestire tutte le distribuzioni con i file di definizione della distribuzione e tenere traccia delle modifiche usando un sistema di controllo della versione.
Considerazioni sulla distribuzione
Kubernetes ha requisiti specifici per la configurazione della rete e dell'archiviazione per un cluster. La configurazione di questi due aspetti influisce sulle decisioni su come esporre le app nella rete del cluster e archiviare i dati.
Ad esempio, ogni servizio nell'app di tracciamento droni ha requisiti specifici per l'accesso utente, l'accesso alla rete tra processi e per l'archiviazione dei dati. Di seguito vengono esaminati questi aspetti di un cluster Kubernetes e il modo in cui influiscono sulla distribuzione delle app.
Rete Kubernetes
Si supponga di avere un cluster con un piano di controllo e due nodi. Quando si aggiungono nodi a Kubernetes, viene assegnato automaticamente a ogni nodo un indirizzo IP di un intervallo di rete privato interno. Si supponga, ad esempio, che l'intervallo della rete locale sia 192.168.1.0/24.
A ogni pod distribuito viene assegnato un indirizzo IP di un pool di indirizzi IP. Ad esempio, si supponga che la configurazione usi l'intervallo di rete 10.32.0.0/12, come illustrato nell'immagine seguente.
Per impostazione predefinita, i pod e i nodi non possono comunicare tra loro usando intervalli di indirizzi IP diversi.
Per complicare ulteriormente la situazione, tenere presente che i pod sono temporanei. L'indirizzo IP del pod è temporaneo e non può essere usato per riconnettersi a un pod appena creato. Questa configurazione ha effetto sul modo in cui l'app comunica con i componenti interni e sull'interazione esterna dei servizi con l'applicazione.
Per semplificare la comunicazione, Kubernetes prevede che la rete venga configurata in modo che:
- I pod possano comunicare reciprocamente tra i nodi senza NAT (Network Address Translation).
- I nodi possono comunicare con tutti i pod e viceversa, senza NAT.
- Gli agenti in un nodo possano comunicare con tutti i nodi e i pod.
Kubernetes offre diverse opzioni di rete che è possibile installare per configurare la rete. Tra gli esempi sono inclusi Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T e Weave Net.
Anche i provider di servizi cloud offrono le proprie soluzioni di rete. Ad esempio, il servizio Azure Kubernetes (AKS) supporta l'interfaccia di rete del contenitore Rete virtuale di Azure, Kubenet, Flannel, Cilium e Antrea.
Servizi Kubernetes
Un servizio Kubernetes è un oggetto Kubernetes che offre una rete stabile per i pod. Un servizio Kubernetes consente la comunicazione tra nodi, pod e utenti dell'app, sia interni che esterni, con il cluster.
Kubernetes assegna a un servizio un indirizzo IP durante la creazione come avviene per un nodo o un pod. Questi indirizzi vengono assegnati da un intervallo IP del cluster di servizio, ad esempio 10.96.0.0/12. Al servizio vengono anche assegnati un nome DNS basato sul nome del servizio e una porta IP.
Nell'app di tracciamento droni la comunicazione di rete è la seguente:
Il sito Web e l'API RESTful sono accessibili agli utenti esterni al cluster.
La cache in memoria e i servizi di accodamento messaggi sono accessibili rispettivamente al front-end e all'API RESTful, ma non agli utenti esterni.
La coda di messaggi deve accedere al servizio di elaborazione dati, ma non agli utenti esterni.
Il database NoSQL è accessibile alla cache in memoria e al servizio di elaborazione dati, ma non agli utenti esterni.
Per supportare questi scenari, è possibile configurare tre tipi di servizi per esporre i componenti dell'app.
| Servizio | Descrizione |
|---|---|
| ClusterIP | Indirizzo assegnato a un servizio che rende disponibile il servizio a un set di servizi all'interno del cluster. Ad esempio, la comunicazione tra i componenti front-end e back-end dell'app. |
| NodePort | Porta del nodo, compresa tra 30000 e 32767, che il piano di controllo Kubernetes assegna al servizio, ad esempio 192.169.1.11 in clusters01. Si procede quindi a configurare il servizio con una porta di destinazione nel pod che si vuole esporre. Configurare, ad esempio, la porta 80 nel pod che esegue uno dei front-end. È ora possibile accedere al front-end tramite l'indirizzo IP e di porta di un nodo. |
| LoadBalancer | Servizio di bilanciamento del carico che consente la distribuzione del carico tra i nodi che eseguono l'app ed espongono i pod all'accesso di rete pubblica. I servizi di bilanciamento del carico vengono in genere configurati quando si usano i provider di servizi cloud. In questo caso, il traffico proveniente dal servizio di bilanciamento del carico esterno viene indirizzato ai pod che eseguono l'app. |
Nell'app di tracciamento droni si può decidere di esporre il sito Web di tracciamento e l'API RESTful usando un servizio LoadBalancer e il servizio di elaborazione dati con un ClusterIP.
Come raggruppare i pod
La gestione dei pod in base all'indirizzo IP non è pratica. Gli indirizzi IP dei pod cambiano quando i controller li ricreano ed è possibile eseguire un numero qualsiasi di pod.
Un oggetto servizio consente di definire come destinazione e gestire pod specifici nel cluster usando le etichette dei selettori. Impostare l'etichetta del selettore in una definizione del servizio in modo che corrisponda all'etichetta del pod definita nel file di definizione del pod.
Si supponga, ad esempio, di avere numerosi pod in esecuzione. Solo alcuni di questi pod sono nel front-end e si vuole impostare un servizio LoadBalancer che abbia come destinazione solo i pod front-end. È possibile applicare il servizio per esporre questi pod facendo riferimento all'etichetta dei pod come valore del selettore nel file di definizione del servizio. Il servizio raggruppa solo i pod che corrispondono all'etichetta. Se un pod viene rimosso e ricreato, il nuovo pod viene aggiunto automaticamente al gruppo di servizi tramite l'etichetta corrispondente.
Archiviazione di Kubernetes
Kubernetes usa lo stesso concetto di volume di archiviazione che si trova quando si usa Docker. I volumi Docker sono meno gestiti rispetto ai volumi Kubernetes perché la durata dei volumi Docker non è gestita. La durata del volume Kubernetes è una durata esplicita che corrisponde alla durata del pod. Questa corrispondenza di durata indica che un volume sopravvive ai contenitori eseguiti nel pod. Tuttavia, se il pod viene rimosso, viene rimosso anche il volume.
Kubernetes offre opzioni per il provisioning di un'archiviazione persistente con l'uso di PersistentVolumes. È anche possibile richiedere una risorsa di archiviazione specifica per i pod usando PersistentVolumeClaims.
Tenere presenti entrambe queste opzioni quando si distribuiscono i componenti dell'app che richiedono un'archiviazione permanente come le code di messaggi e i database.
Considerazioni sull'integrazione del cloud
Kubernetes non impone lo stack di tecnologie da usare nell'app nativa del cloud. In un ambiente cloud come Azure, è possibile usare diversi servizi all'esterno del cluster Kubernetes.
Si ricordi che in precedenza Kubernetes non fornisce i servizi seguenti:
- Middleware
- Framework di elaborazione dati
- Database
- Cache
- Sistemi di archiviazione cluster
In questa soluzione di tracciamento droni ci sono tre servizi che offrono funzionalità middleware, ovvero un database NoSQL, un servizio di cache in memoria e una coda di messaggi. Si potrebbe scegliere di usare MongoDB Atlas per la soluzione NoSQL, Redis per gestire la cache in memoria e RabbitMQ oppure Kafka, a seconda delle esigenze della coda di messaggi.
Quando si usa un ambiente cloud, ad esempio Azure, è consigliabile usare servizi all'esterno del cluster Kubernetes. Questa decisione può semplificare la configurazione e la gestione del cluster. Ad esempio, è possibile usare la cache di Azure per Redis per i servizi di cache in memoria, la messaggistica del bus di servizio di Azure per la coda di messaggi e Azure Cosmos DB per il database NoSQL.