Determine a razão para a falha do Pod

Esta página mostra como escrever e ler uma mensagem de término do contêiner.

Mensagens de término fornecem uma maneira para os contêineres registrarem informações sobre eventos fatais em um local onde possam ser facilmente recuperadas e exibidas por ferramentas como painéis e softwares de monitoramento. Na maioria dos casos, as informações incluídas em uma mensagem de término também devem ser registradas nos logs do Kubernetes.

Antes de você começar

Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

• Killercoda
• Play with Kubernetes

Escrevendo e lendo uma mensagem de término

Neste exercício, você cria um Pod que executa um único contêiner. O manifesto para esse Pod especifica um comando que é executado quando o contêiner é iniciado:

debug/termination.yaml

apiVersion: v1
kind: Pod
metadata:
  name: termination-demo
spec:
  containers:
  - name: termination-demo-container
    image: debian
    command: ["/bin/sh"]
    args: ["-c", "sleep 10 && echo Sleep expired > /dev/termination-log"]

1. Crie um Pod com base no arquivo de configuração YAML:

   kubectl apply -f https://k8s.io/examples/debug/termination.yaml
   

   No arquivo YAML, nos campos command e args, é possível ver que o contêiner dorme por 10 segundos e, em seguida, escreve "Sleep expired" no arquivo /dev/termination-log. Após escrever a mensagem "Sleep expired", o contêiner é encerrado.

2. Exiba informações sobre o Pod:

   kubectl get pod termination-demo
   

   Repita o comando anterior até que o Pod não esteja mais em execução.

3. Exiba informações detalhadas sobre o Pod:

   kubectl get pod termination-demo --output=yaml
   

   A saída inclui a mensagem "Sleep expired":

   apiVersion: v1
   kind: Pod
   ...
       lastState:
         terminated:
           containerID: ...
           exitCode: 0
           finishedAt: ...
           message: |
             Sleep expired          
           ...
   

4. Use um template Go para filtrar a saída, de modo que inclua apenas a mensagem de término:

   kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
   

Se você estiver executando um Pod com vários contêineres, pode usar um template Go para incluir o nome do contêiner. Dessa forma, você pode descobrir qual dos contêineres está falhando:

kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}'

Personalizando a mensagem de término

O Kubernetes recupera mensagens de término do arquivo especificado no campo terminationMessagePath de um contêiner, que tem o valor padrão de /dev/termination-log. Ao personalizar esse campo, você pode instruir o Kubernetes a usar um arquivo diferente. O Kubernetes usa o conteúdo do arquivo especificado para preencher a mensagem de status do contêiner, tanto em casos de sucesso quanto de falha.

A mensagem de término deve ser um breve status final, como uma mensagem de falha de asserção. O kubelet trunca mensagens que excedam 4096 bytes.

O tamanho total da mensagem entre todos os contêineres é limitado a 12KiB, sendo dividido igualmente entre cada contêiner. Por exemplo, se houver 12 contêineres (initContainers ou containers), cada um terá 1024 bytes disponíveis para a mensagem de término.

O caminho padrão para a mensagem de término é /dev/termination-log. Não é possível definir o caminho da mensagem de término após o lançamento de um Pod.

No exemplo a seguir, o contêiner grava mensagens de término em /tmp/my-log para que o Kubernetes possa recuperá-las:

apiVersion: v1
kind: Pod
metadata:
  name: msg-path-demo
spec:
  containers:
  - name: msg-path-demo-container
    image: debian
    terminationMessagePath: "/tmp/my-log"

Além disso, os usuários podem definir o campo terminationMessagePolicy de um contêiner para uma personalização adicional. Esse campo tem como valor padrão "File", o que significa que as mensagens de término são recuperadas apenas do arquivo de mensagem de término. Ao definir terminationMessagePolicy como "FallbackToLogsOnError", você instrui o Kubernetes a usar o último trecho do log de saída do contêiner caso o arquivo de mensagem de término esteja vazio e o contêiner tenha encerrado com erro. A saída do log é limitada a 2048 bytes ou 80 linhas, o que for menor.

Próximos passos

• Veja o campo terminationMessagePath em Container.
• Consulte ImagePullBackOff em Imagens.
• Saiba mais sobre recuperação de logs.
• Aprenda sobre templates Go.
• Conheça mais sobre status do Pod e fase do Pod.
• Entenda os estados do contêiner.