TL; DR :
В неожиданный момент времени все веб-модули, обрабатывающие трафик, исходящий от нашего входа, стали нездоровыми. Примерно час или около того, и все снова стало здоровым. Я пытаюсь выяснить, что произошло, так как, похоже, ни одно из моих действий не вызвало внезапного ремонта. У меня было около часа простоя, и я не знаю почему, что страшно (к счастью, это не производство ... пока).
Я опишу ситуацию как можно лучше; В настоящий момент никаких значительных изменений не произошло с платформой / источниками. Внешняя проверка работоспособности нашего кластера kubernetes (GKE) предупредила меня, что платформа недоступна. Конечно же При выполнении запроса к конечной точке я получил HTTP Error 502.
При описании одного из веб-модулей я заметил, что проверка работоспособности не удалась:
Warning Unhealthy 11m (x3 over 11m) kubelet, gke-test-001-web-6a31v8hq-p5ff Readiness probe failed: Get http://10.52.25.179:3000/healthz/full: dial tcp 10.52.25.179:3000: getsockopt: connection refused
Дальнейшее расследование показало, что все Readiness зонды на всех веб-модулях выходили из строя; Это было причиной отключения.
Еще одна странная вещь, на которую следует обратить внимание, заключается в следующем:
веб-модули зонды Readiness и Liveness абсолютно одинаковы.
В то время как Readiness проверки были последовательно помечены как Failed,
Liveness зонды никогда не делали.
Я решил продолжить изучение проблемы и заметил, что конечные точки, установленные для проверок Readiness, прекрасно работали в следующих местах:
Из POD:
root@webpod-76c8ctc6t8-2prjz:/var/lib/webapp# curl -iL 10.52.25.179:3000/healthz/full.json
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json; charset=utf-8
{"healthy":true,"message":"success"}
От УЗЛА:
root@gke-test-001-web-6a31v8hq-p5ff ~ $ curl -iL http://10.52.25.179:3000/healthz/full.json
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json; charset=utf-8
{"healthy":true,"message":"success"}
В это время проверки работоспособности продолжают возвращаться как Failed. Каким-то образом я получаю разные результаты, чем то, что получает kubelet на каждом из этих узлов?
Я заметил следующее:
[Mon Oct 29 16:06:57 2018] cbr0: port 16(veth34a6a4ce) entered disabled state
Мне кажется, сетевой мост pod-overlay-network отключен, но если бы это действительно вызывало проблему, я бы вообще не смог достичь IP-адреса модуля ...
Я пробовал следующие вещи:
- Проверка правильности "нездоровых" стручков (по моему мнению, они были здоровыми)
ifup и ifdown cbr0 интерфейс - Убить кубелета на одном из узлов и проверить, исправил ли он соответствующие проверки
Readyness (не сделал)
- Перезагрузите узел и убедитесь, что он исправил соответствующие
Readyness проверки (это не так)
- Удалите все узлы в пуле узлов, назначенных веб-модулям, и посмотрите, исправили ли новые проблемы (это не так)
И так же внезапно, как и до того, как я смог определить проблему, примерно через час мои стручки снова стали здоровыми, и платформа работала нормально ...
Кто-нибудь знает, что здесь произошло? Любые советы о том, что я могу сделать, если это произойдет снова?
(обратите внимание, что время во фрагментах может сильно отличаться, поскольку оно было взято из разных моментов времени; временные метки указаны в формате UTC)