Nota. traducción: Esta es una traducción de una autopsia pública del blog de ingeniería de la empresa. . Describe un problema con conntrack en un clúster de Kubernetes, que provocó un tiempo de inactividad parcial de algunos servicios de producción.
Este artículo puede resultar útil para aquellos que quieran aprender un poco más sobre las autopsias o prevenir algunos posibles problemas de DNS en el futuro.
Esto no es DNS
No puede ser DNS
era dns
Un poco sobre autopsias y procesos en Preply
Una autopsia describe un mal funcionamiento o algún evento en la producción. La autopsia incluye una cronología de eventos, impacto en el usuario, causa raíz, acciones tomadas y lecciones aprendidas.
En las reuniones semanales con pizza, entre el equipo técnico, compartimos diversa información. Una de las partes más importantes de estas reuniones son las autopsias, que suelen ir acompañadas de una presentación con diapositivas y un análisis más profundo del incidente. Aunque no aplaudimos después de las autopsias, intentamos desarrollar una cultura de "no culpar" (). Creemos que escribir y presentar autopsias puede ayudarnos a nosotros (y a otros) a prevenir incidentes similares en el futuro, y es por eso que los compartimos.
Las personas involucradas en un incidente deben sentir que pueden hablar en detalle sin temor a castigos o represalias. ¡Sin culpa! Escribir una autopsia no es un castigo, sino una oportunidad de aprendizaje para toda la empresa.
Problemas con DNS en Kubernetes. Post mortem
Fecha: 28.02.2020
Autores: Amet U., Andrey S., Igor K., Alexey P.
Título: Finalizado
En pocas palabras: Indisponibilidad parcial de DNS (26 min) para algunos servicios en el clúster de Kubernetes
Influencia: 15000 eventos perdidos para los servicios A, B y C
Causa principal: Kube-proxy no pudo eliminar correctamente una entrada antigua de la tabla de conntrack, por lo que algunos servicios todavía intentaban conectarse a pods 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: ...Desencadenar: Debido a la baja carga dentro del clúster de Kubernetes, CoreDNS-autoscaler redujo la cantidad de pods en la implementación de tres a dos.
solución: La siguiente implementación de la aplicación inició la creación de nuevos nodos, CoreDNS-autoscaler agregó más pods para servir al clúster, lo que provocó una reescritura de la tabla conntrack.
Detección: El monitoreo 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.
Errores 5xx en Kibana
Actividad
Действие
tipo
Responsable
Tarea
Deshabilitar el escalador automático para CoreDNS
prevenido
Amet U.
DEVOPS-695
Configurar un servidor DNS de caché
disminuir
Max V.
DEVOPS-665
Configurar el monitoreo de conntrack
prevenido
Amet U.
DEVOPS-674
Lecciones aprendidas
Qué salió bien:
- El seguimiento funcionó bien. La respuesta fue rápida y organizada.
- No alcanzamos ningún límite en los nodos.
Que está mal:
- Causa raíz real aún desconocida, similar a en conexión
- Todas las acciones corrigen sólo las consecuencias, no la causa raíz (error)
- Sabíamos que tarde o temprano podríamos tener problemas con los DNS, pero no priorizábamos las tareas
Donde tuvimos suerte:
- La siguiente implementación fue provocada por CoreDNS-autoscaler, que sobrescribió la tabla conntrack
- Este error afectó solo a algunos servicios.
Línea de tiempo (EET)
tiempo
Действие
22:13
CoreDNS-autoscaler redujo la cantidad de pods de tres a dos
22:18
Los ingenieros de turno comenzaron a recibir llamadas del sistema de monitoreo.
22:21
Los ingenieros de turno comenzaron a averiguar la causa de los errores.
22:39
Los ingenieros de turno comenzaron a revertir uno de los últimos servicios a la versión anterior.
22:40
Los errores 5xx dejaron de aparecer, la situación se ha estabilizado
- Tiempo hasta la detección: 4 minutos
- Tiempo antes de la acción: 21 minutos
- Es hora de arreglar: 1 minutos
información adicional
- Registros de CoreDNS:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Enlaces a Kibana (cortado), Grafana (cortado)
Para minimizar el uso de la CPU, el kernel de Linux utiliza algo llamado conntrack. En resumen, se trata de una utilidad que contiene una lista de registros NAT que se almacenan en una tabla especial. Cuando el siguiente paquete llegue 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
resultados
Este fue un ejemplo de una de nuestras autopsias con algunos enlaces útiles. Concretamente en este artículo compartimos información que puede ser útil para otras empresas. Por eso no tenemos miedo de cometer errores y por eso hacemos pública una de nuestras autopsias. Aquí hay algunas autopsias públicas más interesantes:
- GitLab:
- Dropbox:
- Spotify:
- Muchos otros de y repositorio
- también autopsia pública con SRE Book
Fuente: habr.com