Che cos'è l'architettura Kubernetes?
Kubernetes è un'architettura che offre un meccanismo debolmente accoppiato per il rilevamento dei servizi in un cluster. Un cluster Kubernetes ha uno o più control plane e uno o più nodi di elaborazione. Nel complesso, il control plane è responsabile della gestione dell'intero cluster, dell'esposizione dell'interfaccia API (Application Program Interface) e della pianificazione dell'avvio e dell'arresto dei nodi di elaborazione in base alla configurazione desiderata. Ciascun nodo di elaborazione esegue un runtime del container come Docker insieme a un agente, kubelet, che comunica con il control plane. Ogni nodo può essere costituito da server bare-metal oppure da macchine virtuali (VM) on-premise o basate su cloud.
Introduzione a vSphere with Tanzu per amministratori vSphere
Perché scegliere la virtualizzazione VMware per Kubernetes e container
Quali sono i componenti dell'architettura Kubernetes?
I componenti principali di un cluster Kubernetes includono:
Nodi: i nodi sono VM o server fisici che ospitano applicazioni containerizzate. Ogni nodo di un cluster può eseguire una o più istanze dell'applicazione. Può essere presente anche un solo nodo, tuttavia un tipico cluster Kubernetes avrà diversi nodi (e i deployment con centinaia o più nodi non sono rari).
Registro delle immagini: le immagini dei container vengono conservate nel registro e trasferite ai nodi dal control plane per l'esecuzione nei pod dei container.
Pod: i pod sono il luogo in cui vengono eseguite le applicazioni containerizzate. Possono includere uno o più container e rappresentano la più piccola unità di deployment per le applicazioni in un cluster Kubernetes.
Che cos'è l'architettura del control plane di Kubernetes?
Per control plane di Kubernetes si intende il control plane di un cluster Kubernetes. I suoi componenti includono:
- kube-apiserver: come suggerisce il nome, il server API espone l'API Kubernetes, che è la centrale per le comunicazioni. Le comunicazioni esterne tramite l'interfaccia della riga di comando (CLI) o altre interfacce utente (UI) passano al kube-apiserver e anche tutte le comunicazioni tra i control plane e i nodi passano attraverso il server API.
- etcd: è l'archivio dei valori chiave in cui si trovano tutti i dati relativi al cluster. etcd è altamente disponibile e coerente poiché tutto l'accesso a etcd avviene tramite il server API. Le informazioni in etcd sono generalmente formattate in YAML (acronimo di "YAML Ain't Markup Language").
- kube-scheduler: quando viene creato un nuovo pod, questo componente lo assegna a un nodo per l'esecuzione in base ai requisiti delle risorse, alle policy e alle specifiche di "affinità" relative alla geolocalizzazione e all'interferenza con altri carichi di lavoro.
- kube-controller-manager: sebbene un cluster Kubernetes disponga di diverse funzioni controller, queste sono tutte compilate in un singolo file binario noto come kube-controller-manager.
Le funzioni di controller incluse in questo processo includono:
- Controller per replica: garantisce la presenza di un numero corretto di pod per ogni pod replicato in esecuzione nel cluster.
- Controller per nodi: monitora lo stato di ciascun nodo e invia una notifica al cluster quando i nodi diventano online o non rispondono.
- Controller per endpoint: collega pod e servizi per popolare l'oggetto endpoint.
- Controller per account di servizio e token: alloca i token di accesso alle API e gli account predefiniti ai nuovi spazi dei nomi nel cluster.
- cloud-controller-manager: se il cluster è parzialmente o interamente basato su cloud, il cloud controller manager collega il cluster all'API del cloud provider. Verranno eseguiti solo i controlli specifici del cloud provider. Il cloud controller manager non è presente sui cluster interamente on-premise. È possibile eseguire più di un cloud controller manager in un cluster per la tolleranza agli errori o per migliorare le prestazioni complessive del cloud.
Gli elementi del cloud controller manager includono:
- Controller per nodi: determina lo stato di un nodo basato su cloud che ha smesso di rispondere, ad esempio se è stato eliminato.
- Controller per percorsi: stabilisce percorsi nell'infrastruttura del cloud provider.
- Controller per servizio: gestisce i sistemi di bilanciamento del carico del cloud provider.
Che cos'è l'architettura di nodi Kubernetes?
I nodi sono le macchine, ossia VM o server fisici, su cui Kubernetes posiziona i pod da eseguire. I componenti di un nodo includono:
kubelet: ogni nodo ha un agente chiamato kubelet. Assicura che il container descritto in PodSpecs sia attivo e funzioni correttamente.
kube-proxy: è un proxy di rete su ciascun nodo che gestisce i nodi di rete e consente la comunicazione dai pod alle sessioni di rete, all'interno o all'esterno del cluster, utilizzando il filtro dei pacchetti del sistema operativo, se disponibile.
container runtime: software responsabile dell'esecuzione delle applicazioni containerizzate. Anche se Docker è il più diffuso, Kubernetes supporta qualsiasi runtime conforme alla propria CRI (Container Runtime Interface).
Quali sono gli altri componenti dell'infrastruttura Kubernetes?
Pod: incapsulando uno (o più) container di applicazioni, i pod sono l'unità di esecuzione più basilare di un'applicazione Kubernetes. Ogni pod contiene il codice e le risorse di storage necessari per l'esecuzione e dispone di un proprio indirizzo IP. I pod includono anche opzioni di configurazione. In genere, un pod contiene uno o più container che sono associati a un'applicazione o a una funzione aziendale e che condividono un insieme di risorse e dati.
Deployment: è un metodo per distribuire pod di applicazioni containerizzate. Uno stato desiderato descritto in un deployment farà sì che i controller modifichino lo stato effettivo del cluster per raggiungere tale stato in modo ordinato. Scopri di più sui deployment Kubernetes.
ReplicaSet: assicura l'esecuzione di un numero specificato di pod identici in un dato momento.
Cluster DNS: serve i record DNS necessari per gestire i servizi Kubernetes.
Monitoraggio delle risorse dei container: acquisisce e registra le metriche dei container in un database centrale.
Quali sono le best practice e i principi di progettazione dell'architettura Kubernetes?
Le best practice di Gartner per i container suggeriscono una strategia per la piattaforma che considera la sicurezza, la governance, il monitoraggio, lo storage, il networking, la gestione del ciclo di vita dei container e l'orchestrazione come Kubernetes.
Di seguito sono riportate alcune best practice per la progettazione dei cluster Kubernetes:
- Assicurarsi di aver eseguito l'aggiornamento alla versione più recente di Kubernetes (1.18 al momento della stesura di questo documento).
- Investire in anticipo nella formazione per i team di sviluppo e delle operation.
- Definire la governance a livello aziendale. Assicurarsi che strumenti e vendor siano allineati e integrati con l'orchestrazione Kubernetes.
- Migliorare la sicurezza integrando i processi di scansione delle immagini come parte del processo CI/CD, scansionando durante le fasi di creazione ed esecuzione. Il codice Open Source estratto da un repository Github deve sempre essere considerato sospetto.
- Adottare il controllo degli accessi basato sul ruolo (RBAC) in tutto il cluster. I modelli zero-trust e con privilegio minimo dovrebbero essere lo standard.
- Proteggere ulteriormente i container utilizzando solo utenti non root e impostando il file system in modalità di sola lettura.
- Evitare l'uso del valore predefinito, poiché le dichiarazioni semplici sono meno soggette a errori e dimostrano l'intento in modo più chiaro.
- Prestare attenzione quando si utilizzano immagini Docker Hub di base, che possono contenere malware o codice non necessario. Iniziare con codice snello e pulito e creare pacchetti a partire da lì. Le immagini di piccole dimensioni vengono create più velocemente, occupano meno spazio su disco e anche i pull delle immagini sono più veloci.
- Utilizzare container semplici. Un singolo processo per container consentirà all'orchestrator di segnalare se tale processo è integro o meno.
- In caso di dubbio, arrestare in modo anomalo. Kubernetes riavvia un container guasto, quindi non riavviare in caso di guasto.
- Essere prolissi nelle descrizioni. Le etichette descrittive aiutano gli sviluppatori attuali e saranno preziose per gli sviluppatori futuri.
- Non creare microservizi troppo granulari. Non tutte le funzioni all'interno di un componente di codice logico devono necessariamente avere un proprio microservizio.
- Adottare l'automazione, dove serve. L'automazione della pipeline CI/CD consente di evitare completamente i deployment manuali di Kubernetes.
- Utilizzare livenessProbe e readinessProbe per gestire i cicli di vita dei pod, altrimenti i pod potrebbero essere terminati durante l'inizializzazione o potrebbero iniziare a ricevere richieste degli utenti prima che siano pronti.
L'architettura Kubernetes è semplice e intuitiva. L'accoppiamento debole tra il control plane e il nodo offre una flessibilità pressoché infinita e la possibilità di scalare orizzontalmente un'applicazione in modo praticamente istantaneo per soddisfare esigenze mutevoli, migrare gli utenti a nuove build e supportare la migrazione da nodi on-premise a nodi basati su cloud oppure tra più cloud per sfruttare le funzionalità desiderate di ciascun cloud provider.
Soluzioni e prodotti correlati
Modernizzazione delle applicazioni con Kubernetes
Sfrutta la possibilità di eseguire in parallelo app tradizionali e moderne.
Horizon Cloud on Microsoft Azure
Ottieni una piattaforma desktop virtuale nativa per il cloud.