Get best of the week

Problemas con DNS en Kubernetes. Post-mortem p煤blico

Nota perev.: es una traducci贸n del post-mortem p煤blico del blog de ingenier铆a de Preply . Describe un problema de conntrack en el cl煤ster de Kubernetes que provoc贸 cierto tiempo de inactividad de algunos servicios de producci贸n.

Este art铆culo puede ser 煤til para aquellos que quieran aprender un poco m谩s sobre la autopsia o para prevenir posibles problemas con DNS en el futuro.

imagen

DNS
DNS
DNS

Preply


- . , , , .

Seeking SRE

En las reuniones semanales con pizza, en el c铆rculo del equipo t茅cnico, compartimos informaci贸n diversa. Una de las partes m谩s importantes de tales reuniones es la autopsia, que a menudo se acompa帽a de una presentaci贸n con diapositivas y un an谩lisis m谩s profundo del incidente. A pesar del hecho de que no "aplaudimos" despu茅s de la autopsia, tratamos de desarrollar una cultura "sin culpa " ( rutina sin culpa ). Creemos que escribir y presentar una autopsia puede ayudarnos (y no solo) a prevenir incidentes similares en el futuro, por eso los compartimos.

Las personas involucradas en el incidente deben sentir que pueden hablar en detalle al respecto sin temor a castigos o represalias. No hay censura! Escribir un post-mortem no es un castigo, sino una oportunidad de aprender para toda la empresa.

Mantenga CALMS y DevOps: S es para compartir

Problemas con DNS en Kubernetes. Post mortem


Fecha: 28/02/2020

Autores: Amet U., Andrei S., Igor K., Aleksey P.

Estado: Completado

Resumen: indisponibilidad parcial de DNS (26 min) para algunos servicios en el grupo de Kubernetes

Impacto: 15,000 eventos se perdieron para los servicios A,

Causa ra铆z B y C : Kube-proxy no pudo eliminar correctamente la entrada anterior de la tabla conntrack, por lo que algunos servicios a煤n intentaron conectarse a env铆os inexistentes
E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

Disparador: debido a la baja carga dentro del cl煤ster Kubernetes, CoreDNS-autoscaler redujo el n煤mero de pods en la implementaci贸n de tres a dos

decisiones: otra aplicaci贸n de implementaci贸n inici贸 la creaci贸n de nuevos nodos, CoreDNS-autoscaler agreg贸 m谩s plataformas para el servicio de cl煤ster, lo que provoc贸 sobrescribir la

detecci贸n de la tabla de conntrack : La monitorizaci贸n de Prometheus detect贸 una gran cantidad de errores 5xx para los servicios A, B y C e inici贸 una llamada a los ingenieros de servicio


5xx errores en Kibana

Comportamiento


ActuarUn tipoResponsableTarea
Deshabilitar autoescaler para CoreDNSprevenidoAmet U.DEVOPS-695
Instalar el servidor DNS de almacenamiento en cach茅disminuci贸nMax V.DEVOPS-665
Configurar la supervisi贸n de conntrackprevenidoAmet U.DEVOPS-674

Lecciones aprendidas


Qu茅 sali贸 bien:

  • El monitoreo funcion贸 claramente. La reacci贸n fue r谩pida y organizada.


:

  • , conntrack
  • , ()
  • , DNS,

:

  • CoreDNS-autoscaler, conntrack

(EET)


22:13CoreDNS-autoscaler
22:18
22:21
22:39
22:405xx ,

  • Tiempo de detecci贸n: 4 min.
  • Tiempo para completar la acci贸n: 21 min.
  • Tiempo para arreglar: 1 min

Informaci贸n Adicional



Para minimizar la utilizaci贸n del procesador, el kernel de Linux usa algo como conntrack. En resumen, esta es una utilidad que contiene una lista de entradas NAT que se almacenan en una tabla especial. Cuando el pr贸ximo paquete provenga del mismo pod al mismo pod que antes, la direcci贸n IP final no se volver谩 a calcular, sino que se tomar谩 de la tabla conntrack.

C贸mo funciona conntrack

Resumen


Este fue un ejemplo de uno de nuestros post-mortem con algunos enlaces 煤tiles. Espec铆ficamente en este art铆culo compartimos informaci贸n que puede ser 煤til para otras compa帽铆as. Es por eso que no tenemos miedo de cometer errores y es por eso que hacemos p煤blico uno de nuestros post-mortem. Aqu铆 hay algunos temas p煤blicos post mortem m谩s interesantes:

More articles:


All Articles