Informação divergente kubctl describe e get pods

Quando executo kubctl get pods tenho o seguinte resultado:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          23m

Quando executo kubctl describe pod nginx tenho o seguinte resultado:

Events:
  Type     Reason        Age                From               Message
  ----     ------        ----               ----               -------
  Normal   Scheduled     23m                default-scheduler  Successfully assigned default/nginx to minikube
  Warning  Failed        22m                kubelet            Failed to pull image "nginx:latest": rpc error: code = Unknown desc = failed to register layer: Error processing tar file(archive/tar: invalid tar header):
  Warning  Failed        22m                kubelet            Error: ErrImagePull
  Normal   BackOff       22m                kubelet            Back-off pulling image "nginx:latest"
  Warning  Failed        22m                kubelet            Error: ImagePullBackOff
  Normal   Pulling       22m (x2 over 23m)  kubelet            Pulling image "nginx:latest"
  Normal   Pulled        22m                kubelet            Successfully pulled image "nginx:latest" in 10.619108258s
  Normal   Created       22m                kubelet            Created container nginx
  Normal   Started       22m                kubelet            Started container nginx
  Warning  NodeNotReady  16m (x5 over 19m)  node-controller    Node is not ready
  Warning  NodeNotReady  6m                 node-controller    Node is not ready

Qual resultado eu devo confiar? Porque está divergente? Um apontando "Running" e outro retornando um warning de "NodeNotReady"?

Oi, Juan. Tudo bem?

Segundo a documentação do kubernetes neste link

Pods follow a defined lifecycle, starting in the Pending phase, moving through Running if at least one of its primary containers starts OK, and then through either the Succeeded or Failed phases depending on whether any container in the Pod terminated in failure.

Ou seja, um pód começa com status pendente, depois vai para em execução se algum dos containers primários começar bem sua execução e só irão para falha caso o Pod termine com erro.

Olhando o segundo log, do describe pod podemos vez que o último status é o NodeNotReady,ou seja o nó do cluster que deveria executar o pod ainda não está pronto, mas o pod em si ainda não chegou num status de falha, pois está esperando o recurso do node ficar disponível.

Então você não precisa confiar em um ou outro log, mas sim usar os 2 em conjunto para debugar quando ocorrer um problema.

Espero ter ajudado. Bons estudos!

Mergulhe em programação