Kubernetes Exit Code 143: 8 causas, como diagnosticar e corrigir

Como diagnosticar o Exit Code 143 no Kubernetes

Diagnosticar o exit code 143 significa descobrir quem enviou o SIGTERM e por quê. Como o Kubernetes usa esse sinal com frequência durante o gerenciamento normal de workloads, o exit code sozinho não indica uma falha.

Comece pelo status do pod e do container e, em seguida, correlacione o horário do encerramento com logs, eventos, rollouts, atividade de escalonamento e operações de nodes. Verifique também se a aplicação responde corretamente ao receber o SIGTERM.

Etapa 1: inspecione o status do pod

Comece verificando o estado atual e o status detalhado do pod:

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

Procure por reinicializações de containers, condições do pod, eventos recentes e informações de encerramento. kubectl describe pod também pode revelar falhas de probes, atividade de eviction, mudanças de agendamento e outros eventos relacionados ao desligamento.

Se o pod for gerenciado por um Deployment, StatefulSet ou outro controlador, identifique também o seu owner. Isso ajuda a determinar se o encerramento fez parte da atividade normal do controlador.

Etapa 2: verifique o exit code do container e o motivo do encerramento

Inspecione o estado de encerramento atual e anterior do container. Para um container reiniciado, o Kubernetes pode reter detalhes como exit code, motivo, sinal e timestamps:

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

Confirme que o exit code registrado é 143. Verifique também o motivo do encerramento e os timestamps startedAt e finishedAt, que podem ser correlacionados com eventos do Kubernetes e logs da aplicação.

Não presuma que o exit code 143 por si só explica a causa. Ele informa que o processo foi encerrado por causa do SIGTERM, mas não qual operação do Kubernetes ou processo externo iniciou o encerramento.

Etapa 3: revise os logs atuais e anteriores do container

Verifique os logs da aplicação em torno do horário do encerramento:

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

Se o container tiver reiniciado, inspecione os logs da instância anterior do container:

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

Procure por mensagens de desligamento, mensagens de sinal recebido, requisições inacabadas, erros de conexão e exceções da aplicação. Uma sequência limpa — como receber o SIGTERM, parar novos trabalhos, fechar recursos e sair — geralmente indica um encerramento gracioso.

Para pods com vários containers, especifique o container relevante com -c <container-name>.

Etapa 4: inspecione os eventos do Kubernetes

Os eventos do Kubernetes podem fornecer contexto sobre o que aconteceu imediatamente antes do encerramento:

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

Procure por mensagens relacionadas a falhas de probes, eviction de pods, reinicializações de containers, escalonamento, agendamento ou problemas de nodes. Compare os timestamps dos eventos com o timestamp de encerramento do container.

Os eventos são úteis, mas não constituem uma trilha de auditoria completa. Eles podem expirar, e nem toda causa de encerramento de pod gera um evento que explique claramente por que o SIGTERM foi enviado.

Etapa 5: verifique a atividade de Deployment e rollout

Determine se o container parou durante uma atualização de Deployment ou outra mudança no workload:

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

Inspecione também os ReplicaSets ao diagnosticar um Deployment. Um novo ReplicaSet surgindo perto do horário do encerramento é um forte indício de que os pods antigos estavam sendo substituídos durante um rollout.

Se o exit code 143 ocorrer apenas quando novas versões da aplicação são implantadas, geralmente faz parte da substituição normal de pods. A próxima pergunta é se esses pods foram desligados de forma limpa, sem derrubar requisições ou perder trabalho.

Etapa 6: verifique eventos de escalonamento, eviction ou nodes

Verifique se mudanças de réplicas, autoscaling, drains de nodes ou operações de infraestrutura coincidem com o encerramento. Para workloads que usam um HorizontalPodAutoscaler, inspecione seu estado atual e o comportamento recente:

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

Inspecione também o node que hospedava o pod:

kubectl describe node <node-name>

Procure por desligamentos de nodes, manutenção, condições de pressão, atividade do autoscaler ou eventos relacionados a eviction. Se muitos pods não relacionados forem encerrados aproximadamente ao mesmo tempo, uma operação no nível do node ou do cluster é mais provável do que um problema específico da aplicação.

Etapa 7: determine se a aplicação trata o SIGTERM corretamente

Por fim, verifique como o processo principal da aplicação responde ao SIGTERM. Ele normalmente deve parar de aceitar novos trabalhos, concluir ou cancelar com segurança as operações ativas, fazer o flush dos dados necessários, fechar as conexões externas e sair antes que o período de carência expire.

Verifique o período de carência configurado do pod:

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

Verifique também se os sinais realmente chegam à aplicação. Containers que iniciam aplicações por meio de shell scripts ou de gerenciadores de processos configurados incorretamente podem interferir no encaminhamento de sinais quando a aplicação não é o PID 1.

Se o desligamento gracioso consistentemente levar mais tempo do que o período disponível, melhore o caminho de desligamento ou aumente o terminationGracePeriodSeconds quando apropriado. Testar a aplicação diretamente com SIGTERM pode confirmar que seu handler de sinal é executado e sai dentro do tempo esperado.

Boas práticas para prevenir o Exit Code 143 no Kubernetes {#best-practices-to-prevent-kubernetes-exit-code-143}

Confira algumas maneiras de prevenir o exit code 143 ao trabalhar com Kubernetes.

1. Implemente o tratamento gracioso do SIGTERM

As aplicações devem tratar o SIGTERM explicitamente e iniciar um desligamento ordenado quando o sinal chegar. Um serviço deve parar de aceitar novos trabalhos, concluir ou cancelar com segurança as requisições ativas, fechar conexões, fazer o flush dos dados em buffer e, então, sair.

Garanta que a aplicação realmente receba o sinal. Shell scripts intermediários e gerenciadores de processos podem impedir que os sinais cheguem à aplicação se não os encaminharem corretamente. Usar exec em um script de entrypoint pode substituir o shell pelo processo da aplicação:

exec /app/my-service

Isso torna a aplicação o PID 1 e permite que os sinais de encerramento do container cheguem diretamente a ela.

2. Defina um terminationGracePeriodSeconds adequado

Defina o terminationGracePeriodSeconds longo o suficiente para que a aplicação conclua seu procedimento normal de desligamento. O Kubernetes usa 30 segundos por padrão, mas isso pode ser insuficiente para requisições de longa duração, jobs em lote, consumidores de mensagens ou aplicações com trabalho de limpeza considerável.

Por exemplo:

spec:
  terminationGracePeriodSeconds: 60

Baseie o valor nos tempos de desligamento observados, em vez de simplesmente definir um timeout grande. As aplicações ainda devem encerrar o mais rápido possível, pois um período de carência desnecessariamente longo pode atrasar rollouts, operações de escalonamento e manutenções de nodes.

3. Use um hook preStop quando for necessária lógica adicional de desligamento

Um hook preStop pode executar lógica adicional antes que o container receba seu sinal normal de parada. Ele é útil quando o desligamento exige um comando explícito, o cancelamento do registro de um serviço ou outra operação fora do handler padrão de SIGTERM da aplicação.

Por exemplo:

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

Mantenha o hook curto e confiável. Seu tempo de execução é descontado do período de carência do pod, então um hook preStop lento reduz o tempo disponível para a aplicação desligar após receber o SIGTERM.

4. Faça os workers em segundo plano encerrarem com segurança

Workers em segundo plano precisam de tratamento de encerramento tanto quanto os serviços HTTP. Quando um worker recebe o SIGTERM, ele normalmente deve parar de aceitar novos jobs e concluir o job atual ou devolver o trabalho inacabado à fila usando o mecanismo suportado pelo sistema de filas.

Evite sair imediatamente enquanto um job está parcialmente processado. Dependendo do workload, isso pode resultar em trabalho perdido, processamento duplicado, atualizações incompletas no banco de dados ou estado inconsistente da aplicação.

Para jobs de longa duração, garanta que o período de carência seja compatível com os tempos de processamento esperados. Quando os jobs não puderem terminar de forma confiável dentro desse período, projete-os para serem repetíveis ou retomáveis.

5. Monitore o exit code 143 em contexto

Não crie alertas para cada ocorrência do exit code 143. Ele é esperado durante deploys com rolling update, exclusão manual de pods, operações de scale-down, drains de nodes e outras atividades rotineiras do Kubernetes.

Em vez disso, correlacione o exit code 143 com taxas de reinicialização de pods, atividade de deployment, eventos do Kubernetes, operações de nodes, erros da aplicação e requisições com falha. Encerramentos repetidos por SIGTERM sem uma operação conhecida no cluster merecem investigação adicional.

Monitorar o contexto ao redor torna o exit code 143 útil como sinal de diagnóstico. Ele ajuda a distinguir a atividade saudável do ciclo de vida de falhas de probes, workloads instáveis, encerramentos inesperados de processos ou mudanças de infraestrutura.

FAQ

O exit code 143 do Kubernetes é um erro? Geralmente não. O exit code 143 significa que o processo principal do container recebeu SIGTERM e parou. O Kubernetes envia esse sinal durante atividades normais, como rolling updates, exclusão de pods, scale-down e drains de nodes, então o código por si só não indica uma falha.

Qual é a diferença entre o exit code 143 e o exit code 137? O exit code 143 é 128 + 15 e significa que o processo parou após o SIGTERM, que dá à aplicação a chance de desligar de forma graciosa. O exit code 137 é 128 + 9 e significa SIGKILL, que não pode ser capturado. Ele pode ocorrer quando um container estoura seu período de carência de encerramento ou é finalizado por falta de memória.

Quanto tempo o Kubernetes espera antes de enviar o SIGKILL? O período de carência de encerramento é de 30 segundos por padrão e é definido com terminationGracePeriodSeconds. Um hook preStop é executado dentro dessa mesma janela, então um hook lento deixa a aplicação com menos tempo para tratar o SIGTERM.

Como descubro o que enviou o SIGTERM? Comece com kubectl describe pod e o último estado de encerramento do container, depois compare os timestamps com eventos do Kubernetes, histórico de rollouts, atividade do HPA e eventos de nodes. Se nada no cluster coincidir, verifique os logs da aplicação e do gerenciador de processos, já que um script, supervisor ou sidecar também pode enviar SIGTERM.

Devo criar alertas para o exit code 143? Não, não para cada ocorrência. Em vez disso, alerte sobre padrões, como encerramentos repetidos por SIGTERM sem rollout, escalonamento ou operação de node conhecidos, ou encerramentos que coincidam com requisições com falha ou taxas crescentes de reinicialização.

Mantenha seus workloads Kubernetes estáveis em cada encerramento com o PerfectScale

O exit code 143 geralmente é sinal de atividade saudável do ciclo de vida, mas rollouts frequentes, scale-downs e mudanças de nodes dificultam distinguir encerramentos rotineiros de problemas reais de resiliência. O PerfectScale for Kubernetes da DoiT oferece automação sensível aos workloads com uma abordagem que prioriza a estabilidade, mantendo a saúde da aplicação no centro de cada recomendação de otimização. Ele dá às equipes de plataforma, SRE e FinOps uma visão única da saúde, do desempenho e dos custos do cluster, para que possam identificar problemas de resiliência e dimensionar corretamente os workloads sem monitoramento e reconfiguração manuais constantes.

Principais recursos do PerfectScale for Kubernetes:

• Detecção de problemas de resiliência: o Podfit oferece uma visão granular da saúde e dos custos do cluster, priorizando as áreas que precisam de atenção e ajudando as equipes a identificar rapidamente recursos desperdiçados e problemas de resiliência.
• Right-sizing com prioridade na estabilidade: o right-sizing sensível ao contexto adapta as ações com base em baselines de desempenho, padrões de tráfego e criticidade para o negócio, para que a otimização nunca comprometa a saúde da aplicação.
• Otimização autônoma de workloads: recomendações orientadas por dados e fluxos de automação fazem o right-sizing contínuo dos workloads, eliminando o ciclo constante de reconfiguração que consome o tempo da engenharia.
• Insights de configuração de autoscalers: recomendações acionáveis ajudam a melhorar as configurações de HPA e KEDA, enquanto o Infrafit ajuda a maximizar a eficácia de autoscalers de nodes como o Karpenter.
• Visibilidade da utilização dos nodes: o Infrafit identifica capacidade ociosa de nodes e recomenda os nodes certos para seus workloads, garantindo desempenho e confiabilidade máximos do cluster.
• Acompanhamento de recursos no nível do container: monitore CPU e memória no nível do container para eliminar desperdícios e definir recursos com base no uso real.
• Guardrails e políticas: defina regras de otimização por criticidade do workload e tipo de ambiente para manter os workloads de produção protegidos.
• Visibilidade multi-cloud e multi-cluster: obtenha inteligência orientada por dados, aplicação de políticas e ações de otimização em qualquer número de clusters e provedores de nuvem, incluindo o acompanhamento da utilização de GPUs.

Pronto para executar workloads Kubernetes confiáveis e com custos otimizados? Saiba mais sobre o PerfectScale for Kubernetes.