kubectl Avanzato: Comandi Essenziali e Gestione Risorse da CLI per Kubernetes

Gestisci decine di namespace, centinaia di pod e rollout che non rispondono? Il terminale è il tuo migliore alleato, ma solo se usi kubectl nel modo giusto. Noi di Meteora Web lavoriamo ogni giorno su cluster Kubernetes, e abbiamo visto quanto tempo si perde quando manca una strategia chiara sui comandi di base. In questa guida ti portiamo oltre il semplice kubectl get pods: imparerai a interrogare, filtrare, modificare e debug delle risorse con precisione chirurgica.

Il contesto è tutto: kubeconfig, namespace e alias

Prima di lanciare qualsiasi comando, devi sapere su quale cluster e namespace stai operando. L’errore più comune è agire sul cluster sbagliato e modificare risorse in produzione per sbaglio.

Configurazione del contesto

kubectl config gestisce più cluster, utenti e namespace. Comandi indispensabili:

# Mostra il contesto attivo
kubectl config current-context

# Elenca tutti i contesti disponibili
kubectl config get-contexts

# Cambia contesto (es. da staging a produzione)
kubectl config use-context produzione

# Imposta un namespace di default per il contesto attivo
kubectl config set-context --current --namespace=produzione

Noi, di Meteora Web, usiamo sempre kubectl config view per verificare che i certificati e i server endpoint siano corretti, specialmente dopo un cambio di fornitore cloud.

Alias e autocompletamento

Digita meno, fai di più. Configura autocompletamento bash/zsh e crea alias rapidi:

# Autocompletamento per bash
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

# Alias utili
alias k='kubectl'
alias kgp='kubectl get pods'
alias kd='kubectl describe'
alias krm='kubectl delete'
alias ksys='kubectl --namespace=kube-system'

Azioni immediate: Aggiungi questi alias al tuo profilo e abilita l’autocompletamento. Recuperi secondi ogni comando, che diventano ore in un anno.

Query efficaci: selezionare, filtrare, formattare

kubectl get è il comando più usato, ma la maggior parte degli operatori lo usa male. Impariamo a usare label selector, field selector e output personalizzato.

Filtrare con label selector

# Tutti i pod con label app=nginx e ambiente=produzione
kubectl get pods -l app=nginx,env=production

# Pod con label non null (qualsiasi valore)
kubectl get pods -l 'app'

# Pod senza una label specifica
kubectl get pods -l '!tier'

Filtrare per field

I field selector funzionano su proprietà dello stato (es. fase del pod):

# Pod in stato 'Running'
kubectl get pods --field-selector status.phase=Running

# Pod in un nodo specifico
kubectl get pods --field-selector spec.nodeName=worker-2

Output formattato con custom columns e JSONPath

Se hai decine di pod, una tabella standard è inutile. Usa -o custom-columns per estrarre solo ciò che ti serve:

# Mostra pod, namespace, nodo e IP
kubectl get pods -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,NODE:.spec.nodeName,IP:.status.podIP

# Stessa cosa in JSONPath semplice
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}'

Consiglio operativo: Per analisi rapide, usa kubectl get all -A -o wide per vedere lo stato di tutte le risorse in tutti i namespace. Ma attento: su cluster grandi può essere pesante. Meglio limitare con --namespace e -l.

Gestione delle risorse: creare, aggiornare, eliminare con intelligenza

Modificare risorse direttamente da CLI è potente, ma può rompere il cluster se sbagli. Ecco le pratiche che usiamo noi.

Creare risorse con `kubectl apply` vs `create`

apply è dichiarativo: scrivi il manifesto YAML e lo applichi, Kubernetes gestisce lo stato desiderato. create è imperativo: crea la risorsa ma non la aggiorna. Noi usiamo sempre apply per deployment e servizi.

# Creare o aggiornare un deployment
kubectl apply -f deployment.yaml

# Creare una risorsa temporanea per test
kubectl create deployment nginx --image=nginx:1.25 --replicas=3 --dry-run=client -o yaml | kubectl apply -f -

Aggiornare risorse esistenti

Per modifiche rapide (es. cambiare una variabile d'ambiente o una replica):

# Aumentare repliche a 5 (imperativo)
kubectl scale deployment/nginx --replicas=5

# Modificare l'immagine di un deployment
kubectl set image deployment/nginx nginx=nginx:1.26

# Modificare un campo specifico con patch
kubectl patch deployment nginx -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","env":[{"name":"LOG_LEVEL","value":"debug"}]}]}}}}'

Eliminare con cautela

Non usare kubectl delete pod --all in produzione se i pod sono gestiti da ReplicaSet (verranno ricreati). Per eliminare tutto in un namespace:

# Elimina tutte le risorse tranne PersistentVolumeClaim
kubectl delete all --all -n sviluppoo

# Elimina solo pod con label 'batch=true'
kubectl delete pod -l batch=true

Debug avanzato: logs, exec, port-forward e episodi

Quando un pod crasha, devi capire il perché in pochi secondi.

Log interattivi e tail

# Segui i log in tempo reale di un pod con più container
kubectl logs -f pod/web-xxx -c sidecar

# Mostra ultime 50 righe
kubectl logs --tail=50 pod/web-xxx

# Log da un precedente avvio (se il pod è in CrashLoopBackOff)
kubectl logs -p pod/web-xxx

Eseguire comandi dentro il container

# Shell interattiva
kubectl exec -it pod/web-xxx -- /bin/sh

# Esegui un comando singolo e ottieni output
kubectl exec pod/web-xxx -- ls -la /app

Port-forward per test locali

# Espone un servizio su localhost:8080
kubectl port-forward service/web-service 8080:80

Descrivere e ottenere eventi

# Dettaglio completo della risorsa
kubectl describe pod web-xxx

# Eventi recenti del cluster
kubectl get events --sort-by='.lastTimestamp' -n produzione | tail -20

Errori comuni: dimenticare che kubectl logs -p funziona solo se il container è ancora nello stato terminato (non se è stato rimosso). Usa kubectl get events per capire perché un pod non parte.

Gestire ConfigMap e Secret senza rischi

La configurazione sensibile dev'essere gestita con attenzione. kubectl create secret e kubectl create configmap sono i comandi di base, ma attenzione ai valori in chiaro nella history del terminale.

# Creare secret da file (consigliato rispetto a --from-literal)
kubectl create secret generic db-credentials --from-file=username.txt --from-file=password.txt

# Creare configmap da directory di file di configurazione
kubectl create configmap app-config --from-file=config.d/

# Visualizzare secret decodificato (rischioso, ma necessario)
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 --decode

Attenzione: Non eseguire kubectl get secret -o yaml in ambienti condivisi: i dati base64 sono visibili a chiunque abbia accesso al cluster. Usa RBAC per limitare.

Rollout e rollback: gestire le release

Quando aggiorni un deployment, kubectl ti permette di monitorare e annullare le modifiche.

# Verificare lo stato del rollout
kubectl rollout status deployment/nginx

# Storico delle revisioni
kubectl rollout history deployment/nginx

# Rollback all'ultima revisione stabile
kubectl rollout undo deployment/nginx

# Rollback a una revisione specifica (es. revision 3)
kubectl rollout undo deployment/nginx --to-revision=3

Consiglio: Imposta sempre progressDeadlineSeconds nei tuoi deployment per evitare rollout infiniti. Usa kubectl rollout pause/resume per aggiornamenti graduali.

In sintesi — cosa fare adesso

Configura il tuo ambiente: alias, autocompletamento, namespace di default per ogni contesto.
Impara a usare label selector e custom columns: riduci il rumore informativo del 90%.
Preferisci kubectl apply dichiarativo per tutte le risorse di produzione.
Padroneggia i comandi di debug: logs con flag, describe, events. Non perdere tempo a guardare dashboard.
Non esporre segreti in chiaro: usa --from-file e RBAC per limitare la visibilità.

Il terminale è il tuo pannello di controllo più potente. Noi di Meteora Web lo usiamo ogni giorno per gestire cluster Kubernetes su cloud e on-prem. Se vuoi approfondire l’integrazione con CI/CD, dai un’occhiata alla nostra guida su GitHub Actions: automatica deployment di manifesti YAML su Kubernetes.