Funzionamento di Kubernetes
Per un'installazione di Kubernetes configurata correttamente è necessaria una buona conoscenza dell'architettura del sistema Kubernetes. Di seguito sono descritti tutti i componenti inclusi in un'installazione di Kubernetes.
Che cos'è un cluster di computer?
Un cluster è un set di computer configurati per essere utilizzati insieme e visualizzati come singolo sistema. I computer configurati nel cluster gestiscono gli stessi tipi di attività. Ad esempio, tutti ospiteranno siti Web, API o eseguiranno operazioni a elevato utilizzo di calcolo.
Un cluster usa un software centralizzato che è responsabile della pianificazione e del controllo di queste attività. I computer di un cluster che eseguono le attività sono chiamati nodi, mentre i computer che eseguono il software di pianificazione sono chiamati piani di controllo.
Architettura di Kubernetes
Come affermato in precedenza, un agente di orchestrazione è un sistema che distribuisce e gestisce le app. Si è anche appreso che un cluster è un set di computer utilizzati insieme e visualizzati come singolo sistema. Viene usato Kubernetes come software di orchestrazione e cluster per distribuire le app e rispondere ai cambiamenti nelle esigenze delle risorse di calcolo.
Un cluster Kubernetes contiene almeno un piano principale e uno o più nodi. Le istanze dei piani di controllo e dei nodi possono essere dispositivi fisici, macchine virtuali o istanze nel cloud. Il sistema operativo host predefinito in Kubernetes è Linux, con il supporto predefinito per i carichi di lavoro basati su Linux.
È anche possibile eseguire carichi di lavoro Microsoft usando Windows Server 2019 o versioni successive nei nodi del cluster. Si supponga, ad esempio, che il servizio di elaborazione dati nell'app di tracciamento droni sia scritto come app .NET 4.5 che usa chiamate API del sistema operativo Windows specifiche. Questo servizio può essere eseguito solo nei nodi che eseguono un sistema operativo Windows Server.
Verranno ora descritti in maggiore dettaglio i piani di controllo, i nodi di lavoro e il software eseguito in ogni nodo. Conoscere il ruolo di ogni componente e la posizione in cui ogni componente viene eseguito nel cluster risulterà utile quando si eseguirà l'installazione di Kubernetes.
Piano di controllo Kubernetes
In un cluster Kubernetes, il piano di controllo Kubernetes esegue una raccolta di servizi che gestiscono la funzionalità di orchestrazione in Kubernetes.
Dal punto di vista dell'apprendimento, è opportuno usare un singolo piano di controllo nell'ambiente di test mentre si esplorano le funzionalità di Kubernetes. Nelle distribuzioni di produzione e cloud, ad esempio nel servizio Azure Kubernetes, la configurazione consigliata è tuttavia una distribuzione a disponibilità elevata con un numero di piani di controllo replicati compreso tra tre e cinque.
Nota
Il fatto che un piano di controllo esegua software specifico per gestire lo stato del cluster non gli impedisce di eseguire altri carichi di lavoro di calcolo. Tuttavia, in genere si esclude il piano di controllo dall'esecuzione di carichi di lavoro non critici e di app utente.
Nodo Kubernetes
Un nodo in un cluster Kubernetes è la posizione in cui vengono eseguiti i carichi di lavoro di calcolo. Ogni nodo comunica con il piano di controllo tramite il server API per comunicare le modifiche di stato nel nodo.
Servizi eseguiti in un piano di controllo
Kubernetes utilizza diversi servizi amministrativi in esecuzione sul piano di controllo. Questi servizi gestiscono aspetti quali la comunicazione tra i componenti del cluster, la pianificazione del carico di lavoro e la persistenza dello stato del cluster.
I servizi seguenti costituiscono il piano di controllo di un cluster Kubernetes:
- Server API
- Archivio di backup
- Utilità di pianificazione
- Gestione controller
- Gestione controller cloud
Che cos'è il server API?
È possibile considerare il server API come front-end per il piano di controllo del cluster Kubernetes. Tutte le comunicazioni tra i componenti in Kubernetes vengono eseguite tramite questa API.
Come utente, ad esempio, si usa un'app della riga di comando denominata kubectl che consente di eseguire comandi nel server API del cluster Kubernetes. Il componente che fornisce questa API è denominato kube-apiserver ed è possibile distribuire diverse istanze di questo componente per supportare il ridimensionamento nel cluster.
Questa API espone un'API RESTful che è possibile usare per inviare comandi o file di configurazione basati su YAML. YAML è uno standard di serializzazione dei dati leggibile per i linguaggi di programmazione. Usare i file YAML per definire lo stato previsto di tutti gli oggetti all'interno di un cluster Kubernetes.
Ad esempio, si supponga di voler aumentare il numero di istanze dell'app nel cluster. Si definisce il nuovo stato con un file basato su YAML e si invia questo file al server API. Il server API convalida la configurazione, la salva nel cluster e infine applica l'aumento configurato nelle distribuzioni dell'app.
Che cos'è l'archivio di backup?
L'archivio di backup è un archivio permanente in cui il cluster Kubernetes salva la configurazione completata. Kubernetes usa un archivio chiave-valore affidabile distribuito e a disponibilità elevata denominato etcd. Questo archivio chiave-valore archivia lo stato corrente e lo stato desiderato di tutti gli oggetti all'interno del cluster.
In un cluster Kubernetes di produzione, l'indicazione ufficiale di Kubernetes prevede da tre a cinque istanze replicate del database etcd per la disponibilità elevata.
Nota
etcd non è responsabile del backup dei dati. È responsabilità dell'utente assicurarsi che sia attivo un piano di backup efficace per eseguire il backup dei dati etcd.
Che cos'è l'utilità di pianificazione?
L'utilità di pianificazione è il componente responsabile dell'assegnazione dei carichi di lavoro in tutti i nodi. L'utilità di pianificazione monitora il cluster per individuare i nuovi contenitori creati e li assegna ai nodi.
Che cos'è la gestione controller?
La gestione controller è responsabile dell'avvio e del monitoraggio dei controller configurati per un cluster tramite il server API.
Kubernetes usa i controller per tenere traccia degli stati degli oggetti nel cluster. Ogni controller viene eseguito in un ciclo non determinivo durante il controllo e la risposta agli eventi nel cluster. Ad esempio, sono disponibili controller per il monitoraggio di nodi, contenitori ed endpoint.
Il controller comunica con il server API per determinare lo stato dell'oggetto. Se lo stato corrente è diverso dallo stato previsto dell'oggetto, il controller interviene per garantire lo stato previsto.
Si supponga che uno dei tre contenitori in esecuzione nel cluster smetta di rispondere e abbia esito negativo. In questo caso, un controller decide se è necessario avviare nuovi contenitori per assicurarsi che le app siano sempre disponibili. Se lo stato desiderato è eseguire tre contenitori in qualsiasi momento, viene pianificata l'esecuzione di un nuovo contenitore.
Che cos'è la gestione controller cloud?
La gestione controller cloud si integra con le tecnologie cloud sottostanti nel cluster quando il cluster è in esecuzione in un ambiente cloud. Questi servizi possono essere servizi di bilanciamento del carico, code e archiviazione, ad esempio.
Servizi eseguiti in un nodo
In un nodo Kubernetes vengono eseguiti diversi servizi che controllano le modalità di esecuzione dei carichi di lavoro.
Nel nodo Kubernetes vengono eseguiti i servizi di seguito:
- Kubelet
- Kube-proxy
- Runtime del contenitore
Che cos'è il kubelet?
Il kubelet è l'agente che viene eseguito in ogni nodo del cluster e monitora le richieste di lavoro dal server API. Garantisce che l'unità di lavoro richiesta sia in esecuzione e integra.
Il kubelet monitora i nodi e verifica che i contenitori pianificati in ogni nodo vengano eseguiti come previsto. Il kubelet gestisce solo i contenitori che crea Kubernetes. Non è responsabile della ripianificazione del lavoro da eseguire in altri nodi se il nodo corrente non riesce a eseguire il lavoro.
Che cos'è kube-proxy?
Il componente kube-proxy è responsabile della rete di cluster locale e viene eseguito in ogni nodo. Garantisce che ogni nodo abbia un indirizzo IP univoco. Implementa anche le regole per gestire il routing e il bilanciamento del carico del traffico tramite iptables e IPVS.
Questo proxy non offre automaticamente i servizi DNS. Un componente aggiuntivo del cluster DNS basato su CoreDNS è raccomandato e installato per impostazione predefinita.
Che cos'è il runtime del contenitore?
Il runtime del contenitore è il software sottostante che esegue i contenitori in un cluster Kubernetes. Il runtime è responsabile del recupero, dell'avvio e dell'arresto delle immagini del contenitore. Kubernetes supporta diversi runtime per contenitori, tra cui Docker, containerd, rkt, CRI-O e frakti. Il supporto per molti tipi di runtime del contenitore è basato sull'interfaccia di runtime del contenitore (CRI). L'interfaccia CRI è una progettazione di plug-in che consente al kubelet di comunicare con il runtime del contenitore disponibile.
Il runtime predefinito del contenitore nel servizio Azure Kubernetes è in contenitore, un runtime di contenitori standard del settore.
Interagire con un cluster Kubernetes
Kubernetes fornisce uno strumento da riga di comando denominato kubectl per gestire il cluster. Usare kubectl per inviare comandi al piano di controllo del cluster o recuperare informazioni su tutti gli oggetti Kubernetes tramite il server API.
kubectl usa un file di configurazione che include le informazioni di configurazione seguenti:
- La configurazione Cluster specifica un nome di cluster, le informazioni sul certificato e l'endpoint dell'API del servizio associato al cluster. Questa definizione consente di connettersi da una singola workstation a più cluster.
- La configurazione Utente specifica gli utenti e i relativi livelli di autorizzazione per l'accesso ai cluster configurati.
- La configurazione Contesto raggruppa i cluster e gli utenti usando un nome descrittivo. Ad esempio, è possibile avere "dev-cluster" e "prod-cluster" per identificare i cluster di sviluppo e di produzione.
È possibile configurare kubectl per la connessione a più cluster specificando il contesto corretto come parte della sintassi della riga di comando.
Pod Kubernetes
Un pod rappresenta una singola istanza di un'app in esecuzione in Kubernetes. I carichi di lavoro eseguiti in Kubernetes sono app incluse in contenitori. A differenza di quanto avviene in un ambiente Docker, non è possibile eseguire i contenitori direttamente in Kubernetes. Il contenitore viene inserito in un pacchetto in un oggetto Kubernetes denominato pod. Un pod è l'oggetto più piccolo che è possibile creare in Kubernetes.
Un singolo pod può includere un gruppo di uno o più contenitori. Tuttavia, un pod in genere non contiene multipli della stessa app.
Un pod include informazioni sulla configurazione di archiviazione e di rete condivisa e una specifica su come eseguire i contenitori in pacchetto. Usare i modelli di pod per definire le informazioni sui pod che vengono eseguiti nel cluster. I modelli di pod sono file codificati YAML riutilizzabili e inclusi in altri oggetti per gestire le distribuzioni di pod.
Si supponga, ad esempio, di voler distribuire un sito Web in un cluster Kubernetes. È necessario creare il file di definizione del pod che specifica le immagini del contenitore dell'app e la configurazione. Il file di definizione del pod viene quindi distribuito in Kubernetes.
È improbabile che un'app Web abbia un sito Web come unico componente della soluzione. Un'app Web include in genere un tipo di archivio dati e altri elementi di supporto. I pod Kubernetes possono anche contenere più di un contenitore.
Si supponga che il sito usi un database. Il sito Web è inserito nel contenitore principale e il database è inserito nel contenitore di supporto. Più contenitori comunicano tra loro tramite un ambiente. I contenitori includono servizi per un sistema operativo host, uno stack di rete, uno spazio dei nomi del kernel, una memoria condivisa e un volume di archiviazione. Il pod è l'ambiente sandbox che fornisce tutti questi servizi all'app. Il pod consente anche ai contenitori di condividere l'indirizzo IP assegnato.
Poiché è potenzialmente possibile creare numerosi pod in esecuzione su più nodi, può risultare difficile identificarli. È possibile riconoscere e raggruppare i pod usando le etichette di stringa specificate durante la definizione del pod.
Ciclo di vita di un pod Kubernetes
I pod Kubernetes hanno un ciclo di vita distinto che influisce sulla modalità di distribuzione, esecuzione e aggiornamento dei pod. Si inizia inviando il manifesto YAML del pod al cluster. Dopo l'invio e il salvataggio permanente nel cluster, il file manifesto definisce lo stato desiderato del pod. L'utilità di pianificazione pianifica il pod in un nodo integro con risorse sufficienti per eseguire il pod.
Ecco le fasi del ciclo di vita di un pod:
| Fase | Descrizione |
|---|---|
| In sospeso | Il pod accetta il cluster, ma non tutti i contenitori nel cluster sono configurati o pronti per l'esecuzione. Lo stato In sospeso indica il tempo in cui un pod è in attesa di essere pianificato e il tempo impiegato per scaricare le immagini del contenitore. |
| In esecuzione | Quando tutte le risorse all'interno del pod sono pronte, il pod passa allo stato di esecuzione. |
| Operazione riuscita | Dopo che il pod ha completato l'attività prevista ed è stato eseguito correttamente, il pod passa allo stato completato. |
| Convalida non superata | È possibile che i pod non vengano eseguiti per diverse ragioni. Un contenitore nel pod potrebbe non riuscire, causando la terminazione di tutti gli altri contenitori o forse non è stata trovata un'immagine durante la preparazione dei contenitori pod. In questi casi, è possibile che il pod passi allo stato non riuscito. I pod possono passare a uno stato non riuscito dallo stato in sospeso o in esecuzione. Un errore specifico può anche riportare un pod allo stato in sospeso. |
| Sconosciuto | Se non è possibile determinare lo stato del pod, il pod si trova in uno stato Sconosciuto. |
I pod vengono mantenuti in un cluster fino a quando un controller, il piano di controllo o un utente non li rimuove in modo esplicito. Quando un pod viene eliminato, viene creato un nuovo pod immediatamente dopo. Il nuovo pod è considerato una nuova istanza completamente nuova basata sul manifesto del pod. Non è una copia esatta, quindi differisce dal pod eliminato.
Il cluster non salva lo stato del pod o la configurazione assegnata in modo dinamico. Ad esempio, non salva l'ID o l'indirizzo IP del pod. Questo aspetto influisce sulla modalità di distribuzione dei pod e sulla progettazione delle app. Ad esempio, non sarà possibile fare affidamento sugli indirizzi IP preassegnati per i pod.
Stati del contenitore
Tenere presente che le fasi rappresentano un riepilogo della posizione in cui si trova il pod nel ciclo di vita. Quando si ispeziona un pod, il cluster usa tre stati per tenere traccia dei contenitori all'interno del pod:
| Provincia | Descrizione |
|---|---|
| In attesa | Lo stato predefinito di un contenitore e lo stato in cui si trova il contenitore quando non è in esecuzione o è terminato. |
| In esecuzione | Il contenitore è in esecuzione come previsto senza problemi. |
| Terminato | Il contenitore non è più in esecuzione, perché tutte le attività sono terminate o perché il contenitore non è stato eseguito per qualche motivo. Un motivo e un codice di uscita vengono forniti per il debug di entrambi i casi. |