Сбои в работе Kubernetes могут быть вызваны kube-dns

Сбои в работе Kubernetes могут быть вызваны kube-dns

У нас есть производственный кластер Kubernetes, который периодически отключается на ~1-5 минут. Мы пытаемся устранить неполадки, но сталкиваемся с различными пробелами в информации/знаниях и будем признательны за помощь.

Весь наш пользовательский код и программное обеспечение обладают высокой доступностью и развернуты как минимум в 2 копиях, а их высокая доступность была протестирована под нагрузкой.

Кластер kubernetesявляетсязапуск спотовых экземпляров, и когда спотовые экземпляры выходят из строя, содержа только наши pod'ы, все продолжает работать гладко, без каких-либо сбоев. Однако мы заметили, что когда узлы выходят из строя, содержащие его kube-dns, то мы, как правило, получаем — но не всегда — эти сбои.

Мы используем 1.25 на GKE и, таким образом, ограничены в использовании kube-dns. Мы используем 1 kube-dnsреплику на 3 узла (обычно у нас работают 9 узлов),иуказали минимум 3 kube-dnsузла через kube-dns-autoscalerconfigmap. Мы также используем 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 заблокировал ресурс развертывания и отменил уровни ведения журнала...

Мы надеемся получить совет о том, как дальше устранять неполадки и решать эту проблему. Спасибо

Связанный контент