Ciclo di vita e stati dei Pod

I Pod non sono statici: attraversano diverse fasi, proprio come in un viaggio. Comprendere questo «ciclo di vita» è fondamentale per gestire efficacemente le vostre applicazioni in Kubernetes.

Vi aiuta a capire se l'app è integra, si sta avviando o ha riscontrato un problema.

Kubernetes suddivide i Pod in cinque fasi principali. Queste fasi forniscono una panoramica di alto livello dello stato attuale di un Pod:

• Pending: il Pod è stato accettato da Kubernetes, ma i suoi container non sono ancora stati avviati.
• Running: almeno un container nel Pod è in esecuzione o in fase di avvio.
• Succeeded: tutti i container nel Pod sono stati completati correttamente e non verranno riavviati.
• Failed: tutti i container sono terminati e almeno uno ha avuto esito negativo (ad esempio, è terminato con un codice diverso da zero).
• Unknown: non è stato possibile determinare lo stato del Pod, spesso a causa di problemi di comunicazione.

Un Pod si trova nella fase Pending quando è stato accettato dal server API di Kubernetes, ma uno o più container non sono ancora stati creati o configurati.

Tra le cause comuni ci sono:

• L'immagine del container è ancora in fase di download.
• Il cluster non dispone di risorse sufficienti (CPU/memoria) per pianificare il Pod.
• I volumi sono ancora in fase di provisioning o montaggio.

Esaminiamo un esempio. Se provate a distribuire un Pod con un'immagine inesistente, potrebbe rimanere bloccato nello stato «Pending» o mostrare un errore durante il recupero dell'immagine.

Ecco una definizione di esempio per un Pod:

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

Per verificarne lo stato, usereste kubectl get pod. Potreste visualizzare un risultato simile:

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

ErrImagePull indica che non è stato possibile recuperare l'immagine, impedendo al Pod di raggiungere lo stato Running.

La fase Running indica che il Pod è stato associato a un nodo e che tutti i suoi container sono stati creati correttamente. Almeno un container è in esecuzione oppure è in fase di avvio o riavvio.

È importante notare che un Pod in fase Running non significa automaticamente che l'applicazione al suo interno sia integra o completamente funzionante. Significa solo che i container sono attivi.

Questa è una definizione standard di un Pod per un server web Nginx. Dopo averla applicata, il Pod dovrebbe passare rapidamente allo stato 'Running'.

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

Una volta eseguito il deployment, kubectl get pod mostrerebbe:

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

Il valore 1/1 nella colonna READY conferma che un container è pronto su uno definito.

Queste fasi rappresentano gli stati di terminazione di un Pod:

• Succeeded: un Pod entra in questa fase quando tutti i container al suo interno sono terminati correttamente e non verranno riavviati. È tipico dei Pod che eseguono attività singole o processi batch.
• Failed: un Pod si trova nella fase Failed quando tutti i container al suo interno sono terminati e almeno uno di essi è terminato con un errore, ad esempio con un codice di uscita diverso da zero.

Comprendere queste fasi aiuta a diagnosticare il completamento dei job o gli errori dell'applicazione.

La fase Unknown indica che non è stato possibile determinare lo stato del Pod. È una fase rara, ma critica.

Di solito si verifica quando il Kubelet, ovvero l'agente del nodo su cui è in esecuzione il Pod, smette di comunicare con il server API di Kubernetes. La causa potrebbe essere un problema di rete, un arresto anomalo del Kubelet o un problema del nodo stesso.

Sebbene i Pod abbiano fasi complessive, anche i singoli container al loro interno hanno stati più granulari. Questi stati influenzano direttamente la fase complessiva del Pod:

• Waiting: il container è in attesa di essere avviato. Tra i motivi possibili vi sono il download dell'immagine, l'allocazione delle risorse o l'attesa del completamento dei container di inizializzazione.
• Running: il container è in esecuzione attiva senza problemi.
• Terminated: il container ha completato la propria esecuzione. Potrebbe aver avuto successo oppure essere terminato con un errore.

Immagini di aver appena eseguito il deployment di un nuovo Pod. Esegui kubectl get pod my-app e visualizzi il seguente output:

NAME      READY   STATUS     RESTARTS   AGE
my-app    0/1     Pending    0          12s

Qual è il motivo più probabile per cui il Pod my-app si trova nello stato Pending con 0/1 container pronti?

Ha imparato che i Pod Kubernetes attraversano fasi distinte: Pending, Running, Succeeded, Failed e Unknown. Queste fasi forniscono informazioni di alto livello sullo stato operativo di un Pod.

Abbiamo anche esaminato gli stati dei container individuali (Waiting, Running e Terminated), che contribuiscono alla fase complessiva del Pod. Monitorare questi stati con kubectl get pod e kubectl describe pod (che approfondirà più avanti) è fondamentale per comprendere lo stato di salute dell'applicazione.

Ora passeremo ai pattern avanzati per i Pod, esaminando come eseguire più container affiancati all'interno di un singolo Pod usando il pattern sidecar.