☰

Como saber por que a investigação de atividade do Kubernetes obtém HTTP 503 enquanto os logs mostram 200 OK?

tag-icon • tag-icon kubernetes
Como saber por que a investigação de atividade do Kubernetes obtém HTTP 503 enquanto os logs mostram 200 OK?

Implantei um pod com Apache httpd (imagem oficial, etiqueta 2.4.41), servindo texto simples HTTP/2.0 na porta 8082, e está funcionando "bem", mas vejo reinicializações a cada poucas horas ( kubectl get pod/mypod, mostrando 60 reinicializações em 5 dias).

Os logs sempre mostram"peguei SIGWINCH, desligando normalmente"( -p, para pod anterior):

$ kubectl logs -c httpdcontainer -p pod/mypod
  [...]
  127.0.0.1 - - [15/Jan/2020:11:12:27 +0000] "GET / HTTP/2.0" 200 9578
  [Wed Jan 15 11:12:40.433582 2020] [mpm_event:notice] [pid 1:tid 139963289400448] AH00492: caught SIGWINCH, shutting down gracefully
  127.0.0.1 - - [15/Jan/2020:11:12:37 +0000] "GET / HTTP/2.0" 200 9578

O sinal SIGWINCH provavelmente vem de um sinal de parada via Docker (conforme Dockerfile oficial), por exemplo, sonda de atividade do Kubernetes? As solicitações GET são testes de atividade configurados em /, mas como você pode ver, o Apache está retornando 200 OK perfeitamente.

O kubelet do Kubernetes parece discordar do 200 OK do Apache e está reiniciando o pod de propósito:

$ kubectl describe pod/mypod
[...]
Type     Reason     Age                       From                                    Message
----     ------     ----                      ----                                    -------
Warning  Unhealthy  38m (x208 over 5d)        kubelet, node01.kube.mydomain.tld  Readiness probe failed: Get http://192.168.87.178:8082/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Normal   Killing    38m (x60 over 4d23h)      kubelet, node01.kube.mydomain.tld  Container docs failed liveness probe, will be restarted
Warning  Unhealthy  38m (x221 over 5d)        kubelet, node01.kube.mydomain.tld  Liveness probe failed: Get http://192.168.87.178:8082/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Normal   Pulled     38m (x60 over 4d23h)      kubelet, node01.kube.mydomain.tld  Container image "myregistry.mydomain.tld/foo/bar/myimage@sha256:<checksum>" already present on machine
Normal   Created    38m (x61 over 5d19h)      kubelet, node01.kube.mydomain.tld  Created container docs
Normal   Started    38m (x61 over 5d19h)      kubelet, node01.kube.mydomain.tld  Started container docs
Warning  Unhealthy  13m (x1644 over 5d19h)    kubelet, node01.kube.mydomain.tld  Readiness probe failed: HTTP probe failed with statuscode: 503
Warning  Unhealthy  3m16s (x1717 over 5d19h)  kubelet, node01.kube.mydomain.tld  Liveness probe failed: HTTP probe failed with statuscode: 503

Não tenho ideia de como saber qual é a culpa aqui. Estou usando o Kubernetes 1.16.4, implantado com kubeadm e Calico CNI.

Responder1

Depois de investigar isso cada vez mais, parece que o daemon do Docker estava eliminando o contêiner por ultrapassar o limite de memória registrado nos logs do sistema:

Jan 15 12:12:40 node01 kernel: [2411297.634996] httpd invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=998
[...]
Jan 15 12:12:40 node01 kernel: [2411297.672084] oom_reaper: reaped process 519 (httpd), now anon-rss:0kB, file-rss:0kB, shmem-rss:68kB
  • Por que o httpd repentinamente ultrapassa o limite de memória permanece uma questão, mas está fora do escopo aqui.
  • Por que o Kubernetes não relata que o contêiner foi eliminado por ultrapassar o limite de memória (relatório lastState conforme documentos) continua sendo uma pergunta para mim.
  • Os logs provavelmente não mostram a saída de nenhuma resposta 503, porque o contêiner é eliminado pelo daemon do Docker antes de ser gravado em stdout/stderr.
  • Ainda não consigo entender a sequência de eventos aqui se a causa for falta de memória, porque ele recebe primeiro um sinal de desligamento normal e a resposta é registrada como 503 pelo kubelet (não tempo limite).

Mesmo que essa seja a causa, é uma experiência de usuário muito ruim para o administrador do Kubernetes caçá-la.

informação relacionada