☰

¿Cómo saber por qué la sonda de vida de Kubernetes obtiene HTTP 503 mientras que los registros muestran 200 OK?

tag-icon • tag-icon kubernetes
¿Cómo saber por qué la sonda de vida de Kubernetes obtiene HTTP 503 mientras que los registros muestran 200 OK?

Implementé un pod con Apache httpd (imagen oficial, etiqueta 2.4.41), que ofrece texto sin formato HTTP/2.0 en el puerto 8082 y funciona "bien", pero veo reinicios cada pocas horas ( kubectl get pod/mypod, que muestra 60 reinicios en 5 días).

Los registros siempre muestran"capté a SIGWINCH, apagándose con gracia"( -p, para el grupo 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

La señal SIGWINCH probablemente proviene de una señal de parada a través de Docker (según Dockerfile oficial), por ejemplo, ¿sondeo de vida de Kubernetes? Las solicitudes GET son las sondas de actividad configuradas en /, pero como puede ver, Apache devuelve 200 OK sin problemas.

Kubernetes kubelet parece no estar de acuerdo con el 200 OK de Apache y está reiniciando el pod a 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

No tengo idea de cómo saber quién tiene la culpa aquí. Estoy usando Kubernetes 1.16.4, implementado con kubeadm y Calico CNI.

Respuesta1

Después de profundizar más y más en esto, parece que el demonio Docker estaba matando el contenedor por exceder el límite de memoria registrado en los registros del 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 qué httpd repentinamente supera el límite de memoria sigue siendo una pregunta, pero está fuera de alcance aquí.
  • Por qué Kubernetes no informa que el contenedor se cancela por exceder el límite de memoria (último informe estatal según los documentos) sigue siendo una pregunta para mí.
  • Los registros probablemente no muestran el resultado de ninguna respuesta 503, porque el demonio Docker elimina el contenedor antes de escribirlo en stdout/stderr.
  • Todavía no entiendo la secuencia de eventos aquí si la causa es la falta de memoria, porque primero recibe una señal de apagado elegante y kubelet registra la respuesta como 503 (no tiempo de espera).

Incluso si esta es la causa, es una muy mala experiencia de usuario para que el administrador de Kubernetes la busque.

información relacionada