Quando un container fallisce e un Pod muore , possono esserci diverse ragioni, e queste sono sempre descritte all’interno dei termination messages.

Questo tipo di dato è fondamentale per comprendere quali siano gli eventi che hanno portato all’arresto dell’applicazione e quindi per permettere ai team di indagare sull’origine della causa.

Di default, questi messaggi risiedono nella cartella /dev/termination-log: questo vuol dire che, quando il Pod termina, il campo relativo al suo status viene aggiornato con le informazioni che riguardano le cause di arresto, come mostrato di seguito.

Creando un Pod come il seguente, facciamo sì che il container attenda 30 secondi prima di stampare in output il messaggio “Good night!”, riportandone il contenuto nel path di default:

apiVersion: v1
kind: Pod
metadata:
 name: demo
spec:
 containers:
 - name: demo
 image: centos
 command: ["/bin/sh"]
 args: ["-c", "sleep 30 && echo Good night! > /dev/termination-log"]

Questo messaggio è recuperabile sfruttando il campo status del template del Pod, in questo modo: utilizzando il comando kubectl get pod e recuperando l’output in formato yaml, dovremmo ottenere un risultato simile al seguente, dove il campo status contiene al suo interno una serie di dettagli sullo stato dei container e della causa del loro arresto:

kubectl get pod demo --output=yaml

>>>
apiVersion: v1
kind: Pod
...
 lastState:
 terminated:
 containerID: ...
 exitCode: 0
 finishedAt: ...
 message: | #################
 Good night! ################
 ...

Si è già detto che Kubernetes recupera i messaggi di arresto dal file /dev/termination-log; qualora volessimo però specificare un path diverso, potremmo utilizzare il campo terminateMessagePath all’interno delle specifiche del container.

Kubernetes utilizzerà il contenuto del file specificato per popolare il messaggio di stato del container sia in caso di successo che di errore.

Il messaggio di terminazione deve essere un breve stato finale, ad esempio un messaggio di errore rispetto a dei test o delle asserzioni che controllano lo stato di integrità del pod; dev’essere breve perché kubelet tronca i messaggi più lunghi di 4096 byte.

Un’altra nota interessante è che non è possibile impostare il percorso del messaggio di terminazione dopo l’avvio di un pod : questo deve essere impostato prima del suo avvio, altrimenti verrà utilizzato quello di default.

apiVersion: v1
kind: Pod
metadata:
 name: demo
spec:
 containers:
 - name: demo
 image: centos
 terminationMessagePath: "/tmp/my-custom-log-file"

Risorse utili

• Documentazione ufficiale