Le 46 migliori domande e risposte per colloqui su Kubernetes nel 2026

Domande di base per colloqui su Kubernetes

Partiamo ora con le domande di base. Queste domande coprono le conoscenze fondamentali necessarie per comprendere e lavorare con Kubernetes. 

1. Che cos'è un Pod in Kubernetes?

Un Pod è la più piccola unità distribuibile in Kubernetes. Rappresenta uno o più container in esecuzione in un ambiente condiviso. I container all'interno di un Pod condividono risorse di rete e storage.

Ecco un semplice file YAML di definizione di un Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

2. A cosa serve kubectl?

Kubectl è il principale strumento da CLI per gestire le risorse di Kubernetes e interagire con il cluster. Ecco alcuni comandi kubectl comuni che dovresti conoscere:

kubectl get pods 				 # elenca tutti i Pod
kubectl get services 			 # elenca tutti i Service
kubectl logs <pod-name> 	  	 # visualizza i log di un Pod
kubectl exec -it <pod-name> – /bin/sh # apre una shell dentro un Pod

3. Che cos'è un Deployment in Kubernetes?

Un Deployment in Kubernetes è un'astrazione di più alto livello che gestisce il ciclo di vita dei Pod. Garantisce che il numero desiderato di repliche sia attivo e fornisce funzionalità come rolling update, rollback e self-healing. 

Ecco come appare un semplice file YAML di definizione di un Deployment: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

4. Che cos'è un Service in Kubernetes e perché serve?

Un Service in Kubernetes espone un gruppo di Pod e consente la comunicazione tra e verso di essi. 

Poiché i Pod sono effimeri, i loro IP possono cambiare, il che significa che l'applicazione che comunica con i Pod dovrebbe aggiornare a sua volta l'indirizzo IP. I Service forniscono quindi un endpoint di rete stabile con un IP fisso.

Una semplice definizione YAML di Service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Il Service qui sopra inoltra il traffico ai Pod che hanno l'etichetta app: my-app.

5. Quali tipi di Service sono disponibili in Kubernetes?

Kubernetes mette a disposizione quattro principali tipi di Service, ognuno con uno scopo di rete diverso:

• ClusterIP (predefinito): consente la comunicazione interna tra Pod. Accessibile solo dall'interno del cluster.
• NodePort: espone il Service su una porta statica di ogni nodo, rendendolo accessibile dall'esterno del cluster.
• LoadBalancer: utilizza un load balancer esterno del cloud provider. Il Service diventa accessibile tramite un IP pubblico.
• ExternalName: mappa un Service di Kubernetes a un hostname esterno. 

6. Qual è il ruolo di ConfigMap e Secret in Kubernetes?

Le ConfigMap archiviano dati di configurazione non sensibili, mentre i Secret archiviano dati sensibili come chiavi API e password.

Usare i Secret evita di inserire informazioni riservate nel codice dell'applicazione. Le ConfigMap, invece, ti permettono di rendere le applicazioni più configurabili, perché questi valori possono essere modificati facilmente e non serve conservarli nel codice.

Esempio di definizione YAML di ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Esempio di definizione YAML di Secret (con dati codificati in base64 [non cifrati]):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" codificata in Base64

7. Cosa sono i Namespace in Kubernetes?

Un Namespace è un cluster virtuale all'interno di un cluster Kubernetes. Aiuta a organizzare i carichi in ambienti multi-tenant isolando le risorse all'interno del cluster.

Di seguito trovi un breve snippet che mostra come creare un Namespace tramite kubectl e come creare e ottenere Pod in quel Namespace:

# crea un namespace chiamato “dev”
kubectl create namespace dev

# crea un Pod in quel namespace
kubectl run nginx --image=nginx --namespace=dev

# ottieni i Pod in quel namespace
kubectl get pods --namespace=dev

8. Cosa sono le Label e i Selector in Kubernetes?

Le Label sono coppie chiave/valore associate agli oggetti (ad es. i Pod). Aiutano a organizzare gli oggetti Kubernetes. I Selector filtrano le risorse in base alle Label. 

Ecco un esempio di Pod con le etichette environment: production e app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Ora potresti usare il seguente label selector per recuperare tutti i Pod con l'etichetta environment: pod assegnata:

kubectl get pods -l environment=production

9. Cosa sono i Persistent Volume (PV) e i Persistent Volume Claim (PVC)?

I Persistent Volume (PV) forniscono uno storage che persiste oltre il ciclo di vita dei Pod. Il PV è una porzione di storage nel cluster predisposta da un amministratore o provisionata dinamicamente usando le StorageClass.

Un Persistent Volume Claim (PVC) è una richiesta di storage da parte di un utente. 

Ecco un esempio di definizione YAML di PV e PVC: 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Domande intermedie per colloqui su Kubernetes

Ora che hai fatto pratica con le basi, possiamo passare a domande di livello intermedio. A questo livello è essenziale comprendere concetti come networking, sicurezza, gestione delle risorse e troubleshooting.

10. Che cos'è il networking in Kubernetes e come funziona?

Il networking in Kubernetes consente la comunicazione tra Pod, Service e client esterni. Segue una struttura di rete piatta, il che significa che, per impostazione predefinita, tutti i Pod possono comunicare tra loro.  

Concetti chiave di rete in Kubernetes:

• Comunicazione pod-to-pod: ogni Pod riceve un IP univoco e può comunicare all'interno del cluster. 
• Comunicazione service-to-pod: i Service forniscono un endpoint di rete stabile per un gruppo di Pod, dato che i Pod sono effimeri. Ogni Pod riceve un nuovo IP ogni volta che viene creato.
• Ingress controller: gestiscono il traffico HTTP/HTTPS esterno.
• Network policy: definiscono regole per limitare o consentire la comunicazione tra Pod.

11. Che cos'è l'RBAC (Role-Based Access Control) in Kubernetes?

L'RBAC è un meccanismo di sicurezza che limita utenti e servizi in base ai loro permessi. Si compone di:

• Role e ClusterRole: definiscono le azioni consentite sulle risorse.
• RoleBinding e ClusterRoleBinding: assegnano i ruoli a utenti o service account.

Il seguente YAML mostra un esempio di ruolo che consente solo accesso in sola lettura ai Pod:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Questo ruolo pod-reader può ora essere associato a un utente tramite RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

12. Come funziona l'autoscaling in Kubernetes?

Kubernetes fornisce tre tipi di autoscaling per ottimizzare l'uso delle risorse:

1. Horizontal Pod Autoscaler (HPA): regola il numero di Pod in base a CPU, memoria o metriche personalizzate.
2. Vertical Pod Autoscaler (VPA): regola le richieste di CPU e memoria dei singoli Pod.
3. Cluster Autoscaler: regola il numero di worker node nel cluster in base alle necessità di risorse.

Puoi creare un HPA usando kubectl:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Il comando sopra crea un HPA per un Deployment chiamato nginx e cerca di mantenere l'utilizzo medio della CPU tra tutti i Pod al 50%, con un numero minimo di repliche pari a 1 e massimo pari a 10.

13. Come si esegue il debug dei Pod in Kubernetes?

Quando i Pod falliscono, Kubernetes offre diversi modi per fare debug:

• Usa kubectl logs per controllare i log dei container alla ricerca di errori.
• Usa kubectl describe pod per ispezionare eventi e cambi di stato recenti.
• Usa kubectl exec per aprire una shell interattiva e indagare dall'interno del container.
• Usa kubectl get pods --field-selector=status.phase=Failed per elencare tutti i Pod in errore.

# ottieni i log di uno specifico Pod
kubectl get logs <pod-name>

# descrivi il Pod e controlla gli eventi
kubectl describe pod <pod-name>

# apri una shell interattiva dentro il Pod
kubectl exec -it <pod-name> – /bin/sh

# controlla tutti i pod in errore
kubectl get pods --field-selector=status.phase=Failed

Questi comandi aiutano a individuare errori di configurazione, vincoli di risorse o errori applicativi.

14. Come si eseguono rolling update e rollback in Kubernetes?

I Deployment di Kubernetes supportano i rolling update per evitare downtime. Puoi eseguire un rolling update modificando un Deployment o impostando esplicitamente la sua immagine su una nuova versione con:

kubectl set image deployment/my-deployment nginx=nginx:1.21

Poi puoi controllare lo stato del Deployment:

kubectl rollout status deployment my-deployment

Se vuoi tornare alla versione precedente, esegui:

kubectl rollout undo deployment my-deployment

15. Che cos'è un Ingress in Kubernetes e come funziona?

Un Ingress è un oggetto API che gestisce l'accesso HTTP/HTTPS esterno ai Service all'interno di un cluster Kubernetes.  Consente di instradare le richieste in base a hostname e path, agendo da reverse proxy per più applicazioni.

Esempio di definizione YAML di Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

16. Che cos'è la Kubernetes Gateway API e in cosa differisce da Ingress?

La Gateway API è l'evoluzione moderna del networking in Kubernetes che punta a sostituire l'Ingress standard. Mentre Ingress è stato progettato per un routing HTTP semplice, con la crescita della complessità dei cluster è diventato limitante e frammentato.

La Gateway API migliora la situazione grazie a:

• Design orientato ai ruoli: separa la definizione del Gateway (gestito dagli ingegneri dell'infrastruttura) dalle Route (gestite dagli sviluppatori applicativi).
• Supporto migliore: ha supporto nativo per funzionalità avanzate di traffico come traffic splitting (A/B testing), header matching e networking multi-cluster senza dover ricorrere ad annotazioni personalizzate complesse.

17. Come gestisce Kubernetes i limiti e le richieste di risorse?

Kubernetes ti consente di impostare richieste e limiti di risorse per i Pod per garantire un'allocazione equa ed evitare l'uso eccessivo delle risorse del cluster.

• Le richieste sono la quantità minima di CPU e memoria di cui un Pod ha bisogno. Sono assegnate in modo permanente a un Pod. 
• I limiti sono il massimo che un Pod può usare. Non sono assegnati al Pod, ma se necessita di più risorse può crescere fino al raggiungimento del limite.

Esempio YAML di Pod che imposta richieste e limiti di risorse:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

18. Cosa succede se un Pod ha bisogno di più risorse rispetto ai limiti assegnati?

Se il consumo di memoria di un Pod supera il limite assegnato, Kubernetes termina immediatamente il container con un errore out of memory (OOM). Il container viene riavviato se è definita una restart policy.

Diversamente dalla memoria, se un Pod supera il limite di CPU assegnato non viene ucciso. Kubernetes limita (throttling) l'uso della CPU, causando un rallentamento dell'applicazione.

19. Cosa sono gli init container e quando andrebbero usati?

Gli init container sono container speciali che vengono eseguiti prima dei container principali. Aiutano a preparare l'ambiente controllando le dipendenze, caricando file di configurazione o predisponendo i dati.

Un esempio può essere un init container che attende che un database sia attivo:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

20. Come gestisce Kubernetes le interruzioni dei Pod e l'alta disponibilità?

Kubernetes garantisce l'alta disponibilità tramite Pod Disruption Budget (PDB), regole di anti-affinity e meccanismi di self-healing. Ecco come funzionano:

• Pod Disruption Budget (PDB): assicura che un numero minimo di Pod rimanga disponibile durante interruzioni volontarie (ad es. aggiornamenti del cluster con riduzione di nodi).
• Affinità e anti-affinità dei Pod: controlla quali Pod possono essere pianificati insieme o separatamente.
• Selector di nodo e Taint/Toleration: controllano come i carichi vengono distribuiti tra i nodi.

Ecco un esempio YAML di PDB che garantisce che almeno due Pod rimangano in esecuzione durante le interruzioni:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Domande avanzate per colloqui su Kubernetes

Questa sezione copre domande avanzate, con focus su applicazioni stateful, gestione multi-cluster, sicurezza, ottimizzazione delle prestazioni e troubleshooting. Se ti candidi per una posizione senior, assicurati di leggerle.

21. Cosa sono gli StatefulSet e in cosa differiscono dai Deployment?

Uno StatefulSet è usato per applicazioni stateful che richiedono identità di rete stabili, storage persistente e ordine nel deployment. A differenza dei Deployment, gli StatefulSet garantiscono che:

• I Pod abbiano identità di rete stabili e uniche, con nomi del tipo pod-0, pod-1, ecc.
• I Pod vengano creati, aggiornati e rimossi in ordine.
• Ogni Pod mantenga uno storage persistente tra i riavvii. Lo storage persistente è definito nella YAML dello StatefulSet.

22. Che cos'è un service mesh e perché si usa in Kubernetes?

Un service mesh gestisce la comunicazione tra servizi, fornendo:

• Gestione del traffico (bilanciamento, canary deployment).
• Sicurezza (mTLS tra servizi).
• Osservabilità (tracing, metriche, logging)

Tutte queste funzionalità sono incluse nel livello infrastrutturale, quindi non servono modifiche al codice. 

Soluzioni service mesh popolari per Kubernetes includono: Istio, Linkerd e Consul.

23. Come si mette in sicurezza un cluster Kubernetes?

Segui il modello di sicurezza 4C per mettere in sicurezza un cluster Kubernetes:

1. Sicurezza del cloud provider: usa ruoli IAM e regole firewall.
2. Sicurezza del cluster: abilita RBAC, audit log e sicurezza dell'API server.
3. Sicurezza dei container: analizza le immagini e usa utenti non-root.
4. Sicurezza del codice: implementa la gestione dei secret e usa le network policy.

24. Cosa sono Taint e Toleration in Kubernetes?

Taint e Toleration controllano dove vengono eseguiti i Pod:

• Taint: contrassegnano nodi per rifiutare i Pod.
• Toleration: consentono ai Pod di ignorare determinati Taint.

Ecco un esempio per applicare un taint a un nodo affinché accetti solo carichi specifici:

kubectl taint nodes node1 key1=value1:NoSchedule

Questo significa che nessun Pod può essere pianificato su node1 finché non ha la Toleration richiesta.

Una Toleration si aggiunge nella sezione PodSpec come segue:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

Il Pod potrà essere pianificato su node1.

25. Cosa sono i sidecar container di Kubernetes e come si usano?

Un sidecar container gira insieme al container principale dell'applicazione nello stesso Pod. È comunemente usato per:

• Logging e monitoraggio (ad es. raccolta dei log con Fluentd).
• Proxy di sicurezza (ad es. esecuzione del proxy Envoy di Istio per il service mesh).
• Gestione della configurazione (ad es. sincronizzazione delle impostazioni applicative).

Esempio di sidecar per l'elaborazione dei log:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

Il sidecar esegue Fluentd, che raccoglie i log dal container principale tramite un volume condiviso.

26. Cosa sono i Native Sidecar (SidecarContainers) e quale problema risolvono?

Prima di Kubernetes v1.28/1.29, i sidecar erano semplici container che giravano accanto alla tua app. Questo causava una "race condition": se la tua applicazione partiva prima del sidecar (ad es. un proxy di sicurezza o un agente di log), l'app poteva andare in crash o perdere dati perché l'helper non era ancora pronto.

I Native Sidecar risolvono il problema permettendoti di definire i sidecar nella sezione initContainers con restartPolicy: Always.

• Come funziona: Kubernetes li tratta come init container, il che significa che devono avviarsi correttamente prima dell'app principale.
• Il vantaggio: garantisce che proxy di sicurezza o logger siano pienamente attivi prima che la tua applicazione gestisca la prima richiesta.

27. Indica tre cause tipiche di errori dei Pod e come risolverle.

I Pod possono bloccarsi negli stati Pending, CrashLoopBackOff o ImagePullBackOff:

• Pod bloccato in Pending: controlla disponibilità dei nodi e limiti di risorse. Verifica gli eventi del Pod per maggiori informazioni.
• CrashLoopBackOff: indaga i log dell'app e verifica eventuali errori di configurazione.
• ImagePullBackOff: assicurati che il nome dell'immagine e le credenziali di pull siano corrette. Anche in questo caso, controlla gli eventi del Pod per ulteriori dettagli.

Puoi controllare gli eventi del Pod usando il comando describe:

kubectl describe pod <pod-name>

28. Che cos'è un mutating admission webhook in Kubernetes e come funziona?

Un mutating admission webhook consente la modifica in tempo reale degli oggetti Kubernetes prima che vengano applicati al cluster e persistiti. Esegue un admission controller dinamico che intercetta le richieste API prima che gli oggetti vengano salvati in etcd. Può modificare il payload della richiesta inserendo, alterando o rimuovendo campi prima di consentire il proseguimento della richiesta.

Sono comunemente usati per:

• Iniettare sidecar.
• Impostare valori predefiniti per Pod, Deployment o altre risorse.
• Far rispettare le best practice (ad es. assegnare automaticamente limiti di risorse).
• Aggiungere configurazioni di sicurezza (ad es. richiedere label per il tracciamento degli audit).

29. Come si implementano Deployment a zero downtime in Kubernetes?

I Deployment a zero downtime garantiscono che gli aggiornamenti non interrompano il traffico live. Kubernetes lo ottiene tramite:

• Rolling update (predefinito, sostituisce gradualmente i Pod vecchi con quelli nuovi).
• Canary deployment (test con un sottoinsieme di utenti).
• Blue-green deployment (switch tra ambienti di produzione e test).

Le readiness probe aiutano Kubernetes a evitare che il traffico venga inviato a Pod non pronti.

30. Che cosa sono le Custom Resource Definition (CRD) di Kubernetes e quando andrebbero usate?

Una Custom Resource Definition (CRD) estende le API di Kubernetes, consentendo agli utenti di definire e gestire risorse personalizzate. Si usano per casi specifici in cui si vuole continuare a usare l'API di Kubernetes per la gestione di tali risorse, ad esempio:

• Gestione di applicazioni personalizzate (ad es., modelli di machine learning).
• Abilitazione di operator Kubernetes per applicazioni self-healing.

Esempio di definizione YAML di CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Ora potresti, ad esempio, recuperare l'oggetto shirt usando kubectl:

kubectl get shirts

Scopri come sfruttare Docker e Kubernetes per i workflow di machine learning in questo tutorial pratico sulla containerizzazione.

31. Cosa sono i Kubernetes operator e come funzionano?

Un operator Kubernetes estende le funzionalità di Kubernetes automatizzando il deployment, lo scaling e la gestione di applicazioni complesse. È costruito usando CRD e controller personalizzati per gestire la logica specifica dell'applicazione.

Gli operator funzionano definendo risorse personalizzate in Kubernetes e osservando i cambiamenti nel cluster per automatizzare compiti specifici. 

Questi sono i componenti chiave di un operator:

• Custom Resource Definition (CRD): definisce una nuova risorsa API di Kubernetes.
• Controller personalizzato: osserva la CRD e applica logiche di automazione in base allo stato desiderato.
• Reconciliation loop: assicura continuamente che lo stato dell'applicazione combaci con quello atteso.

Domande per colloqui su Kubernetes destinate agli amministratori

Gli amministratori Kubernetes mantengono, mettono in sicurezza e ottimizzano i cluster per carichi di lavoro in produzione. Questa sezione copre domande focalizzate sulla gestione del cluster.

32. Come eseguire backup e ripristino di un cluster etcd in Kubernetes?

Etcd è lo store key-value che contiene l'intero stato del cluster. I backup regolari sono essenziali per evitare perdite di dati.

Puoi creare un backup con il comando seguente:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Se vuoi ripristinare da un backup, puoi eseguire:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

33. Come si aggiorna in sicurezza un cluster Kubernetes?

L'aggiornamento di un cluster Kubernetes è un processo in più fasi che richiede downtime minimo e stabilità del cluster. Gli amministratori dovrebbero seguire un approccio strutturato per prevenire problemi durante l'upgrade:

1. Esegui drain e backup di etcd prima dell'upgrade per poter ripristinare in caso di fallimento.
2. Aggiorna il nodo del control plane.
3. Aggiorna kubelet e kubectl sui nodi del control plane.
4. Aggiorna i worker node uno alla volta. Prima di aggiornare, ogni worker node deve essere messo in drain per prevenire interruzioni dei carichi.
5. Aggiorna gli add-on del cluster (ad es., Ingress controller, strumenti di monitoraggio, …).

34. Come si monitora un cluster Kubernetes?

Gli amministratori devono monitorare CPU, memoria, disco, rete e stato delle applicazioni. Gli strumenti consigliati per questi compiti sono:

• Prometheus + Grafana: raccolta e visualizzazione delle metriche del cluster. Crea alert in tempo reale per essere avvisato in caso di problemi.
• Loki + Fluentd: raccolta e analisi dei log.
• Kubernetes dashboard: monitoraggio del cluster tramite interfaccia grafica.
• Jaeger/OpenTelemetry: tracing distribuito.

35. Come si mette in sicurezza un cluster Kubernetes?

La sicurezza è un aspetto chiave e ogni amministratore dovrebbe seguire le best practice per mettere in sicurezza un cluster Kubernetes:

• Abilita RBAC: limita l'accesso degli utenti usando Role e RoleBinding.
• Pod security admission: usa gli admission controller per far rispettare gli standard di sicurezza dei Pod.
• Applica le NetworkPolicy: limita la comunicazione tra Pod, dato che per impostazione predefinita tutti i Pod possono comunicare tra loro.
• Ruota regolarmente token API e certificati.
• Usa la gestione dei secret: utilizza strumenti come Vault, AWS Secrets Manager, ecc. 

Scopri come Kubernetes viene implementato nel cloud con questa guida all'orchestrazione dei container su AWS Elastic Kubernetes Service (EKS).

36. Come si configura il logging in Kubernetes?

Il logging centralizzato è necessario per il debug e l'audit. Due opzioni di stack per il logging:

• Loki + Fluentd + Grafana (leggero e veloce).
• ELK Stack (Elastic, Logstash, Kibana) (scalabile e di livello enterprise).

37. Come si implementa l'alta disponibilità in Kubernetes?

L'alta disponibilità è essenziale per evitare downtime delle applicazioni in esecuzione nel tuo cluster. Puoi garantirla:

• Usando più nodi di control plane. Più API server prevengono downtime se uno fallisce.
• Abilitando il cluster autoscaler. Aggiunge/rimuove automaticamente nodi in base alla domanda.

38. Come si implementa la multi-tenancy in un cluster Kubernetes?

La multi-tenancy è molto importante quando imposti Kubernetes per la tua azienda. Permette a più team o applicazioni di condividere in sicurezza un cluster senza interferire tra loro.

Esistono due tipi di multi-tenancy:

1. Soft multi-tenancy: usa Namespace, RBAC e NetworkPolicy per isolare a livello di namespace.
2. Hard multi-tenancy: usa virtual cluster o control plane separati per isolare un cluster fisico (ad es. KCP).

39. Come si cifrano i Secret di Kubernetes in etcd?

Etcd memorizza lo stato completo del cluster, quindi lì sono archivate informazioni critiche. 

Per impostazione predefinita, Kubernetes memorizza i Secret non cifrati in etcd, rendendoli vulnerabili a compromissioni. Pertanto, può essere cruciale abilitare la crittografia dei Secret a riposo (at REST) così che i Secret vengano archiviati cifrati. 

Come primo passo, devi creare un file di configurazione per la cifratura e memorizzare in quel file una chiave di cifratura/decifratura:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

La configurazione sopra specifica che Kubernetes userà il provider aescbc per cifrare le risorse Secret, con fallback a identity per i dati non cifrati.

Successivamente, devi adattare il file di configurazione di kube-apiserver, tipicamente in /etc/kubernetes/manifests/kube-apiserver.yaml su un nodo del control plane, includendo il flag -- encryption-provider-config che punta al file di configurazione della cifratura che hai creato:

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Salva le modifiche e riavvia kube-apiserver per applicare la nuova configurazione.

40. Come gestisci le ResourceQuota di Kubernetes in ambienti multi-tenant?

Le ResourceQuota impediscono a un singolo tenant (namespace) di consumare eccessivamente le risorse del cluster, ostacolando gli altri tenant.

Puoi definire ResourceQuota per i namespace per assegnare una determinata quantità di risorse a quello specifico namespace. Gli utenti di quel namespace possono quindi creare risorse che consumano fino ai limiti definiti nella ResourceQuota del namespace.

Esempio di definizione YAML di ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Puoi controllare una ResourceQuota di un namespace con:

kubectl describe resourcequota namespace-quota -n team-a

41. Che cos'è CoreDNS? Come lo si configura e usa?

CoreDNS è il provider DNS predefinito per i cluster Kubernetes. Fornisce service discovery e consente ai Pod di comunicare usando nomi DNS interni al posto degli indirizzi IP.

Funzionalità di CoreDNS:

• Gestisce la risoluzione DNS interna (my-service.default.svc.cluster.local).
• Supporta configurazioni DNS personalizzate.
• Esegue il load balancing delle query DNS tra più Pod.
• Consente la cache per migliorare le prestazioni.

Puoi configurare CoreDNS tramite la ConfigMap presente nel namespace kube-system. Puoi visualizzare le impostazioni correnti con:

kubectl get configmap coredns -n kube-system -o yaml

Aggiorna semplicemente quella ConfigMap e applica le modifiche per adattare la configurazione di CoreDNS.

Domande di colloquio su Kubernetes basate su scenari e problem solving

Gli ingegneri affrontano regolarmente sfide complesse di scalabilità, networking, sicurezza, prestazioni e troubleshooting in ambienti Kubernetes reali, e gli intervistatori lo sanno. Questa sezione presenta domande basate su scenari che mettono alla prova la tua capacità di risolvere problemi pratici.

42. Debug di un'applicazione Kubernetes lenta

“Il tuo team segnala che un'applicazione in esecuzione su Kubernetes è diventata lenta e gli utenti registrano tempi di risposta elevati. Come risolvi il problema?”

Puoi affrontare il problema con i seguenti passaggi:

1. Controlla l'utilizzo delle risorse dei Pod. Aumenta le risorse se sono al limite.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Descrivi il Pod lento per ottenere più informazioni. Cerca throttling delle risorse, conteggi di riavvii o errori delle liveness probe.

kubectl describe pod <pod-name>

3. Controlla i log dei container per errori. Cerca timeout, errori o problemi di connessione.

kubectl logs <pod-name>

4. Verifica la latenza di rete, che può rallentare le applicazioni.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Verifica lo stato dei nodi Kubernetes e controlla un eventuale esaurimento delle risorse sui nodi.

kubectl get nodes
kubectl describe node <node-name>

43. Un server web Nginx è in esecuzione, ma l'URL esposto non si collega

“Hai distribuito un server web Nginx su Kubernetes e il Pod è in esecuzione correttamente, ma l'applicazione non è accessibile tramite l'URL esposto. Cosa puoi fare?”

Passi per affrontare il problema sopra:

1. Verifica che il Pod Nginx sia in esecuzione e in salute.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Controlla il Service e il mapping delle porte. Assicurati che la porta corretta sia esposta e corrisponda alla porta del container del Pod. Verifica che il Service trovi i Pod corretti.

kubectl describe service nginx-service

3. Controlla le NetworkPolicy. Se una network policy blocca il traffico in ingresso, il Service non sarà accessibile.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Verifica la configurazione di Ingress e del DNS esterno.

kubectl describe ingress nginx-ingress

44. Un Deployment Kubernetes fallisce dopo un aggiornamento

“Hai distribuito una nuova versione della tua applicazione, ma non si avvia, causando downtime per gli utenti. Come risolvi il problema?”

Approccio per affrontare il problema:

1. Esegui il rollback alla versione precedente funzionante.

kubectl rollout undo deployment my-app

2. Controlla la cronologia del Deployment e individua cosa è cambiato nella nuova versione.

kubectl rollout history deployment my-app

3. Controlla i log dei nuovi Pod per errori.

kubectl logs -l app=my-app

4. Verifica le readiness e liveness probe.

5. Verifica problemi di pull dell'immagine. A volte la nuova immagine è errata o non disponibile.

45. L'applicazione non riesce a connettersi a un database esterno

“Un microservizio in esecuzione su Kubernetes non riesce a connettersi a un database esterno, ospitato fuori dal cluster. Come risolvi il problema?”

Passi per affrontare il problema:

1. Verifica la connettività esterna dall'interno di un Pod. Controlla se il database è raggiungibile dalla rete del cluster.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Controlla la risoluzione DNS all'interno del Pod. Se fallisce, CoreDNS potrebbe essere configurato in modo errato.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Controlla se esistono network policy che bloccano l'accesso esterno, poiché possono impedire il traffico in uscita.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

46. Le risorse del cluster sono esaurite e i nuovi Pod restano in stato pending

“I nuovi Pod restano nello stato Pending. Analizzando i Pod, vediamo il messaggio “0/3 nodi disponibili: CPU e memoria insufficienti”. Come fai debug e risolvi il problema?”

Passi per affrontare il problema:

1. Controlla la disponibilità di risorse del cluster. Verifica un uso elevato di CPU/memoria che impedisce lo scheduling.

kubectl describe node <node-name>
kubectl top nodes

2. Controlla quali Pod consumano più risorse. Imposta richieste e limiti per assicurarti che non eccedano. Puoi farlo valere anche per tutti i namespace del cluster.

kubectl top pods --all-namespaces

3. Riduci i carichi non essenziali per liberare risorse.

kubectl scale deployment <deployment-name> --replicas=0

4. Aumenta il numero di nodi disponibili per incrementare le risorse del cluster. Puoi anche aggiungere più nodi al cluster autoscaler se è in uso.

Consigli per prepararti a un colloquio su Kubernetes

Dalla mia esperienza con i colloqui su Kubernetes, ho imparato che il successo richiede più che memorizzare concetti. Devi saper applicare le conoscenze in scenari reali, fare troubleshooting in modo efficiente e spiegare chiaramente le tue soluzioni.

Se vuoi avere successo nei colloqui su Kubernetes, segui i consigli qui sotto:

1. Padroneggia i concetti base di Kubernetes. Assicurati di capire Pod, Deployment, Service, Persistent Volume, ConfigMap, Secret, ecc.
2. Fai esperienza pratica con Kubernetes. Quando mi preparavo ai colloqui, ho scoperto che creare un mio cluster Minikube e distribuire microservizi mi aiutava a consolidare la comprensione. Puoi anche usare un servizio Kubernetes gestito da un cloud provider per fare pratica su scala.
3. Impara a fare debug dei problemi di Kubernetes, perché il troubleshooting è una parte significativa del lavoro reale con Kubernetes. Probabilmente passerai la maggior parte del tempo a fare troubleshooting delle applicazioni.
• Problemi tipici includono Pod bloccati, guasti di rete, volume persistente che non si monta correttamente e guasti dei nodi.
4. Comprendi il networking e il bilanciamento del carico in Kubernetes. Concentrati su come è implementata la rete, come comunicano i Pod, quali tipi di Service esistono e come esporre le applicazioni.
5. Sappi come scalare e ottimizzare i carichi su Kubernetes. Gli intervistatori chiedono spesso strategie di scaling e ottimizzazione dei costi. Sii competente con HPA, cluster autoscaler, richieste e limiti di risorse. 
6. Comprendi le best practice di sicurezza in Kubernetes. Familiarizza con RBAC, security context dei Pod, network policy e gestione dei secret.
7. Studia l'architettura e gli internals di Kubernetes. Conosci i componenti del control plane e come interagiscono kubelet e il container runtime.

Combinando conoscenza teorica con pratica sul campo e imparando dal troubleshooting reale, affronterai al meglio qualsiasi colloquio su Kubernetes!

Conclusione

Kubernetes è un sistema di orchestrazione dei container potente ma complesso. Affrontare colloqui su Kubernetes richiede una profonda comprensione teorica e capacità di risoluzione di problemi reali. Che tu sia un junior in cerca del primo impiego o un senior puntando a ruoli più avanzati, la preparazione è sempre fondamentale.

Non posso sottolineare abbastanza quanto sia importante la pratica. Ti aiuta a trovare più rapidamente i problemi nelle applicazioni e a diventare più sicuro delle tue capacità.

Se vuoi rafforzare le basi, ti consiglio vivamente di esplorare corsi come Containerization and Virtualization Concepts per costruire solide fondamenta, seguiti da Introduction to Kubernetes per fare esperienza pratica con Kubernetes. Quando ti sentirai pronto, puoi valutare una certificazione Kubernetes per dimostrare le tue competenze. 

Ti auguro il meglio per i tuoi colloqui!