У нас есть производственный кластер Kubernetes, который периодически отключается на ~1-5 минут. Мы пытаемся устранить неполадки, но сталкиваемся с различными пробелами в информации/знаниях и будем признательны за помощь.
Весь наш пользовательский код и программное обеспечение обладают высокой доступностью и развернуты как минимум в 2 копиях, а их высокая доступность была протестирована под нагрузкой.
Кластер kubernetesявляетсязапуск спотовых экземпляров, и когда спотовые экземпляры выходят из строя, содержа только наши pod'ы, все продолжает работать гладко, без каких-либо сбоев. Однако мы заметили, что когда узлы выходят из строя, содержащие его kube-dns
, то мы, как правило, получаем — но не всегда — эти сбои.
Мы используем 1.25 на GKE и, таким образом, ограничены в использовании kube-dns
. Мы используем 1 kube-dns
реплику на 3 узла (обычно у нас работают 9 узлов),иуказали минимум 3 kube-dns
узла через kube-dns-autoscaler
configmap. Мы также используем Istio 1.17.1 по разным причинам, нонетдля mTLS. У нас также есть PDB, kube-dns
которая допускает только 1 нарушение.
Мы видим, что большинство наших служб начинают тайм-аут в своих запросах друг к другу ( istio-proxy
журналы доступа имеют тенденцию регистрировать 504
UT
ошибку), а некоторые службы действительно регистрируют ошибку EAI_AGAIN
, что означает, что DNS истек. У нас также есть отдельное запущенное приложение, которое пингует смесь имен служб, а также IP-адрес службы напрямую (начали делать это в целях устранения неполадок), и мы можем видеть, что в те моменты, когда EAI_AGAIN
происходят ошибки, пинги IP-адресов успешны, но запросы имен служб нет, что еще раз указывает на kube-dns
связь с проблемой.
Мы также проверили эти пинги служб и IP-адресов для модулей, у которых есть и нет sidecar istio-proxy
, и видим одинаковое поведение, что означает, что проблема заключается внетиз-за istio
.
Единственное, что мы начинаем думать о том, чтобы реализовать NodeLocal DNSCache
так, чтобы все узлы имели кэш DNS и - возможно - замазать любые периодические kube-dns
проблемы. Однако мы не уверены, поможет ли это, и беспокоимся, что это будет маскировать более серьезную проблему.
Мы также можем видеть эту же проблему, запущенную в нашей непроизводственной среде, но пока не смогли воспроизвести ее где-либо. Это просто происходит. Даже перезапуск/удаление узлов, похоже, не приводит к этому.
Я также не могу повысить уровень ведения журнала, kube-dns
поскольку GKE заблокировал ресурс развертывания и отменил уровни ведения журнала...
Мы надеемся получить совет о том, как дальше устранять неполадки и решать эту проблему. Спасибо