133 lines
5.2 KiB
Markdown
133 lines
5.2 KiB
Markdown
---
|
|
title: Determine a razão para a falha do Pod
|
|
content_type: task
|
|
weight: 30
|
|
---
|
|
|
|
<!-- overview -->
|
|
|
|
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](/docs/concepts/cluster-administration/logging/).
|
|
|
|
## {{% heading "prerequisites" %}}
|
|
|
|
{{< include "task-tutorial-prereqs.md" >}}
|
|
|
|
<!-- steps -->
|
|
|
|
## 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:
|
|
|
|
{{% code_sample file="debug/termination.yaml" %}}
|
|
|
|
1. Crie um Pod com base no arquivo de configuração YAML:
|
|
|
|
```shell
|
|
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.
|
|
|
|
1. Exiba informações sobre o Pod:
|
|
|
|
```shell
|
|
kubectl get pod termination-demo
|
|
```
|
|
|
|
Repita o comando anterior até que o Pod não esteja mais em execução.
|
|
|
|
1. Exiba informações detalhadas sobre o Pod:
|
|
|
|
```shell
|
|
kubectl get pod termination-demo --output=yaml
|
|
```
|
|
|
|
A saída inclui a mensagem "Sleep expired":
|
|
|
|
```yaml
|
|
apiVersion: v1
|
|
kind: Pod
|
|
...
|
|
lastState:
|
|
terminated:
|
|
containerID: ...
|
|
exitCode: 0
|
|
finishedAt: ...
|
|
message: |
|
|
Sleep expired
|
|
...
|
|
```
|
|
|
|
1. Use um template Go para filtrar a saída, de modo que inclua apenas a mensagem de término:
|
|
|
|
```shell
|
|
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:
|
|
|
|
```shell
|
|
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:
|
|
|
|
```yaml
|
|
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.
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
* Veja o campo `terminationMessagePath` em [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
|
|
* Consulte [ImagePullBackOff](/docs/concepts/containers/images/#imagepullbackoff) em [Imagens](/docs/concepts/containers/images/).
|
|
* Saiba mais sobre [recuperação de logs](/docs/concepts/cluster-administration/logging/).
|
|
* Aprenda sobre [templates Go](https://pkg.go.dev/text/template).
|
|
* Conheça mais sobre [status do Pod](/docs/tasks/debug/debug-application/debug-init-containers/#understanding-pod-status) e [fase do Pod](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase).
|
|
* Entenda os [estados do contêiner](/docs/concepts/workloads/pods/pod-lifecycle/#container-states).
|