![Как узнать, почему проверка работоспособности Kubernetes выдает HTTP 503, а в журналах отображается 200 OK?](https://rvso.com/image/747339/%D0%9A%D0%B0%D0%BA%20%D1%83%D0%B7%D0%BD%D0%B0%D1%82%D1%8C%2C%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8%20Kubernetes%20%D0%B2%D1%8B%D0%B4%D0%B0%D0%B5%D1%82%20HTTP%20503%2C%20%D0%B0%20%D0%B2%20%D0%B6%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D0%B0%D1%85%20%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20200%20OK%3F.png)
Я развернул модуль с Apache httpd (официальное изображение, тег 2.4.41), обслуживающий открытый текст HTTP/2.0 на порту 8082, и он работает «нормально», но я вижу перезапуски каждые несколько часов ( kubectl get pod/mypod
, показывая 60 перезапусков за 5 дней).
Логи всегда показывают"поймал SIGWINCH, изящно отключился"( -p
, для предыдущего модуля):
$ 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
Сигнал SIGWINCH, вероятно, исходит от стоп-сигнала через Docker (согласно официальному Dockerfile), например, проверка жизнеспособности Kubernetes? Запросы GET — это настроенные проверки жизнеспособности на /, но, как вы видите, Apache возвращает 200 OK, все в порядке.
Kubernetes kubelet, похоже, не согласен с ответом 200 OK от Apache и намеренно перезапускает модуль:
$ 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
Понятия не имею, что тут виновато. Я использую Kubernetes 1.16.4, развернутый с помощью kubeadm и Calico CNI.
решение1
После более глубокого изучения этой проблемы выяснилось, что демон Docker завершал работу контейнера из-за превышения лимита памяти, что зафиксировано в системных журналах:
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
- Почему httpd внезапно превысил лимит памяти, остается вопросом, но он здесь не рассматривается.
- Почему Kubernetes не сообщает об остановке контейнера из-за превышения лимита памяти (последний отчет штата согласно документам) остается для меня вопросом.
- Логи, вероятно, не отображают вывод ответа 503, поскольку контейнер завершается демоном Docker до того, как он запишет его в stdout/stderr.
- Я все еще не могу понять последовательность событий, если причиной является нехватка памяти, потому что сначала он получает сигнал о корректном завершении работы, а ответ регистрируется kubelet как 503 (не тайм-аут).
Даже если это и есть причина, администратору Kubernetes будет крайне сложно ее выследить.