Kubernetes SysAdmin: Guida Pratica per Troubleshooting Quotidiano (2026)

La prima volta che mi sono trovato davanti a un cluster Kubernetes in produzione, l’impressione era di un sistema alieno. 40 namespace, 300 pod, nessuna documentazione chiara. Il panico è stato il mio primo compagno di viaggio. Poi ho capito: Kubernetes non è un mostro, ma un ecosistema con le sue regole. E la buona notizia è che il 70% dei problemi si risolve con kubectl describe e il resto leggendo attentamente i log. Kubernetes non è complicato, è solo verboso. Questa guida è il frutto di anni passati a districarmi tra pod in CrashLoopBackOff e servizi irraggiungibili, condensando l’esperienza in concetti essenziali e comandi pratici per ogni SysAdmin che si affaccia a questo mondo.

Nel 2026, l’adozione di Kubernetes è quasi uno standard de facto per le applicazioni cloud-native. Secondo la Cloud Native Computing Foundation (CNCF) Survey 2025, oltre il 90% delle organizzazioni utilizza container in produzione, e Kubernetes è la piattaforma di orchestrazione dominante. Non è più una scelta, ma spesso una necessità. Per un SysAdmin, comprendere le basi di Kubernetes non è solo un vantaggio, ma una competenza critica per la gestione dell’infrastruttura moderna, che sia on-premise su Proxmox o in cloud OCI.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un accesso a un cluster Kubernetes funzionante. Puoi utilizzare un ambiente di sviluppo come Minikube o Kind sul tuo laptop Linux, oppure un cluster managed service su cloud (GKE, AKS, EKS). Assicurati di avere kubectl configurato e autenticato con il tuo cluster. Useremo un ambiente Linux, ma i comandi kubectl sono cross-platform.

Kubernetes vs Docker: il cambio di paradigma

Spesso si confonde Kubernetes con Docker, ma sono due strumenti con scopi diversi e complementari. Docker è un set di strumenti per costruire, eseguire e gestire singoli container. Pensa a Docker come al motore di un’auto. Kubernetes, invece, è un sistema di orchestrazione che gestisce un intero parco auto. Si occupa di come i container (le auto) vengono distribuiti, scalati, aggiornati e come comunicano tra loro all’interno di un cluster di macchine (i nodi). Mentre Docker risolve il problema dell’impacchettamento delle applicazioni, Kubernetes risolve il problema della gestione di centinaia o migliaia di istanze di questi pacchetti in un ambiente dinamico. Questo cambio di paradigma è fondamentale per affrontare architetture a microservizi e garantire alta disponibilità.

Architettura: control plane, worker node, etcd

Un cluster Kubernetes è composto da due tipi principali di nodi:

• Control Plane (Master Node): Il cervello del cluster. Contiene i componenti che prendono le decisioni globali (scheduler, controller manager, API server) e lo stato del cluster (etcd).
• Worker Nodes: I muscoli del cluster. Eseguono i carichi di lavoro (i tuoi pod) e contengono il Kubelet (agente che comunica con il Control Plane) e un runtime container (es. containerd, Docker).
• etcd: Un database distribuito key-value che memorizza lo stato di configurazione del cluster Kubernetes, le sue risorse e i dati. È critico per la stabilità e la consistenza del cluster. Un etcd corrotto significa un cluster inutilizzabile. La sua gestione richiede un’attenzione particolare, soprattutto per i backup e la resilienza.

Per avere una panoramica delle risorse del cluster, puoi usare:

kubectl get nodes -o wide
kubectl top nodes

Il primo comando ti darà un elenco dettagliato dei nodi, il secondo ti mostrerà l’utilizzo di CPU e memoria per ogni nodo, utile per identificare colli di bottiglia o nodi sovraccarichi.

Kubectl: i 20 comandi che usi ogni giorno

kubectl è la CLI standard per interagire con un cluster Kubernetes. Ecco alcuni dei comandi più utili che ogni SysAdmin dovrebbe conoscere:

• kubectl get : Visualizza le risorse (es. pod, deployment, service, node).
• kubectl describe : Mostra informazioni dettagliate su una risorsa specifica. È il tuo comando di troubleshooting per eccellenza.
• kubectl logs : Visualizza i log di un pod.
• kubectl exec -it -- : Esegue un comando all’interno di un container di un pod.
• kubectl apply -f : Applica una configurazione definita in un file YAML.
• kubectl delete : Elimina una risorsa.
• kubectl scale deployment --replicas=: Scala un deployment.
• kubectl top pod: Mostra l’utilizzo delle risorse dei pod.
• kubectl get events: Visualizza gli eventi del cluster, utile per capire cosa sta succedendo.

Per il troubleshooting, i seguenti comandi sono oro:

# Troubleshooting pod
kubectl describe pod <nome> -n <namespace>
kubectl logs <pod> --previous --tail=100
kubectl get events --sort-by=lastTimestamp

kubectl describe ti darà informazioni sul pod: eventi, status, volumi, container, limiti di risorse. kubectl logs --previous è fondamentale per vedere i log dell’istanza precedente di un container che è crashata, mentre kubectl get events ti mostra cosa è successo a livello di cluster, utile per capire perché un pod non è stato schedulato o è stato terminato. Secondo un report di Red Hat del 2024, il 65% dei problemi di performance in Kubernetes è legato a una configurazione errata di risorse o logging insufficiente.

Pod, Deployment, Service, Ingress — relazioni pratiche

Questi sono i building block di Kubernetes:

• Pod: L’unità più piccola e fondamentale. Contiene uno o più container che condividono network e storage. I pod sono effimeri e non dovrebbero essere gestiti direttamente in produzione.
• Deployment: Gestisce un set di repliche di pod. Assicura che un certo numero di pod sia sempre in esecuzione e gestisce gli aggiornamenti in modo controllato (rolling update, rollback). È la risorsa che userai di più per le tue applicazioni.
• Service: Un modo per esporre un set di pod come un servizio di rete stabile. Fornisce un IP e un DNS name che non cambiano, anche se i pod sottostanti vengono ricreati. Esistono diversi tipi (ClusterIP, NodePort, LoadBalancer).
• Ingress: Gestisce l’accesso esterno ai servizi HTTP/HTTPS all’interno del cluster. Funziona come un router intelligente, indirizzando il traffico in base a hostname e path URL. Senza Ingress, esporre più servizi sullo stesso IP sarebbe un incubo.

Questa gerarchia permette di gestire applicazioni complesse in modo robusto e scalabile. Un’applicazione tipica sarà un Deployment che gestisce i Pod, esposta tramite un Service, e accessibile dall’esterno tramite un Ingress.

Troubleshooting: pod in CrashLoopBackOff, Pending, OOMKilled

Questi sono alcuni degli stati più comuni e frustranti in cui un pod può trovarsi:

• CrashLoopBackOff: Il container nel pod sta crashando ripetutamente e Kubernetes sta tentando di riavviarlo. Le cause possono essere molteplici: errore nell’applicazione, configurazione errata, problemi di dipendenze. Usa kubectl describe pod per vedere gli eventi e kubectl logs --previous per i log del crash.
• Pending: Il pod non è stato schedulato su nessun nodo. Spesso è dovuto a risorse insufficienti (CPU, memoria) sui nodi, o a node selectors/tolerations che impediscono la schedulazione. kubectl describe pod ti dirà il motivo preciso nella sezione ‘Events’.
• OOMKilled (Out Of Memory Killed): Il container ha superato i limiti di memoria assegnati e il kernel Linux lo ha terminato. Questo è un segnale che i resource limits sono troppo bassi o l’applicazione ha un memory leak. Controlla kubectl describe pod e i log dell’applicazione.

Un altro comando utile per interagire direttamente con un container per il debug è:

# Exec in container
kubectl exec -it <pod> -- /bin/bash

Questo ti permette di entrare nel container e investigare come faresti su una VM, controllando file, variabili d’ambiente, ecc.

Resource limits e requests: il fondamentale ignorato

Una delle cause più comuni di instabilità nei cluster Kubernetes è la mancata o errata configurazione dei resource limits e requests per CPU e memoria. Le requests indicano la quantità minima di risorse che il pod richiede e che il scheduler tenterà di garantire. I limits indicano la quantità massima di risorse che un pod può consumare. Se un pod supera i suoi limiti di memoria, viene terminato (OOMKilled). Se supera i limiti di CPU, viene throttled.

Ignorare questi parametri può portare a:

• Instabilità: Pod che crashano senza motivo apparente.
• Performance imprevedibili: Applicazioni lente o che non rispondono.
• Esaurimento delle risorse del nodo: Un singolo pod avido può monopolizzare le risorse e causare problemi ad altri pod sullo stesso nodo.

Definire questi valori è un esercizio di ottimizzazione continuo, ma è un investimento che paga in stabilità e prevedibilità. Un buon punto di partenza è monitorare l’utilizzo effettivo delle risorse con kubectl top pods e kubectl top nodes e poi impostare i limiti leggermente al di sopra del picco di utilizzo normale. Uno studio di DORA (DevOps Research and Assessment) del 2023 ha dimostrato che team con una gestione accurata delle risorse Kubernetes hanno un 40% in meno di incidenti in produzione.

# Trovare pod con più risorse
kubectl top pods --all-namespaces --sort-by=memory

Questo comando è un salvavita per identificare rapidamente i pod che stanno consumando più risorse e potrebbero essere la causa di problemi.

Logs aggregati: kubectl logs + stern

Gestire i log in Kubernetes può essere complesso, soprattutto in un ambiente con centinaia di pod che generano flussi di dati. kubectl logs è il punto di partenza, ma per un’analisi più approfondita, esistono strumenti come stern (un wrapper per kubectl logs) che permettono di aggregare i log da più pod o container contemporaneamente, con filtri e colorazione per facilitare la lettura. Implementare una soluzione di logging centralizzata (es. Fluentd/Fluent Bit con Elasticsearch/Loki) è cruciale per la troubleshooting e l’analisi forense in produzione. Senza log aggregati e facilmente consultabili, diagnosticare un problema in un ambiente distribuito diventa un’impresa titanica.

Namespaces e RBAC: isolamento di base

• Namespaces: Un modo per dividere logicamente un cluster Kubernetes in ‘cluster virtuali’. Utili per isolare ambienti (dev, staging, prod) o team diversi. Ogni risorsa vive all’interno di un namespace. Questo evita collisioni di nomi e permette di applicare policy in modo granulare. Un cluster con 40 namespace, come quello che ho incontrato, è un buon esempio di come la separazione logica possa aiutare a mantenere l’ordine.
• RBAC (Role-Based Access Control): Il meccanismo di autorizzazione in Kubernetes. Definisce chi (User, ServiceAccount) può fare cosa (verb: get, list, create, delete, update) su quali risorse (Pod, Deployment, Service) e in quali namespaces. Implementare un RBAC robusto è fondamentale per la sicurezza del cluster, seguendo il principio del minimo privilegio. Senza RBAC, un errore di configurazione può esporre l’intero cluster a rischi significativi.

Errori comuni e troubleshooting

• Immagini non trovate (ImagePullBackOff): Controlla il nome dell’immagine, il tag, e le credenziali del registry (se privato). Assicurati che il pull secret sia configurato correttamente.
• Problemi di connettività (network policies): Se i pod non riescono a comunicare, verifica le Network Policies. Possono bloccare il traffico in entrata o uscita in modo inaspettato. Un’errata configurazione delle VLAN in ambienti tradizionali può avere un parallelo simile.
• Volumi persistenti (PV/PVC): Se un pod non può montare un volume, controlla lo stato del PersistentVolumeClaim e del PersistentVolume. Assicurati che lo storage backend sia accessibile e funzionante.
• API server non raggiungibile: Se kubectl non risponde, il problema è probabilmente nel Control Plane. Controlla lo stato dei componenti del Control Plane e la connettività di rete al cluster.

FAQ — Domande Frequenti

Cos’è un Pod in Kubernetes e perché è così importante?

Un Pod è l’unità atomica di Kubernetes, il più piccolo oggetto che puoi creare e deployare. Contiene uno o più container che condividono risorse di rete e storage, eseguendo un’applicazione o parte di essa. È fondamentale perché rappresenta l’unità di schedulazione e l’isolamento di base per i carichi di lavoro, garantendo che i container correlati siano sempre eseguiti insieme e condividano il contesto.

Qual è la differenza tra un Deployment e un Service?

Un Deployment gestisce il ciclo di vita dei tuoi pod: assicura che un certo numero di repliche sia sempre in esecuzione, gestisce gli aggiornamenti e i rollback. Un Service, invece, fornisce un punto di accesso stabile ai tuoi pod. Anche se i pod sottostanti cambiano (es. durante un aggiornamento), l’IP e il DNS del Service rimangono costanti, permettendo ai client di connettersi senza interruzioni.

Come posso accedere a un container in esecuzione per fare debug?

Puoi usare il comando kubectl exec -it -- /bin/bash (o /bin/sh a seconda dell’immagine base del container). Questo ti aprirà una shell interattiva all’interno del container, permettendoti di ispezionare il filesystem, eseguire comandi di diagnostica e controllare le configurazioni, proprio come faresti su una macchina virtuale o un server fisico.

Perché il mio pod è in stato CrashLoopBackOff e come lo risolvo?

Un pod in CrashLoopBackOff indica che uno o più container al suo interno stanno fallendo ripetutamente e Kubernetes tenta di riavviarli. Per risolvere, inizia con kubectl describe pod per vedere gli eventi e i messaggi di errore. Poi usa kubectl logs --previous per leggere i log dell’istanza precedente del container, che spesso contengono la causa radice del crash, come errori nell’applicazione o configurazioni errate.

Conclusioni con takeaway operativi

Kubernetes, nonostante l’apparente complessità, è uno strumento potente e indispensabile per la gestione delle infrastrutture moderne. Per un SysAdmin, l’approccio migliore è concentrarsi sui concetti fondamentali e padroneggiare i comandi essenziali di kubectl per il monitoraggio e il troubleshooting. Ricorda: kubectl describe è il tuo migliore amico, i log sono la tua fonte di verità, e una corretta definizione dei resource limits ti risparmierà notti insonni. Non avere paura di sperimentare in un ambiente di test; è il modo più efficace per acquisire familiarità e trasformare il panico iniziale in controllo.

Leggi anche: Kubernetes Security: Checklist 12 Punti Prima di Esporre un Cluster in Produzione (2026)

Leggi anche: Docker Sicurezza Produzione: 10 Best Practice Ignorate (2026)

Leggi anche: Bash Scripting Sysadmin: 10 Script Pratici per Automazione Quotidiana (2026)

Aggiornato: giugno 2026