Domande e risposte per il colloquio su Kubernetes: 26 domande con comandi

I colloqui su Kubernetes passano dal vocabolario (pod, deployment, service) alle operazioni (cosa succede quando un pod va in crash, come si fa il debug di un rollout bloccato) e alla progettazione (come gestiresti un'applicazione in modo sicuro). Agli intervistatori piacciono i comandi e i sintomi, quindi esercitati a dire cosa digiteresti davvero e cosa ti aspetteresti di vedere.

Qui sotto ci sono 26 domande con risposte, raggruppate per argomento. Sostituisci gli esempi con la tua esperienza diretta sul cluster, dove puoi.

Architettura e oggetti

1. Cos'è Kubernetes?

Un sistema open source per eseguire e gestire container su un cluster di macchine. Dichiari lo stato che desideri, ad esempio tre copie di un servizio, e Kubernetes continua a lavorare per mantenerlo.

2. Quali sono i componenti principali di un cluster?

Il control plane comprende l'API server (la porta d'ingresso), etcd (l'archivio dati), lo scheduler (che sceglie un nodo per ogni pod) e il controller manager (che esegue i control loop). Ogni nodo worker esegue il kubelet (che avvia i pod), un container runtime e kube-proxy (che gestisce il networking dei service).

3. Cos'è un pod?

L'unità distribuibile più piccola. Contiene uno o più container che condividono il namespace di rete e lo storage. La maggior parte dei pod ha un container principale, mentre i container aggiuntivi sono sidecar o init container.

4. Qual è la differenza tra un Deployment, un ReplicaSet e uno StatefulSet?

Un ReplicaSet mantiene in esecuzione un certo numero di pod identici. Un Deployment gestisce i ReplicaSet e ti offre rolling update e rollback. Uno StatefulSet è per le applicazioni stateful: i pod hanno nomi stabili, storage stabile e avvio e arresto ordinati.

5. Cos'è un DaemonSet? Un Job? Un CronJob?

Un DaemonSet esegue un pod per nodo, per agenti come i collector di log. Un Job esegue un'attività fino al completamento. Un CronJob esegue Job secondo una pianificazione.

6. Cosa sono le label, i selector e le annotation?

Le label sono coppie chiave-valore sugli oggetti, e i selector selezionano gli oggetti in base alle label. I Service trovano i pod in questo modo, e i Deployment trovano i loro ReplicaSet. Anche le annotation contengono dati chiave-valore, ma servono per metadati non identificativi usati dagli strumenti.

7. Cos'è un namespace?

Un modo per dividere un cluster in gruppi virtuali, di solito per team o ambiente. I namespace delimitano i nomi, e puoi applicare quote di risorse e regole di accesso per namespace. Da soli non costituiscono un confine di sicurezza solido.

Networking

8. Quali sono i tipi di Service?

9. Cos'è un Ingress?

Un oggetto che instrada il traffico HTTP e HTTPS esterno verso i service in base a host e path, con un ingress controller che fa il lavoro. La più recente Gateway API è un successore più espressivo.

10. Come si trovano i pod tra loro?

Tramite i Service e il DNS del cluster. Un service chiamato api nel namespace shop è raggiungibile come api.shop.svc.cluster.local, oppure semplicemente api dall'interno dello stesso namespace.

11. Cos'è una NetworkPolicy?

Un insieme di regole che controlla quali pod possono comunicare con quali. Per impostazione predefinita tutti i pod possono raggiungersi a vicenda. Con le policy (e un plugin di rete che le applica), puoi limitare il traffico, ad esempio consentendo solo ai pod dell'API di raggiungere il database.

Configurazione e storage

12. Qual è la differenza tra un ConfigMap e un Secret?

Entrambi contengono configurazione iniettata come variabili d'ambiente o file. I Secret sono pensati per i dati sensibili, ma per impostazione predefinita sono solo codificati in base64, non cifrati. Attiva la cifratura at rest, limita l'accesso con RBAC e valuta un secrets manager esterno.

13. Cosa sono i PersistentVolume e i PersistentVolumeClaim?

Un PersistentVolume è una porzione di storage nel cluster. Un PersistentVolumeClaim è la richiesta di storage di un pod. Una StorageClass permette a Kubernetes di provisionare i volumi automaticamente. I dati nel filesystem normale di un container spariscono quando il pod viene sostituito.

14. Cosa sono le request e i limit?

Le request sono le risorse che lo scheduler riserva per un container. I limit sono il massimo che può usare. Superare un limite di memoria fa terminare il container (OOMKilled), mentre superare un limite di CPU causa throttling.

Affidabilità e aggiornamenti

15. Cosa sono le probe di liveness, readiness e startup?

La liveness verifica se il container deve essere riavviato. La readiness verifica se deve ricevere traffico. La startup dà tempo alle applicazioni che si avviano lentamente prima che partano le altre probe. Un errore comune è una liveness probe che dipende da un database, che può riavviare ogni pod quando il database è inattivo.

16. Come funziona un rolling update?

Il Deployment crea nuovi pod e rimuove gradualmente quelli vecchi, controllato da maxSurge e maxUnavailable. Le readiness probe decidono quando un nuovo pod è considerato pronto. Se qualcosa va storto, kubectl rollout undo torna alla revisione precedente.

17. Come funziona l'autoscaling?

L'Horizontal Pod Autoscaler modifica il numero di pod in base a metriche come la CPU. Il Vertical Pod Autoscaler regola le richieste e i limiti. Il cluster autoscaler aggiunge o rimuove nodi quando i pod non possono essere schedulati o i nodi sono sottoutilizzati.

18. Come mantieni disponibile un'app durante la manutenzione di un nodo?

Esegui diverse repliche, distribuiscile su più nodi o zone e imposta un PodDisruptionBudget in modo che le espulsioni volontarie mantengano un numero minimo in esecuzione. Svuota i nodi con kubectl drain.

Risoluzione dei problemi

19. Un pod è in CrashLoopBackOff. Cosa fai?

Il container si avvia e poi esce ripetutamente. Esegui kubectl logs <pod> --previous per vedere perché è fallito, kubectl describe pod per eventi, codici di uscita e fallimenti delle probe, e controlla la configurazione, i secret mancanti e i limiti delle risorse.

20. Un pod è bloccato in Pending. Cosa controlli?

kubectl describe pod mostra perché lo scheduler non è riuscito a posizionarlo: CPU o memoria insufficienti su qualsiasi nodo, node selector o taint che non corrispondono, o una volume claim non associata.

21. Un pod è OOMKilled. Cosa fai?

Ha superato il suo limite di memoria. Controlla l'andamento dell'utilizzo, verifica se c'è un leak o se il limite è semplicemente troppo basso, e aumenta il limite o correggi l'app. Imposta le richieste vicine all'utilizzo reale così che la schedulazione sia realistica.

22. Un servizio non è raggiungibile. Come lo debugghi?

1. Controlla che i pod siano in esecuzione e pronti.
2. Controlla che il selector del servizio corrisponda alle etichette dei pod (kubectl get endpoints).
3. Testa dall'interno del cluster con un pod temporaneo.
4. Controlla la porta, la target port e l'indirizzo di ascolto del container.
5. Controlla le network policy, poi l'ingress e il DNS.

Sicurezza e operazioni

23. Come funziona il RBAC?

I Role definiscono i permessi sulle risorse, e i binding li concedono a utenti, gruppi o service account. Usa Role con namespace quando possibile, evita cluster-admin e assegna a ogni workload il proprio service account con i permessi minimi di cui ha bisogno.

24. Come proteggi un cluster?

Usa il RBAC con il minimo privilegio, limita l'accesso alle API, scansiona le immagini, esegui i container come non-root con un filesystem di sola lettura quando possibile, applica le network policy, cifra i secret, mantieni Kubernetes aggiornato e verifica l'attività.

25. Cos'è Helm?

Un package manager per Kubernetes. Un chart è un insieme di manifest templatizzati, e una release è un'istanza installata con i propri valori. Ti aiuta a riutilizzare e versionare i deployment tra ambienti diversi. Kustomize è un altro approccio che applica patch a manifest semplici.

26. Come distribuiresti un'app web su Kubernetes in modo sicuro?

"Un Deployment con almeno tre repliche distribuite tra le zone, richieste e limiti impostati, readiness e liveness probe, un Service e un Ingress con TLS, la configurazione in ConfigMap e Secret, un HPA e un PodDisruptionBudget. Distribuisci tramite una pipeline con rolling update e un rollback facile, e monitora il tasso di errore e la latenza durante il rilascio."

Comandi da conoscere

Come prepararti

Avvia un piccolo cluster in locale con kind o minikube e rompi le cose di proposito: un tag di immagine sbagliato, una probe che fallisce, un limite di memoria troppo basso. Esercitati a leggere l'output di describe e logs. Prepara un incidente reale che hai gestito e cosa hai cambiato in seguito. Per esercitarti sul design, consulta la nostra guida al system design, e per i temi cloud la guida ai colloqui AWS.

Di' ad alta voce i tuoi passaggi di debug, perché agli intervistatori interessa l'ordine dei tuoi controlli. Un colloquio simulato con una trascrizione ti mostrerà dove hai saltato un passaggio. Rispetta le regole del datore di lavoro sugli strumenti di AI in qualsiasi colloquio dal vivo.