PerfectScale
Architettura Kubernetes: i 7 layer che ogni engineer deve conoscere
Fai fatica a fare debug su Kubernetes? Scopri i 7 layer architetturali - nodi, networking, storage e altro - che ti servono per risolvere in modo efficace i problemi di qualsiasi cluster.
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
Kubernetes nasconde benissimo la complessità. È uno dei motivi principali per cui piace così tanto. Interagisci con un'API pulita, definisci ciò che vuoi e tutto funziona.
Finché non funziona più.
Quando qualcosa si rompe, tutta quella complessità nascosta diventa improvvisamente molto concreta. E risolvere il problema significa scavare, layer dopo layer, per capire cosa sta succedendo davvero.
Chiedi a diversi engineer cosa pensano di Kubernetes e sentirai opinioni contrastanti. Alcuni lo adorano e lo considerano essenziale per le applicazioni moderne. Altri lo trovano eccessivamente complicato. E altri ancora lo trattano come uno strumento qualsiasi: utile nelle situazioni giuste, superfluo in altre.
In tutte queste opinioni c'è del vero.
Ma una cosa è chiara: se lavori con infrastrutture moderne, Kubernetes fa probabilmente parte del tuo stack. E quando qualcosa va storto, ti serve un modello mentale di come funziona sotto il cofano.
Questa guida vuole darti esattamente questo: un modo semplice per capire i diversi layer di Kubernetes, così da poter fare troubleshooting in modo più efficace.
Se vuoi una guida dettagliata al troubleshooting per ogni layer, abbiamo anche creato un ebook intitolato The Ultimate Kubernetes Troubleshooting Handbook. È una risorsa da tenere a portata di mano per i problemi reali.
Layer 1: i nodi
Tutto in Kubernetes gira su macchine reali. Possono essere server fisici, istanze cloud o macchine virtuali. In ogni caso, sono le fondamenta.
Ogni nodo esegue un componente chiamato kubelet, che riceve istruzioni dal control plane e si assicura che i container funzionino correttamente. Se kubelet ha problemi, i pod possono bloccarsi e le applicazioni iniziano a dare errori. Potresti vedere alert da strumenti diversi, ma nessuno indica chiaramente la causa alla radice.
È di solito qui che inizia il debugging più approfondito: accedi alla macchina, controlli i log di kubelet, verifichi l'utilizzo del disco, il comportamento della CPU e le impostazioni di sistema. Anche piccole differenze, come il container runtime o il sistema operativo, possono influire sul comportamento.
I servizi Kubernetes gestiti semplificano la gestione dei nodi, ma limitano anche il tuo controllo quando qualcosa si rompe a quel livello.
I nodi determinano inoltre le decisioni di scheduling attraverso label e taint. Quando un nodo diventa unhealthy, tutti i pod che ospita ne risentono. Ecco perché i nodi sono una delle parti più critiche di un cluster.
Layer 2: il networking
Se lavori con Kubernetes da un po', probabilmente hai avuto a che fare con problemi di networking almeno una volta.
Ogni pod riceve un indirizzo IP. I pod possono comunicare direttamente tra loro. I Service forniscono punti di accesso stabili.
Ma l'implementazione effettiva dipende dai plugin CNI come Flannel, Calico o Cilium. Ognuno si comporta in modo diverso e ha i propri limiti.
Inoltre, kube-proxy gestisce l'instradamento del traffico. Se le regole di routing si rompono o diventano obsolete, il traffico può smettere di raggiungere i pod giusti. Può sembrare che la tua applicazione sia rotta, anche se funziona perfettamente.
Il DNS è un altro problema comune. CoreDNS gira all'interno del cluster, quindi se il cluster è sotto pressione, il DNS può smettere di funzionare. I pod non riusciranno a trovare i Service e gli errori non indicheranno chiaramente il DNS come causa.
L'Ingress aggiunge un ulteriore layer per il traffico esterno, e configurarlo può creare confusione. Se aggiungi una service mesh, le cose diventano ancora più complesse.
Quando il networking si rompe, ti ritrovi a tracciare le richieste attraverso più componenti solo per capire dove qualcosa è andato storto.
Layer 3: lo storage
Kubernetes è nato per le applicazioni stateless. Il supporto per lo storage è arrivato dopo, e si nota ancora.
Il sistema utilizza Persistent Volume e Persistent Volume Claim per gestire lo storage. Ma lo storage effettivo può provenire da molte fonti, come dischi cloud, NFS o sistemi distribuiti.
Ogni tipo di storage si comporta in modo diverso e ha i propri problemi.
La Container Storage Interface ha aiutato a standardizzare le cose, ma ha anche aggiunto altri componenti da gestire. Se qualcosa va storto, il mount dei volumi può fallire e le applicazioni potrebbero non avviarsi.
I workloads stateful come i database aggiungono ulteriore complessità. Hanno bisogno di identità e dati stabili, il che rende i deployment più lenti e più delicati.
Molti problemi di storage emergono solo durante i guasti, specialmente quando i workloads si spostano su un altro nodo. E di solito è proprio il momento peggiore perché qualcosa si rompa.
Layer 4: la sicurezza
La sicurezza in Kubernetes non è una singola impostazione. È composta da più parti che lavorano insieme.
RBAC controlla chi può accedere a cosa. Se è configurato male, puoi bloccare gli accessi oppure creare rischi di sicurezza.
I service account danno un'identità alle applicazioni. Vengono usati per accedere ad altri servizi in modo sicuro.
I Secret memorizzano dati sensibili, ma di default non sono completamente sicuri. Molti team usano strumenti aggiuntivi per gestire i secret correttamente.
Ci sono anche regole che controllano come vengono eseguiti i pod, come impedire l'accesso root o limitare i privilegi. Sono importanti, ma possono rompere i workloads se non configurate con attenzione.
Le network policy controllano la comunicazione tra i pod, ma funzionano solo se il tuo plugin di rete le supporta.
Proprio perché ci sono così tante parti in gioco, gestire la sicurezza in Kubernetes può sembrare un'impresa.
Layer 5: l'allocazione delle risorse
Questo layer decide quanta CPU e memoria usano le tue applicazioni.
Definisci request e limit. Le request aiutano Kubernetes a decidere dove posizionare i pod. I limit controllano quanto possono consumare.
Se richiedi troppo, sprechi risorse e fai lievitare i costi. Se richiedi troppo poco, la tua applicazione potrebbe rallentare o andare in crash.
C'è una differenza importante da tenere a mente. La CPU può essere limitata e rallentata. La memoria no. Se un container supera i limiti di memoria, viene terminato immediatamente.
Impostazioni come ResourceQuota e LimitRange aiutano a controllare l'utilizzo a un livello superiore. Kubernetes assegna anche priority class che decidono quali pod vengono rimossi per primi quando il cluster è sotto pressione.
L'allocazione delle risorse influisce direttamente sia sulle prestazioni sia sui costi, e per questo è molto importante.
Layer 6: l'orchestrazione
È soprattutto per questo che Kubernetes è conosciuto.
Definisci lo stato che vuoi e Kubernetes continua a cercare di raggiungerlo. Controlla e corregge costantemente le differenze.
Diversi tipi di workload come Deployment, StatefulSet e Job coprono casi d'uso diversi.
Lo scheduler decide dove eseguire i pod in base a molti fattori, come risorse, regole e vincoli.
I rolling update funzionano bene per le applicazioni semplici, ma i workloads più complessi richiedono una gestione attenta.
Le custom resource e gli operator estendono ulteriormente Kubernetes. Ti permettono di gestire sistemi complessi, ma aggiungono anche altri componenti da mantenere.
Per fare debug dei problemi a questo livello, devi capire cosa sta cercando di fare Kubernetes, non solo ciò che vedi.
Layer 7: l'autoscaling
L'autoscaling aiuta Kubernetes ad adattare le risorse in base alla domanda.
L'Horizontal Pod Autoscaler aumenta o diminuisce il numero di pod. Il Vertical Pod Autoscaler modifica le impostazioni delle risorse. Il Cluster Autoscaler gestisce i nodi.
Questi strumenti sono potenti, ma non sono perfetti.
Scalare richiede tempo, soprattutto quando servono nuovi nodi. Picchi di traffico improvvisi possono comunque causare problemi.
Strumenti di scaling diversi possono anche entrare in conflitto tra loro se usati insieme.
Ci sono approcci più recenti come lo scaling basato su eventi e lo scaling predittivo, ma comportano anch'essi delle sfide.
Perché l'autoscaling funzioni bene, ti servono buone metriche e una chiara comprensione dei tuoi workloads.
Conclusione
Questi layer - nodi, networking, storage, sicurezza, allocazione delle risorse, orchestrazione e autoscaling - aiutano a spiegare come funziona Kubernetes.
Ma nella realtà non sono separati. Si sovrappongono continuamente. È per questo che i problemi sono difficili da diagnosticare.
Un problema di networking può sembrare un problema di storage. Un problema di risorse può innescare problemi di scaling. Una modifica alla sicurezza può interrompere le comunicazioni.
Non puoi concentrarti su un solo layer. Ti serve una comprensione complessiva dell'intero sistema.
Anche con gli strumenti moderni, questa comprensione è importante. Altrimenti passerai il tempo a sistemare i sintomi invece del problema reale.
Abbiamo raccolto tutto ciò che abbiamo imparato in The Ultimate Kubernetes Troubleshooting Handbook. Copre problemi reali, procedure di debugging ed esempi pratici.
Se ti aiuta a risolvere anche un solo problema più velocemente, ne vale la pena. E speriamo che i tuoi cluster filino lisci.