Cos'è l'architettura Kubernetes? Importanza + Best Practice

Kubernetes ha registrato un'enorme crescita nella sua adozione dal 2014. Ispirato dalla soluzione di gestione dei cluster interni di Google, Borg, Kubernetes semplifica la distribuzione e l'amministrazione delle tue applicazioni. Come tutti i software di orchestrazione dei container , Kubernetes sta diventando popolare tra i professionisti IT perché è sicuro e semplice. Tuttavia, come con ogni strumento, riconoscere come la sua architettura ti aiuta a usarlo in modo più efficace.

Scopriamo le basi dell'architettura Kubernetes, iniziando da cos'è, cosa fa e perché è importante.

Google ha creato il sistema di gestione dei container Kubernetes adattabile, che gestisce le applicazioni containerizzate in molte impostazioni. Aiuta ad automatizzare la distribuzione di applicazioni containerizzate, apportare modifiche e ridimensionare queste applicazioni.

Tuttavia, Kubernetes non è solo un orchestratore di container . Allo stesso modo, le app desktop funzionano su MacOS, Windows o Linux; è il sistema operativo per le applicazioni native del cloud perché funge da piattaforma cloud per tali programmi.

Cos'è un contenitore?

I contenitori sono un approccio standard per la creazione di pacchetti di applicazioni e le relative dipendenze in modo che le applicazioni possano essere eseguite facilmente in ambienti di runtime. Utilizzando i contenitori, puoi adottare misure essenziali per ridurre i tempi di distribuzione e aumentare l'affidabilità dell'applicazione impacchettando il codice, le dipendenze e le configurazioni di un'app in un singolo blocco predefinito di facile utilizzo.

Il numero di contenitori nelle applicazioni aziendali può diventare ingestibile. Per ottenere il massimo dai tuoi container, Kubernetes ti aiuta a orchestrarli.

A cosa serve Kubernetes?

Kubernetes è una piattaforma incredibilmente adattabile ed espandibile per l'esecuzione di carichi di lavoro dei container. La piattaforma Kubernetes non solo fornisce l'ambiente per creare applicazioni cloud-native, ma aiuta anche a gestire e automatizzare le loro distribuzioni.

Mira a sollevare gli operatori e gli sviluppatori delle applicazioni dallo sforzo di coordinare l'infrastruttura di elaborazione, rete e archiviazione sottostante, consentendo loro di concentrarsi esclusivamente sui processi incentrati sui contenitori per il funzionamento self-service. Gli sviluppatori possono anche creare procedure di distribuzione e gestione specializzate, insieme a livelli più elevati di automazione per le applicazioni costituite da più contenitori.

Kubernetes è in grado di gestire tutti i carichi di lavoro back-end significativi, incluse applicazioni monolitiche, programmi stateless o stateful, microservizi, servizi, processi batch e tutto il resto.

Kubernetes viene spesso scelto per i seguenti vantaggi.

• L'infrastruttura di Kubernetes è superiore a quella di molte tecnologie DevOps.
• Kubernetes scompone i container in componenti più piccoli per una gestione precisa.
• Kubernetes distribuisce gli aggiornamenti software in modo rapido e regolare.
• Kubernetes fornisce una piattaforma per lo sviluppo di app native del cloud.

Architettura e componenti di Kubernetes

L'architettura di base di Kubernetes comprende molti componenti, noti anche come componenti K8s, quindi prima di iniziare subito, è importante ricordare i seguenti concetti.

• L'architettura Kubernetes di base è costituita da un piano di controllo che gestisce i nodi e i nodi di lavoro che eseguono le app containerizzate.
• Mentre il piano di controllo gestisce l'esecuzione e la comunicazione, i nodi di lavoro eseguono effettivamente questi contenitori.
• Un cluster Kubernetes è un gruppo di nodi e ogni cluster ha almeno un nodo di lavoro.

Diagramma dell'architettura Kubernetes

Piano di controllo Kubernetes

Il piano di controllo è il centro del sistema nervoso centrale della progettazione del cluster Kubernetes e ospita i componenti di controllo del cluster. Registra inoltre la configurazione e lo stato di tutti gli oggetti Kubernetes nel cluster.

Il piano di controllo Kubernetes mantiene una comunicazione regolare con le unità di calcolo per garantire che il cluster funzioni come previsto. I controller supervisionano gli stati degli oggetti e rendono gli oggetti di sistema fisici, osservati o correnti per adattarli allo stato o alle specifiche desiderate in risposta alle modifiche del cluster.

Il piano di controllo è costituito da diversi elementi essenziali, tra cui il server API (Application Programming Interface), lo scheduler, il controller manager e etcd. Questi componenti fondamentali di Kubernetes garantiscono che i container vengano eseguiti con le risorse appropriate. Questi componenti possono funzionare tutti su un singolo nodo primario, ma molte aziende li duplicano su numerosi nodi per un'elevata disponibilità.

1. Server dell'API Kubernetes

Il server API Kubernetes è il front-end del piano di controllo Kubernetes. Facilita gli aggiornamenti, il ridimensionamento, la configurazione dei dati e altri tipi di orchestrazione del ciclo di vita offrendo la gestione delle API per varie applicazioni. Poiché il server API è il gateway, gli utenti devono potervi accedere dall'esterno del cluster. In questo caso, il server API è un tunnel verso pod, servizi e nodi. Gli utenti si autenticano tramite il server API.

2. Pianificatore Kubernetes

Il kube-scheduler registra le statistiche sull'utilizzo delle risorse per ogni nodo di elaborazione, valuta se un cluster è integro e decide se e dove devono essere distribuiti i nuovi container. Lo scheduler valuta l'integrità complessiva del cluster e le richieste di risorse del pod, come l'unità di elaborazione centrale (CPU) o la memoria. Quindi sceglie un nodo di elaborazione appropriato e pianifica l'attività, il pod o il servizio, considerando i vincoli o le garanzie delle risorse, la località dei dati, i requisiti di qualità del servizio, l'anti-affinità o gli standard di affinità.

3. Gestore controller Kubernetes

In un ambiente Kubernetes, più controller regolano gli stati degli endpoint (pod e servizi), token e account di servizio (spazi dei nomi), nodi e replica (scalabilità automatica). Il kube-controller manager, spesso noto come cloud controller manager o semplicemente controller, è un daemon che gestisce il cluster Kubernetes svolgendo varie funzioni del controller.

Il controller monitora gli oggetti nel cluster durante l'esecuzione dei cicli di controllo principali di Kubernetes. Li monitora per i loro stati desiderati ed esistenti tramite il server API. Se gli stati correnti e previsti degli oggetti gestiti non corrispondono, il controller intraprende un'azione correttiva per avvicinare lo stato dell'oggetto allo stato desiderato. Il controller Kubernetes gestisce anche le attività essenziali del ciclo di vita.

4. ecc

etcd è un database archivio chiave-valore distribuito e tollerante agli errori che conserva i dati di configurazione e le informazioni sullo stato del cluster. Sebbene etcd possa essere configurato in modo indipendente, spesso funge da parte del piano di controllo Kubernetes.

L'algoritmo di consenso raft viene utilizzato per mantenere lo stato del cluster in etcd. Ciò aiuta a gestire un problema tipico nel contesto delle macchine a stati replicati e richiede che molti server concordino sui valori. Raft stabilisce tre ruoli: leader, candidato e seguace e crea consenso attraverso il voto per un leader.

Di conseguenza, etcd è l'unica fonte di verità (SSOT) per tutti i componenti del cluster Kubernetes, che risponde alle query del piano di controllo e raccoglie informazioni diverse sullo stato di container, nodi e pod. etcd viene utilizzato anche per archiviare informazioni di configurazione come ConfigMap, sottoreti, segreti e dati sullo stato del cluster.

Nodi di lavoro Kubernetes

I nodi di lavoro sono sistemi che eseguono i contenitori gestiti dal piano di controllo. Il kubelet, il controller principale di Kubernetes, viene eseguito su ciascun nodo come agente per l'interazione con il piano di controllo. Inoltre, ogni nodo esegue un motore di runtime del contenitore, come Docker o rkt. Sul nodo vengono eseguiti anche altri componenti per il monitoraggio, la registrazione, l'individuazione dei servizi e gli extra facoltativi.

Alcuni componenti chiave dell'architettura del cluster Kubernetes sono i seguenti.

Nodi

Un cluster Kubernetes deve avere almeno un nodo di elaborazione, ma può averne molti di più a seconda dei requisiti di capacità. Poiché i pod sono coordinati e pianificati per l'esecuzione sui nodi, sono necessari ulteriori nodi per aumentare la capacità del cluster. I nodi svolgono il lavoro di un cluster Kubernetes. Collegano applicazioni e risorse di rete, di calcolo e di archiviazione.

I nodi nei data center possono essere macchine virtuali (VM) native del cloud o server bare metal.

Motore di runtime del contenitore

Ogni nodo di elaborazione utilizza un motore di runtime del contenitore per operare e gestire i cicli di vita del contenitore. Kubernetes supporta runtime conformi all'iniziativa del contenitore aperto come Docker, CRI-O e rkt.

Servizio Kubelet

Un kubelet è incluso in ogni nodo di calcolo. È un agente che comunica con il piano di controllo per garantire che i contenitori in un pod funzionino. Quando il piano di controllo richiede l'esecuzione di un'azione specifica in un nodo, il kubelet ottiene le specifiche del pod tramite il server API e funziona. Si assicura quindi che i relativi contenitori siano in buono stato di funzionamento.

Servizio proxy Kube

Ogni nodo di calcolo ha un proxy di rete noto come kube-proxy, che aiuta i servizi di rete Kubernetes. Per gestire le connessioni di rete all'interno e all'esterno del cluster, il kube-proxy inoltra il traffico o dipende dal livello di filtraggio dei pacchetti del sistema operativo.

Il processo kube-proxy opera su ciascun nodo per garantire che i servizi siano disponibili per altre parti e per far fronte a specifiche sottoreti dell'host. Funge da proxy di rete e servizio di bilanciamento del carico sul suo nodo, gestendo il routing di rete per il traffico UDP (user datagram protocol) e il traffico TCP (transmission control protocol). Il kube-proxy, in realtà, instrada il traffico per tutti gli endpoint del servizio.

Baccelli

Finora, abbiamo coperto le idee relative all'infrastruttura e all'interno. I pod, tuttavia, sono fondamentali per Kubernetes poiché sono i principali componenti rivolti verso l'esterno con cui interagiscono gli sviluppatori.

Un pod è l'unità più semplice nel modello di contenitore Kubernetes, che rappresenta una singola istanza di un'applicazione. Ogni pod comprende un contenitore o più contenitori strettamente correlati che si incastrano logicamente tra loro ed eseguono le regole che governano la funzione del contenitore.

I pod hanno una durata limitata e alla fine muoiono dopo essere stati aggiornati o ridimensionati. Sebbene effimeri, eseguono applicazioni stateful connettendosi allo storage persistente.

I pod possono anche ridimensionarsi orizzontalmente, il che significa che possono aumentare o diminuire il numero di istanze operative. Sono anche in grado di eseguire aggiornamenti continui e distribuzioni canary.

I pod operano insieme sui nodi, quindi condividono contenuto e spazio di archiviazione e possono comunicare con altri pod tramite localhost. I contenitori possono estendersi su più computer, così come i pod. Un singolo nodo può gestire diversi pod, ognuno dei quali raccoglie numerosi container.

Il pod è l'unità di gestione centrale nell'ecosistema Kubernetes e funge da confine logico per i container che condividono risorse e contesto. Il metodo di raggruppamento dei pod, che consente a diversi processi dipendenti di operare contemporaneamente, mitiga le differenze tra virtualizzazione e containerizzazione.

Altri componenti dell'architettura Kubernetes

Kubernetes mantiene i contenitori di un'applicazione ma può anche gestire i dati dell'applicazione associati in un cluster. Gli utenti di Kubernetes possono richiedere risorse di archiviazione senza comprendere l'infrastruttura di archiviazione sottostante.

Un volume Kubernetes è una directory in cui un pod può accedere e archiviare i dati. Il tipo di volume determina il contenuto del volume, come è stato creato e il supporto che lo supporta. I volumi persistenti (PV) sono risorse di archiviazione specifiche del cluster spesso fornite da un amministratore. I PV possono anche sopravvivere a un dato pod.

Kubernetes dipende dalle immagini del contenitore , che sono memorizzate in un registro del contenitore . Potrebbe trattarsi di un registro di terze parti o di uno creato dall'organizzazione.

Gli spazi dei nomi sono cluster virtuali che esistono all'interno di un cluster fisico. Sono progettati per creare ambienti di lavoro indipendenti per numerosi utenti e team. Inoltre impediscono ai team di interferire tra loro limitando gli oggetti Kubernetes a cui possono accedere. I container Kubernetes all'interno di un pod possono comunicare con altri pod tramite localhost e condividere indirizzi IP e spazi dei nomi di rete.

Kubernetes contro Docker Swarm

Sia Kubernetes che Docker sono piattaforme che forniscono la gestione dei container e il ridimensionamento delle applicazioni. Kubernetes fornisce un'efficace soluzione di gestione dei container, ideale per applicazioni ad alta richiesta con una configurazione complicata. Al contrario, Docker Swarm è progettato per la semplicità, il che lo rende una scelta eccellente per le app essenziali che sono veloci da distribuire e mantenere.

• Docker Swarm è più facile da distribuire e configurare rispetto a Kubernetes.
• Kubernetes offre una scalabilità all-in-one basata sul traffico, mentre Docker Swarm dà priorità alla scalabilità rapida.
• Il bilanciamento automatico del carico è disponibile in Docker Swarm ma non in Kubernetes. Tuttavia, le soluzioni di terze parti possono collegare un bilanciatore del carico esterno a Kubernetes.

Le esigenze della tua azienda determinano lo strumento giusto.

Soluzioni di orchestrazione dei container

I sistemi di orchestrazione dei container consentono agli sviluppatori di avviare diversi container per la distribuzione delle applicazioni. I responsabili IT possono utilizzare queste piattaforme per automatizzare l'amministrazione delle istanze, l'approvvigionamento di host e la connessione dei container.

Di seguito sono riportati alcuni dei migliori strumenti di orchestrazione dei container che facilitano la distribuzione, identificano implementazioni di container non riuscite e gestiscono le configurazioni delle applicazioni.

Best practice e principi di progettazione dell'architettura Kubernetes

L'implementazione di una strategia di piattaforma che tenga conto di sicurezza, governance, monitoraggio, storage, networking, gestione del ciclo di vita dei container e orchestrazione è fondamentale. Tuttavia, Kubernetes è molto difficile da adottare e scalare, in particolare per le aziende che gestiscono sia l'infrastruttura on-premise che quella del cloud pubblico. Per semplificarlo, di seguito sono discusse alcune best practice che devono essere prese in considerazione durante l'architettura dei cluster Kubernetes.

• Assicurati di avere sempre la versione più recente di Kubernetes.
• Investire nella formazione dei team operativi e di sviluppo.
• Stabilire una governance a livello aziendale . Assicurati che i tuoi strumenti e provider siano compatibili con l'orchestrazione Kubernetes.
• Aumenta la sicurezza includendo tecniche di scansione delle immagini nel tuo flusso di lavoro di integrazione e distribuzione continua (CI/CD). Il codice open source scaricato da un repository GitHub deve essere sempre trattato con cautela.
• Implementa il controllo degli accessi in base al ruolo (RBAC) in tutto il cluster. I modelli basati su privilegi minimi e zero trust dovrebbero essere la norma.
• Utilizza solo utenti non root e rendi il file system di sola lettura per proteggere ulteriormente i contenitori.
• Evita i valori predefiniti poiché le dichiarazioni semplici sono meno soggette a errori e comunicano meglio lo scopo.
• Quando si utilizzano immagini Docker Hub di base, prestare attenzione perché potrebbero includere malware o essere piene di codice non necessario. Inizia con un codice snello e pulito e procedi verso l'alto. Le immagini più piccole crescono più rapidamente, occupano meno spazio di archiviazione e estraggono le immagini più velocemente.
• Mantieni i contenitori il più semplici possibile. Un processo per contenitore consente all'agente di orchestrazione di segnalare se tale processo è integro o meno.
• Crash in caso di dubbio. Non riavviare in caso di errore poiché Kubernetes riavvierà un container in errore.
• Sii descrittivo . Le etichette descrittive avvantaggiano gli sviluppatori presenti e futuri.
• Quando si tratta di microservizi, non essere troppo specifico . Ogni funzione all'interno di un componente di codice logico non deve essere il suo microservizio.
• Ove possibile, automatizza . Puoi saltare del tutto le distribuzioni Kubernetes manuali automatizzando il tuo flusso di lavoro CI/CD.
• Utilizzare le sonde di vivacità e prontezza per assistere nella gestione dei cicli di vita dei pod ; in caso contrario, i pod potrebbero essere terminati durante l'inizializzazione o la ricezione delle richieste degli utenti prima che siano pronti.

Considera i tuoi contenitori

Kubernetes, il software di gestione incentrato sui container, è diventato lo standard de facto per l'implementazione e il funzionamento di applicazioni containerizzate a causa dell'ampio utilizzo di container all'interno delle aziende. L'architettura di Kubernetes è semplice e intuitiva. Sebbene offra ai responsabili IT un maggiore controllo sulla loro infrastruttura e sulle prestazioni delle applicazioni, c'è molto da imparare per ottenere il massimo dalla tecnologia.

Incuriosito per esplorare di più l'argomento? Scopri la crescente importanza della containerizzazione nel cloud computing!