Las interrupciones de Kubernetes podrían ser causadas por kube-dns

Las interrupciones de Kubernetes podrían ser causadas por kube-dns

Tenemos un clúster de Kubernetes de producción que ha tenido varias interrupciones de aproximadamente 1 a 5 minutos de forma semiregular. Estamos intentando solucionar el problema, pero nos encontramos con varias lagunas de información/conocimiento y agradeceríamos algo de ayuda.

Todo nuestro código y software personalizados tienen alta disponibilidad y se implementan en al menos 2 réplicas, y su alta disponibilidad se ha probado bajo carga.

El clúster de Kubernetesesejecutando instancias puntuales, y cuando aparecen instancias puntuales que solo contienen nuestros pods, todo continúa funcionando sin problemas y sin interrupciones. Sin embargo, lo que hemos notado es que cuando se activan los nodos que kube-dnslo contienen, tendemos a sufrir, aunque no siempre, estas interrupciones.

Estamos ejecutando 1.25 en GKE y, por lo tanto, su uso está restringido kube-dns. Estamos ejecutando 1 kube-dnsréplica por cada 3 nodos (normalmente tenemos 9 nodos en ejecución),yHa especificado un mínimo de 3 kube-dnsnodos a través del kube-dns-autoscalermapa de configuración. También estamos ejecutando Istio 1.17.1 por varias razones, peronopara mTLS. También tenemos un PDB kube-dnsque permite solo 1 interrupción.

Lo que vemos es que la mayoría de nuestros servicios comenzarán a agotar el tiempo de espera en sus solicitudes entre sí (los istio-proxyregistros de acceso tienden a registrar un 504 UTerror), y algunos de los servicios en realidad registrarán un EAI_AGAINerror, lo que implica que el DNS agotó el tiempo de espera. También tenemos una aplicación separada en ejecución que hace ping a una combinación de nombres de servicios, así como a la dirección IP del servicio directamente (comenzando a hacer esto para solucionar problemas), y podemos ver que durante los momentos en que EAI_AGAINocurren los errores, el Los pings a las direcciones IP son exitosos, pero las solicitudes de nombres de servicios no, lo que indica además que kube-dnsestán relacionados con el problema.

También hemos verificado esos pings de servicio versus IP en pods que tienen y no tienen sidecar istio-proxy, y podemos ver el mismo comportamiento, lo que implica que el problema esnodebido a istio.

Lo único que estamos empezando a pensar en hacer es implementar NodeLocal DNSCachepara que todos los nodos tengan un caché DNS y, tal vez, solucionar cualquier kube-dnsproblema intermitente. Sin embargo, no estamos seguros de si esto ayudará y nos preocupa que esté enmascarando un problema mayor.

También podemos ver este mismo problema ejecutándose en nuestro entorno que no es de producción, pero aún no hemos podido reproducirlo en ningún lugar. Solo pasa. Incluso reiniciar/eliminar nodos no parece provocar que esto suceda.

Tampoco puedo aumentar el nivel de registro kube-dnsporque GKE ha bloqueado el recurso de implementación y revierte los niveles de registro...

Esperamos recibir algún consejo sobre cómo solucionar y resolver este problema. Gracias

información relacionada