Nota tradución: Esta é unha tradución dunha autopsia pública do blog de enxeñería da empresa . Describe un problema con conntrack nun clúster de Kubernetes, que provocou un tempo de inactividade parcial dalgúns servizos de produción.
Este artigo pode ser útil para aqueles que queiran aprender un pouco máis sobre as autopsias ou previr algúns posibles problemas de DNS no futuro.
Isto non é DNS
Non pode ser DNS
Era DNS
Un pouco sobre as autopsias e os procesos en Preply
Unha autopsia describe un mal funcionamento ou algún evento na produción. A autopsia inclúe unha cronoloxía dos eventos, a descrición do impacto do usuario, a causa raíz, as accións realizadas e as leccións aprendidas.
Nas reunións semanais con pizza, entre o equipo técnico, compartimos información diversa. Unha das partes máis importantes deste tipo de reunións son as autopsias, que a maioría das veces van acompañadas dunha presentación con diapositivas e dunha análise máis profunda do suceso. Aínda que non aplaudimos despois das autopsias, intentamos desenvolver unha cultura de "non culpa" (). Cremos que escribir e presentar autopsias pode axudarnos a nós (e a outros) a evitar incidentes similares no futuro, por iso os compartimos.
As persoas implicadas nun incidente deben sentir que poden falar detalladamente sen medo a castigo ou retribución. Sen culpa! Escribir unha autopsia non é un castigo, senón unha oportunidade de aprendizaxe para toda a empresa.
Problemas con DNS en Kubernetes. Post mortem
Data: 28.02.2020
Os autores: Amet U., Andrey S., Igor K., Alexey P.
Estado: Rematou
Brevemente: Non dispoñibilidade de DNS parcial (26 min) para algúns servizos do clúster de Kubernetes
Impacto: 15000 eventos perdidos para os servizos A, B e C
Causa raíz: Kube-proxy non puido eliminar correctamente unha entrada antiga da táboa conntrack, polo que algúns servizos aínda estaban tentando 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: ...Disparador: Debido á baixa carga dentro do clúster de Kubernetes, CoreDNS-autoscaler reduciu o número de pods na implementación de tres a dous
solución: A seguinte implantación da aplicación iniciou a creación de novos nodos, CoreDNS-autoscaler engadiu máis pods para servir o clúster, o que provocou unha reescritura da táboa conntrack
Detección: A monitorización de Prometheus detectou un gran número de erros 5xx para os servizos A, B e C e iniciou unha chamada aos enxeñeiros de servizo.
Erros 5xx en Kibana
Actividade
efecto
Tipo
Responsable
Tarefa
Desactivar o escalador automático para CoreDNS
impedido
Amet U.
DEVOPS-695
Configura un servidor DNS de caché
diminuír
V máx.
DEVOPS-665
Configurar a monitorización de conttrack
impedido
Amet U.
DEVOPS-674
Leccións aprendidas
Que foi ben:
- O seguimento funcionou ben. A resposta foi rápida e organizada
- Non alcanzamos ningún límite nos nodos
Que estaba mal:
- A causa raíz real aínda descoñecida, similar a en contra
- Todas as accións corrixen só as consecuencias, non a causa raíz (error)
- Sabiamos que tarde ou cedo podíamos ter problemas co DNS, pero non priorizamos as tarefas
Onde tivemos sorte:
- O seguinte despregamento foi desencadeado por CoreDNS-autoscaler, que sobrescribiu a táboa conntrack
- Este erro afectou só a algúns servizos
Cronoloxía (EET)
Tempo
efecto
22:13
CoreDNS-autoscaler reduciu o número de pods de tres a dous
22:18
Os enxeñeiros de servizo comezaron a recibir chamadas do sistema de vixilancia
22:21
Os enxeñeiros de servizo comezaron a descubrir a causa dos erros.
22:39
Os enxeñeiros de servizo comezaron a revertir un dos servizos máis recentes á versión anterior
22:40
Os erros 5xx deixaron de aparecer, a situación estabilizouse
- Tempo de detección: 4 min
- Tempo antes da acción: 21 min
- Hora de arranxar: 1 min
información adicional
- Rexistros 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 - Ligazóns a Kibana (corte), Grafana (corte)
Para minimizar o uso da CPU, o núcleo de Linux usa algo chamado conntrack. En resumo, esta é unha utilidade que contén unha lista de rexistros NAT que se almacenan nunha táboa especial. Cando o seguinte paquete chegue do mesmo pod ao mesmo pod que antes, o enderezo IP final non se volverá calcular, senón que se tomará da táboa conntrack.
Como funciona conttrack
Resultados de
Este foi un exemplo dunha das nosas autopsias con algunhas ligazóns útiles. En concreto, neste artigo, compartimos información que pode ser útil para outras empresas. Por iso non temos medo a equivocarnos e por iso facemos pública unha das nosas autopsias. Aquí tes algunhas autopsias públicas máis interesantes:
- GitLab:
- Dropbox:
- Spotify:
- Moitos outros de e repositorio
- Tamén autopsia pública con libro SRE
Fonte: www.habr.com