Concetti di Kubernetes

Distribuire applicazioni su più macchine (utilizzando container distribuiti nei pod)

Monitorare lo stato dei container e riavviare quelli che hanno subito un errore

Aumentare e ridurre i container in base al carico

Aggiornare i container con le nuove versioni

Allocare le risorse tra i container

Bilanciare il traffico tra le macchine

Containerizzato: Kubernetes è uno strumento di orchestrazione dei container. Per utilizzare Kubernetes, devi prima avere le tue applicazioni containerizzate. A seconda del tipo di applicazione, potrebbe trattarsi di un insieme di microservizi, di processi in batch o in altre forme. Quindi, le tue applicazioni possono trarre vantaggio da un flusso di lavoro di Kubernetes che comprende un enorme ecosistema di strumenti, in cui i container possono essere archiviati come immagini in un registro di container, distribuiti in un cluster Kubernetes ed eseguiti su un nodo disponibile. Puoi creare e testare singoli container sul tuo computer locale con Docker o un altro runtime di container prima di distribuirli nel cluster Kubernetes.

Scalabile: se la domanda per le tue applicazioni supera la capacità delle istanze in esecuzione delle stesse, Kubernetes è in grado di aumentare verticalmente. Se necessario, Kubernetes è in grado di stabilire se le applicazioni richiedono più CPU o memoria e rispondere o espandendo automaticamente la capacità disponibile o utilizzando una maggiore capacità esistente. La scalabilità può essere eseguita a livello di pod, se è disponibile una quantità di calcolo sufficiente per eseguire solo più istanze dell’applicazione (scalabilità automatica del pod in orizzontale), o a livello di nodo, se è necessario attivare più nodi per gestire l’aumento della capacità (Cluster Autoscaler o Karpenter). Poiché la capacità non è più necessaria, questi servizi possono eliminare i pod non necessari e chiudere i nodi non necessari.

Disponibile: se un’applicazione o un nodo non sono integri o non sono disponibili, Kubernetes può spostare i carichi di lavoro in esecuzione su un altro nodo disponibile. Puoi forzare il problema semplicemente eliminando un’istanza in esecuzione di un carico di lavoro o di un nodo che esegue i tuoi carichi di lavoro. In conclusione, i carichi di lavoro possono essere trasferiti in altre posizioni se non possono più essere eseguiti dove si trovano.

Dichiarativo: Kubernetes utilizza la riconciliazione attiva per verificare costantemente che lo stato dichiarato per il cluster corrisponda allo stato effettivo. Applicando oggetti Kubernetes a un cluster, in genere tramite file di configurazione in formato YAML, puoi, ad esempio, chiedere di avviare i carichi di lavoro che desideri eseguire sul cluster. Successivamente, puoi modificare le configurazioni per eseguire operazioni quali utilizzare una versione successiva di un container o allocare più memoria. Kubernetes farà ciò che deve fare per stabilire lo stato desiderato. Ciò può includere l’attivazione o la disattivazione dei nodi, l’arresto e il riavvio dei carichi di lavoro o l’estrazione di container aggiornati.

Componibile: poiché un’applicazione è in genere composta da più componenti, è necessario essere in grado di gestire insieme un insieme di questi componenti (spesso rappresentati da più container). Sebbene Docker Compose offra un modo per farlo direttamente con Docker, il comando Kompose di Kubernetes può aiutarti a farlo con Kubernetes. Consultare Translate a Docker Compose File to Kubernetes Resources per un esempio di come eseguire questa operazione.

Estensibile: a differenza del software proprietario, il progetto open source Kubernetes è progettato per consentirti di estendere Kubernetes in qualsiasi modo desideri per soddisfare le tue esigenze. Le API e i file di configurazione sono aperti a modifiche dirette. I terzi sono incoraggiati a scrivere i propri comandi per estendere sia l’infrastruttura che le funzionalità di Kubernetes per gli utenti finali. I webhook consentono di configurare le regole del cluster per applicare le policy e adattarsi alle condizioni mutevoli. Per altre idee su come estendere i cluster Kubernetes, consultare Extending Kubernetes.

Portatile: molte organizzazioni hanno standardizzato le proprie operazioni su Kubernetes perché consente loro di gestire tutte le esigenze applicative nello stesso modo. Gli sviluppatori possono utilizzare le stesse pipeline per creare e archiviare applicazioni containerizzate. Queste applicazioni possono quindi essere distribuite su cluster Kubernetes che vengono eseguiti on-premises, nel cloud, sui terminali dei punti vendita nei ristoranti o su dispositivi IOT distribuiti tra i siti remoti dell’azienda. La sua natura open source consente alle persone di sviluppare queste speciali distribuzioni Kubernetes, insieme agli strumenti necessari per gestirle.

Hardware: se non disponi di hardware disponibile per eseguire Kubernetes in base alle tue esigenze, un provider di servizi cloud come AWS Amazon EKS può farti risparmiare sui costi iniziali. Con Amazon EKS, ciò significa che puoi utilizzare le migliori risorse cloud offerte da AWS, tra cui istanze di computer (Amazon Elastic Compute Cloud), il tuo ambiente privato (Amazon VPC), la gestione centralizzata di identità e permessi (IAM) e lo storage (Amazon EBS). AWS gestisce i computer, le reti, i data center e tutti gli altri componenti fisici necessari per eseguire Kubernetes. Allo stesso modo, non è necessario pianificare il data center per gestire la capacità massima nei giorni con una maggiore richiesta. Per Amazon EKS Anywhere o altri cluster Kubernetes on-premises, sei responsabile della gestione dell’infrastruttura utilizzata nelle implementazioni Kubernetes, ma puoi comunque contare sull’aiuto di AWS per mantenere Kubernetes aggiornato.

Gestione del piano di controllo: Amazon EKS gestisce la sicurezza e la disponibilità del piano di controllo Kubernetes ospitato da AWS, responsabile della pianificazione dei container, della gestione della disponibilità delle applicazioni e di altre attività chiave, così che tu possa concentrarti sui carichi di lavoro delle applicazioni. In caso di guasto del cluster, AWS dovrebbe avere a disposizione i mezzi per ripristinarlo in uno stato di esecuzione. Per Amazon EKS Anywhere, il piano di controllo verrebbe gestito dall’utente stesso.

Upgrade testati: quando aggiorni i tuoi cluster, puoi fare affidamento su Amazon EKS o Amazon EKS Anywhere per fornire versioni testate delle distribuzioni Kubernetes.

Componenti aggiuntivi: esistono centinaia di progetti creati per estendere e utilizzare Kubernetes che puoi aggiungere all’infrastruttura del cluster o utilizzare per facilitare l’esecuzione dei tuoi carichi di lavoro. Invece di creare e gestire per proprio conto questi componenti aggiuntivi, AWS fornisce Componenti aggiuntivi Amazon EKS che puoi utilizzare coi cluster. Amazon EKS Anywhere fornisce pacchetti curati che includono build di molti progetti open source popolari. Quindi non è necessario creare il software o gestire patch di sicurezza, correzioni di bug o aggiornamenti critici per proprio conto. Allo stesso modo, se le impostazioni predefinite soddisfano le tue esigenze, è normale che sia necessaria una configurazione minima di tali componenti aggiuntivi. Consultare Estendere i cluster per i dettagli sull’estensione del cluster con componenti aggiuntivi.

Piano di controllo gestito: AWS assicura che il cluster Amazon EKS sia disponibile e scalabile perché gestisce il piano di controllo per te e lo rende disponibile in tutte le zone di disponibilità AWS.

Gestione dei nodi: invece di aggiungere i nodi manualmente, puoi fare in modo che Amazon EKS crei i nodi in automatico a seconda delle necessità, utilizzando Gruppi di nodi gestiti (vedere Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti) o Karpenter. I gruppi di nodi gestiti presentano integrazioni con Cluster Autoscaling di Kubernetes. Utilizzando gli strumenti di gestione dei nodi, è possibile trarre vantaggio dai risparmi sui costi, come le istanze spot e il consolidamento e la disponibilità dei nodi, utilizzando le funzionalità di pianificazione per impostare la modalità di distribuzione dei carichi di lavoro e la selezione dei nodi.

Rete di cluster: utilizzando i modelli CloudFormation, eksctl configura la rete tra i componenti del piano di controllo e del piano dati (nodo) nel cluster Kubernetes. Inoltre, configura gli endpoint attraverso i quali possono avvenire le comunicazioni interne ed esterne. Per i dettagli, consultare De-mystifying cluster networking for Amazon EKS worker nodes. Le comunicazioni tra i pod in Amazon EKS vengono effettuate utilizzando Pod Identity di Amazon EKS (consultare Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS), che fornisce un mezzo per consentire ai pod di attingere ai metodi cloud AWS per la gestione delle credenziali e delle autorizzazioni.

Componenti aggiuntivi: con Amazon EKS non c’è bisogno di creare e aggiungere componenti software comunemente usati per supportare i cluster Kubernetes. Ad esempio, quando crei un cluster Amazon EKS da Console di gestione AWS, questo aggiunge automaticamente i componenti aggiuntivi Amazon EKS kube-proxy (Gestisci kube-proxy nei cluster Amazon EKS), il plug-in Amazon VPC CNI per Kubernetes (Assegna IPs ai pod con Amazon VPC CNI) e CoreDNS (Gestisci CoredNS per DNS nei cluster Amazon EKS). Consultare Componenti aggiuntivi Amazon EKS per ulteriori elementi aggiuntivi, incluso un elenco di quali sono disponibili.

Comunicazione con i componenti del cluster (server API): il server API (kube-apiserver) espone l’API Kubernetes in modo che le richieste al cluster possano essere effettuate sia dall’interno che dall’esterno del cluster. In altre parole, le richieste di aggiunta o modifica degli oggetti di un cluster (pod, servizi, nodi e così via) possono provenire da comandi esterni, come le richieste di esecuzione da parte di kubectl di eseguire un pod. Allo stesso modo, è possibile effettuare richieste dal server API ai componenti all’interno del cluster, ad esempio una richiesta al servizio kubelet per lo stato di un pod.

Archivia dati sul cluster (archivio di valori delle chiavi etcd): il servizio etcd svolge il ruolo fondamentale di tenere traccia dello stato attuale del cluster. Se il servizio etcd diventasse inaccessibile, non sarebbe possibile aggiornare lo stato del cluster o eseguire query su di esso, anche se i carichi di lavoro continuerebbero a funzionare per un po’. Per questo motivo, i cluster critici in genere dispongono di più istanze di bilanciatore del carico del servizio etcd in esecuzione contemporaneamente ed effettuano backup periodici dell’archivio di valori delle chiavi etcd in caso di perdita o danneggiamento dei dati. Tieni presente che, in Amazon EKS, tutto questo viene gestito automaticamente per impostazione predefinita. Amazon EKS Anywhere fornisce istruzioni per etcd backup and restore. Consulta etcd Data Model per scoprire come etcd gestisce i dati.

Programma i pod ai nodi (Scheduler): le richieste di avvio o arresto di un pod in Kubernetes vengono indirizzate a Kubernetes Scheduler (kube-scheduler). Poiché un cluster può avere più nodi in grado di eseguire il pod, spetta allo Scheduler scegliere su quale nodo (o nodi, nel caso delle repliche) eseguire il pod. Se la capacità disponibile non è sufficiente per eseguire il pod richiesto su un nodo esistente, la richiesta avrà esito negativo, a meno che non siano state prese altre disposizioni. Tali disposizioni potrebbero includere l’abilitazione di servizi come Gruppi di nodi gestiti (Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti) o Karpenter in grado di avviare automaticamente nuovi nodi per gestire i carichi di lavoro.

Mantieni i componenti nello stato desiderato (Gestore di controller): il Gestore controller di Kubernetes viene eseguito come processo daemon (kube-controller-manager) per monitorare lo stato del cluster e apportare modifiche al cluster per ristabilire gli stati previsti. In particolare, esistono diversi controller che controllano diversi oggetti Kubernetes, tra cui statefulset-controller, endpoint-controller, cronjob-controller, node-controller e altri.

Gestisci le risorse cloud (Gestore di controller cloud): le interazioni tra Kubernetes e il provider cloud che esegue le richieste per le risorse del data center sottostanti vengono gestite dal Gestore di controller cloud (cloud-controller-manager). I controller gestiti da Gestore di controller cloud possono includere un controller di percorso (per configurare i percorsi di rete cloud), un controller di servizio (per l’utilizzo dei servizi di bilanciatore del carico nel cloud) e un controller del ciclo di vita dei nodi (per mantenere i nodi sincronizzati con Kubernetes per tutto il loro ciclo di vita).

Gestisci ogni nodo (kubelet): il server API comunica con il servizio kubelet in esecuzione su ciascun nodo per assicurarsi che il nodo sia registrato correttamente e che i pod richiesti dallo Scheduler siano in esecuzione. Il kubelet può leggere i manifest dei pod e configurare volumi di archiviazione o altre funzionalità necessarie ai pod sul sistema locale. Può anche verificare lo stato dei container in esecuzione locale.

Esegui i container su un nodo (runtime del container): il Runtime del container su ciascun nodo gestisce i container richiesti per ogni pod assegnato al nodo. Ciò significa che può estrarre le immagini del container dal registro appropriato, eseguire il container, interromperlo e rispondere alle query sul container. Il runtime predefinito del container è containerd. A partire da Kubernetes 1.24, la speciale integrazione di Docker (dockershim) che poteva essere utilizzata come runtime del container è stata eliminata da Kubernetes. Sebbene sia ancora possibile utilizzare Docker per testare ed eseguire container sul sistema locale, per utilizzare Docker con Kubernetes ora è necessario installare il motore Docker su ogni nodo per utilizzarlo con Kubernetes.

Gestisci la rete tra container (kube-proxy): per supportare la comunicazione tra i pod, Kubernetes utilizza una funzionalità denominata Servizio per configurare le reti pod che tengono traccia degli indirizzi IP e delle porte associate a tali pod. Il servizio kube-proxy viene eseguito su ogni nodo per consentire la comunicazione tra i pod.

Un’immagine di base: un’immagine container di base è un container che viene in genere creato da una versione minima del file system di un sistema operativo (come Red Hat Enterprise Linux o Ubuntu) o da un sistema minimale migliorato per fornire software al fine di eseguire tipi specifici di applicazioni (come app nodejs o python).

Software applicativo: puoi aggiungere il tuo software applicativo al container più o meno nello stesso modo in cui lo aggiungeresti a un sistema Linux. Ad esempio, nel tuo Dockerfile puoi eseguire npm e yarn per installare un’applicazione Java o yum e dnf per installare pacchetti RPM. In altre parole, utilizzando un comando RUN in un Dockerfile, è possibile eseguire qualsiasi comando disponibile nel file system dell’immagine di base per installare software o configurare software all’interno dell’immagine del container risultante.

Istruzioni: il Dockerfile reference descrive le istruzioni che è possibile aggiungere a un Dockerfile durante la configurazione. Queste includono le istruzioni utilizzate per creare ciò che è contenuto nel container stesso (file ADD o COPY dal sistema locale), identificare i comandi da eseguire quando il container viene eseguito (CMD o ENTRYPOINT) e connettere il container al sistema su cui viene eseguito (identificando USER eseguire come, un VOLUME locale da montare o le porte su EXPOSE).

Archiviazione: quando un container in esecuzione viene interrotto ed eliminato, l’archiviazione di dati in quel container scompare, a meno che non si configuri uno spazio di archiviazione più permanente. Kubernetes supporta molti tipi di storage diversi e li riassume sotto il termine Volumi. I tipi di storage includono CephFS, NFS, iSCSI e altri. È anche possibile utilizzare un dispositivo a blocchi locale dal computer locale. Con uno di questi tipi di archiviazione disponibili nel cluster, è possibile montare il volume di archiviazione su un punto di montaggio selezionato nel file system del container. Un volume persistente è quello che continua a esistere dopo l’eliminazione del pod, mentre un volume temporaneo viene eliminato quando il pod viene eliminato. Se l’amministratore del cluster ha creato diverse classi di archiviazione per il cluster, potrebbe essere possibile scegliere gli attributi dello storage da utilizzare, ad esempio se il volume viene eliminato o recuperato dopo l’uso, se si espanderà se è necessario più spazio e anche se soddisfa determinati requisiti di prestazioni.

Segreti: rendendo disponibile Segreti ai container nelle specifiche del pod, puoi fornire le autorizzazioni necessarie a tali container per accedere a file system, database o altre risorse protette. Chiavi, password e token sono tra gli elementi che possono essere archiviati come segreti. L’uso dei segreti consente di non dover memorizzare queste informazioni nelle immagini dei container, ma è sufficiente rendere i segreti disponibili ai container in esecuzione. ConfigMaps sono simili a Segreti. ConfigMap tende a contenere informazioni meno critiche, come coppie chiave-valore per la configurazione di un servizio.

Risorse del container: gli oggetti per un’ulteriore configurazione dei container possono assumere la forma di configurazione delle risorse. Per ogni container, puoi richiedere la quantità di memoria e CPU che può utilizzare, nonché porre limiti alla quantità totale di tali risorse che il container può utilizzare. Per degli esempi, consultare Resource Management for Pods and Containers.

Interruzioni: i pod possono essere interrotti involontariamente (un nodo non funziona) o volontariamente (è necessario un aggiornamento). Configurando un budget per le interruzioni dei pod, puoi esercitare un certo controllo sulla disponibilità dell’applicazione in caso di interruzioni. Per degli esempi, consultare Specifica di un budget di interruzioni per la tua applicazione.

Namespace: Kubernetes offre diversi modi per isolare i componenti e i carichi di lavoro di Kubernetes gli uni dagli altri. L’esecuzione di tutti i pod per una particolare applicazione nello stesso namespace è un modo comune per proteggere e gestire insieme tali pod. Puoi creare i tuoi namespace da utilizzare o scegliere di non indicare un namespace (il che fa sì che Kubernetes utilizzi il namespace default). I componenti del piano di controllo di Kubernetes vengono in genere eseguiti nel namespace kube-system.

Applicazioni stateless: un’applicazione stateless non salva i dati della sessione di un client, quindi un’altra sessione non deve fare riferimento a ciò che è accaduto a una sessione precedente. In questo modo è più semplice sostituire i pod con altri nuovi se non funzionano bene o spostarli senza salvarne lo stato. Se si esegue un’applicazione stateless (come un server Web), è possibile utilizzare un’Implementazione per implementare pod e ReplicaSet. Un ReplicaSet definisce quante istanze di un pod si desidera eseguire contemporaneamente. Sebbene sia possibile eseguire direttamente un ReplicaSet, è comune eseguire le repliche direttamente all’interno di un’Implementazione, per definire quante repliche di un pod devono essere eseguite contemporaneamente.

Applicazioni stateful: un’applicazione stateful è un’applicazione in cui l’identità del pod e l’ordine in cui vengono avviati i pod sono importanti. Queste applicazioni necessitano di uno storage persistente che sia stabile e che debba essere distribuito e scalato in modo coerente. Per distribuire un’applicazione stateful in Kubernetes, puoi utilizzare StatefulSets. Un esempio di applicazione che viene in genere eseguita come StatefulSet è un database. All’interno di uno StatefulSet, è possibile definire le repliche, il pod e i relativi container, i volumi di archiviazione da montare e le posizioni nel contenitore in cui sono archiviati i dati. Consultare Run a Replicated Stateful Application per un esempio di database implementato come ReplicaSet.

Applicazioni per nodo: a volte è necessario eseguire un’applicazione su ogni nodo del cluster Kubernetes. Ad esempio, il tuo data center potrebbe richiedere che ogni computer esegua un’applicazione di monitoraggio o un particolare servizio di accesso remoto. Per Kubernetes, puoi utilizzare un DaemonSet per garantire che l’applicazione selezionata venga eseguita su ogni nodo del cluster.

Applicazioni eseguite fino al completamento: ci sono alcune applicazioni che desideri eseguire per completare un’attività particolare. Ciò potrebbe includerne una che esegue report mensili sullo stato o elimina i vecchi dati. Un oggetto Job può essere utilizzato per configurare un’applicazione per l’avvio e l’esecuzione, quindi uscire al termine dell’attività. Un oggetto CronJob consente di configurare un’applicazione in modo che venga eseguita a un’ora, un minuto, un giorno del mese, un mese o un giorno della settimana specifici, utilizzando una struttura definita dal formato crontab di Linux.

Servizi: poiché un pod può spostarsi su nodi e indirizzi diversi, un altro pod che deve comunicare con il primo pod potrebbe avere difficoltà a localizzarlo. Per risolvere questo problema, Kubernetes ti consente di rappresentare un’applicazione come servizio. Con un servizio, puoi identificare un pod o un set di pod con un nome particolare, quindi indicare quale porta espone il servizio di quell’applicazione dal pod e quali porte potrebbe utilizzare un’altra applicazione per contattare quel servizio. Un altro pod all’interno di un cluster può semplicemente richiedere un servizio per nome e Kubernetes indirizzerà la richiesta alla porta appropriata per un’istanza del pod che esegue quel servizio.

In ingresso: In ingresso è ciò che può rendere disponibili le applicazioni rappresentate dai servizi Kubernetes ai client esterni al cluster. Le funzionalità di base di In ingresso includono un sistema di bilanciatore del carico (gestito da In ingresso), il controller In ingresso e regole per il routing delle richieste dal controller al servizio. Con Kubernetes, puoi scegliere tra diversi controller in ingresso.

Nozioni di base su Amazon EKS: eksctl

Crea un cluster Amazon EKS.

Implementazione di un’applicazione esemplificativa

Organizzazione e monitoraggio delle risorse del cluster