Kubernetes Exit Code 143: le 8 cause e come risolverlo

Come eseguire il troubleshooting dell'exit code 143 di Kubernetes

Fare il troubleshooting dell'exit code 143 significa scoprire chi ha inviato SIGTERM e perché. Poiché Kubernetes usa frequentemente questo segnale durante la normale gestione dei workloads, l'exit code da solo non indica un guasto.

Iniziare dallo stato del pod e del container, poi correlare il momento della terminazione con log, eventi, rollout, attività di scaling e operazioni sui nodi. Verificare inoltre che l'applicazione risponda correttamente quando riceve SIGTERM.

Passo 1: ispezionare lo stato del pod

Iniziare controllando lo stato attuale e i dettagli del pod:

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Cercare riavvii del container, condizioni del pod, eventi recenti e informazioni sulla terminazione. kubectl describe pod può anche rivelare probe fallite, attività di eviction, modifiche di scheduling e altri eventi legati all'arresto.

Se il pod è gestito da un Deployment, da uno StatefulSet o da un altro controller, identificare anche il suo owner. Questo aiuta a capire se la terminazione rientrava nella normale attività del controller.

Passo 2: controllare l'exit code del container e il motivo della terminazione

Ispezionare lo stato di terminazione attuale e precedente del container. Per un container riavviato, Kubernetes può conservare dettagli come exit code, motivo, segnale e timestamp:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'

Confermare che l'exit code registrato sia 143. Controllare anche il motivo della terminazione e i timestamp startedAt e finishedAt, che possono essere correlati con gli eventi di Kubernetes e i log applicativi.

Non dare per scontato che l'exit code 143 spieghi di per sé la causa. Indica che il processo è terminato a causa di SIGTERM, ma non quale operazione di Kubernetes o processo esterno ha avviato la terminazione.

Passo 3: esaminare i log del container attuale e precedente

Controllare i log applicativi intorno al momento della terminazione:

kubectl logs <pod-name> -n <namespace>

Se il container è stato riavviato, ispezionare i log dell'istanza precedente del container:

kubectl logs <pod-name> -n <namespace> --previous

Cercare messaggi di arresto, messaggi relativi ai segnali ricevuti, richieste non completate, errori di connessione ed eccezioni applicative. Una sequenza pulita — ricezione di SIGTERM, interruzione del nuovo lavoro, chiusura delle risorse e uscita — indica di solito una terminazione controllata.

Per i pod multi-container, specificare il container pertinente con -c <container-name>.

Passo 4: ispezionare gli eventi di Kubernetes

Gli eventi di Kubernetes possono fornire contesto su quanto accaduto immediatamente prima della terminazione:

kubectl get events -n <namespace> \
  --sort-by=.metadata.creationTimestamp

Cercare messaggi relativi a probe fallite, eviction di pod, riavvii di container, scaling, scheduling o problemi dei nodi. Confrontare i timestamp degli eventi con il timestamp di terminazione del container.

Gli eventi sono utili, ma non costituiscono un audit trail completo. Possono scadere e non tutte le cause di terminazione di un pod generano un evento che spieghi chiaramente perché è stato inviato SIGTERM.

Passo 5: controllare l'attività di Deployment e rollout

Stabilire se il container si è arrestato durante un aggiornamento del Deployment o un'altra modifica del workload:

kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl rollout history deployment/<deployment-name> -n <namespace>

Ispezionare anche i ReplicaSet durante il troubleshooting di un Deployment. La comparsa di un nuovo ReplicaSet intorno al momento della terminazione è un forte indizio che i vecchi pod venivano sostituiti durante un rollout.

Se l'exit code 143 si verifica solo quando vengono distribuite nuove versioni dell'applicazione, di solito fa parte della normale sostituzione dei pod. La domanda successiva è se quei pod si sono arrestati in modo pulito, senza perdere richieste o lavoro.

Passo 6: verificare eventi di scaling, eviction o dei nodi

Verificare se modifiche delle repliche, autoscaling, node drain o operazioni infrastrutturali coincidono con la terminazione. Per i workloads che usano un HorizontalPodAutoscaler, ispezionarne lo stato attuale e il comportamento recente:

kubectl get hpa -n <namespace>
kubectl describe hpa <hpa-name> -n <namespace>

Ispezionare anche il nodo che ospitava il pod:

kubectl describe node <node-name>

Cercare arresti dei nodi, manutenzione, condizioni di pressure, attività dell'autoscaler o eventi legati all'eviction. Se molti pod non correlati terminano all'incirca nello stesso momento, è più probabile un'operazione a livello di nodo o di cluster che un problema specifico dell'applicazione.

Passo 7: determinare se l'applicazione gestisce correttamente SIGTERM

Infine, verificare come il processo principale dell'applicazione risponde a SIGTERM. Di norma dovrebbe smettere di accettare nuovo lavoro, completare o annullare in sicurezza le operazioni attive, scrivere i dati necessari, chiudere le connessioni esterne e terminare prima della scadenza del grace period di terminazione.

Controllare il grace period configurato per il pod:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.terminationGracePeriodSeconds}'

Verificare inoltre che i segnali raggiungano effettivamente l'applicazione. I container che avviano le applicazioni tramite script shell o process manager configurati in modo errato possono interferire con l'inoltro dei segnali quando l'applicazione non è il PID 1.

Se l'arresto controllato richiede sistematicamente più tempo del periodo disponibile, migliorare il percorso di arresto o aumentare terminationGracePeriodSeconds dove opportuno. Testare l'applicazione direttamente con SIGTERM può confermare che il suo signal handler venga eseguito e termini entro i tempi previsti.

Best practice per prevenire l'exit code 143 in Kubernetes {#best-practices-to-prevent-kubernetes-exit-code-143}

Ecco alcuni dei modi per prevenire l'exit code 143 quando si lavora con Kubernetes.

1. Implementare una gestione corretta di SIGTERM

Le applicazioni dovrebbero gestire esplicitamente SIGTERM e avviare un arresto ordinato all'arrivo del segnale. Un servizio dovrebbe smettere di accettare nuovo lavoro, completare o annullare in sicurezza le richieste attive, chiudere le connessioni, svuotare i dati in buffer e quindi terminare.

Assicurarsi che l'applicazione riceva effettivamente il segnale. Script shell wrapper e process manager possono impedire ai segnali di raggiungere l'applicazione se non li inoltrano correttamente. L'uso di exec in uno script di entrypoint può sostituire la shell con il processo dell'applicazione:

exec /app/my-service

In questo modo l'applicazione diventa il PID 1 e i segnali di terminazione del container possono raggiungerla direttamente.

2. Impostare un terminationGracePeriodSeconds adeguato

Impostare terminationGracePeriodSeconds a un valore sufficiente perché l'applicazione completi la normale procedura di arresto. Kubernetes usa 30 secondi per impostazione predefinita, ma potrebbero non bastare per richieste di lunga durata, batch job, consumer di messaggi o applicazioni con operazioni di pulizia consistenti.

Ad esempio:

spec:
  terminationGracePeriodSeconds: 60

Basare il valore sui tempi di arresto osservati, invece di impostare semplicemente un timeout elevato. Le applicazioni dovrebbero comunque terminare il più rapidamente possibile, perché un grace period inutilmente lungo può ritardare rollout, operazioni di scaling e manutenzione dei nodi.

3. Usare un hook preStop quando serve logica di arresto aggiuntiva

Un hook preStop può eseguire logica aggiuntiva prima che il container riceva il normale segnale di arresto. È utile quando l'arresto richiede un comando esplicito, la deregistrazione di un servizio o un'altra operazione esterna al normale handler SIGTERM dell'applicazione.

Ad esempio:

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "/app/prepare-shutdown.sh"]

Mantenere l'hook breve e affidabile. Il suo tempo di esecuzione viene conteggiato nel grace period di terminazione del pod, quindi un hook preStop lento riduce il tempo disponibile per l'arresto dell'applicazione dopo la ricezione di SIGTERM.

4. Fare in modo che i worker in background si arrestino in sicurezza

I worker in background hanno bisogno di una gestione della terminazione tanto quanto i servizi HTTP. Quando un worker riceve SIGTERM, dovrebbe di norma smettere di prendere nuovi job e completare quello corrente, oppure restituire il lavoro incompiuto alla coda usando il meccanismo supportato dal sistema di code.

Evitare di uscire immediatamente mentre un job è elaborato solo in parte. A seconda del workload, questo può causare lavoro perso, elaborazioni duplicate, aggiornamenti del database incompleti o uno stato applicativo incoerente.

Per i job di lunga durata, assicurarsi che il grace period di terminazione sia compatibile con i tempi di elaborazione previsti. Dove i job non possono completarsi in modo affidabile entro quel periodo, progettarli in modo che siano ritentabili o riprendibili.

5. Monitorare l'exit code 143 nel suo contesto

Non impostare alert su ogni occorrenza dell'exit code 143. È atteso durante i rolling deployment, l'eliminazione manuale di pod, le operazioni di scale-down, i node drain e altre attività di routine di Kubernetes.

Correlare invece l'exit code 143 con i tassi di riavvio dei pod, l'attività di deployment, gli eventi di Kubernetes, le operazioni sui nodi, gli errori applicativi e le richieste fallite. Terminazioni SIGTERM ripetute senza un'operazione nota del cluster meritano ulteriori indagini.

Monitorare il contesto circostante rende l'exit code 143 utile come segnale diagnostico. Aiuta a distinguere la normale attività del ciclo di vita da probe fallite, workloads instabili, terminazioni di processo impreviste o modifiche infrastrutturali.

FAQ

L'exit code 143 di Kubernetes è un errore? Di solito no. L'exit code 143 significa che il processo principale del container ha ricevuto SIGTERM e si è arrestato. Kubernetes invia questo segnale durante attività normali come rolling update, eliminazione di pod, scale-down e node drain, quindi il codice da solo non indica un guasto.

Qual è la differenza tra exit code 143 ed exit code 137? L'exit code 143 è 128 + 15 e significa che il processo si è arrestato dopo un SIGTERM, che dà all'applicazione la possibilità di arrestarsi in modo controllato. L'exit code 137 è 128 + 9 e significa SIGKILL, che non può essere intercettato. Può verificarsi quando un container supera il grace period di terminazione o viene terminato per esaurimento della memoria.

Quanto attende Kubernetes prima di inviare SIGKILL? Il grace period di terminazione è di 30 secondi per impostazione predefinita e si imposta con terminationGracePeriodSeconds. Un hook preStop viene eseguito all'interno della stessa finestra, quindi un hook lento lascia all'applicazione meno tempo per gestire SIGTERM.

Come scopro chi ha inviato il SIGTERM? Iniziare con kubectl describe pod e con l'ultimo stato di terminazione del container, poi confrontare i timestamp con gli eventi di Kubernetes, la cronologia dei rollout, l'attività dell'HPA e gli eventi dei nodi. Se nulla nel cluster coincide, controllare i log dell'applicazione e del process manager, perché anche uno script, un supervisor o un sidecar possono inviare SIGTERM.

Dovrei impostare alert sull'exit code 143? No, non su ogni occorrenza. Meglio impostare alert sui pattern, come terminazioni SIGTERM ripetute senza rollout, scaling o operazioni note sui nodi, oppure terminazioni che coincidono con richieste fallite o tassi di riavvio in aumento.

Workloads Kubernetes stabili a ogni terminazione con PerfectScale

L'exit code 143 è di solito il segno di una normale attività del ciclo di vita, ma rollout frequenti, scale-down e cambi di nodo rendono più difficile distinguere le terminazioni di routine dai veri problemi di resilienza. PerfectScale for Kubernetes di DoiT offre un'automazione workload-aware che mette la stabilità al primo posto, mantenendo la salute delle applicazioni al centro di ogni raccomandazione di ottimizzazione. Offre ai team platform, SRE e FinOps una visione unificata di salute, prestazioni e costi del cluster, per individuare i problemi di resilienza e dimensionare correttamente i workloads senza bisogno di monitoraggio manuale e riconfigurazioni continue.

Funzionalità chiave di PerfectScale for Kubernetes:

• Rilevamento dei problemi di resilienza: Podfit offre una visione granulare della salute e dei costi del cluster, dando priorità alle aree che richiedono attenzione e aiutando i team a individuare rapidamente risorse sprecate e problemi di resilienza.
• Right-sizing orientato alla stabilità: il right-sizing context-aware calibra le azioni su baseline di prestazioni, pattern di traffico e criticità di business, così l'ottimizzazione non va mai a scapito della salute delle applicazioni.
• Ottimizzazione autonoma dei workloads: raccomandazioni data-driven e workflow di automazione dimensionano i workloads in modo continuo, eliminando il ciclo costante di riconfigurazioni che sottrae tempo all'engineering.
• Insight sulla configurazione degli autoscaler: raccomandazioni concrete aiutano a migliorare le configurazioni di HPA e KEDA, mentre Infrafit contribuisce a massimizzare l'efficacia degli autoscaler di nodi come Karpenter.
• Visibilità sull'utilizzo dei nodi: Infrafit individua la capacità inutilizzata dei nodi e consiglia i nodi giusti per i workloads, a supporto di prestazioni e affidabilità ottimali del cluster.
• Monitoraggio delle risorse a livello di container: monitoraggio di CPU e memoria a livello di singolo container per eliminare gli sprechi e impostare le risorse in base all'utilizzo effettivo.
• Guardrail e policy: definizione di regole di ottimizzazione per criticità del workload e tipo di ambiente, per mantenere protetti i workloads di produzione.
• Visibilità multi-cloud e multi-cluster: intelligence data-driven, applicazione delle policy e azioni di ottimizzazione su qualsiasi numero di cluster e cloud provider, incluso il monitoraggio dell'utilizzo delle GPU.

È pronto a eseguire workloads Kubernetes affidabili ed efficienti sul piano dei costi? Scopra di più su PerfectScale for Kubernetes.