Nota. traducció: Aquesta és una traducció d'una autopsia pública del bloc d'enginyeria de l'empresa . Descriu un problema amb conntrack en un clúster de Kubernetes, que va provocar un temps d'inactivitat parcial d'alguns serveis de producció.
Aquest article pot ser útil per a aquells que vulguin aprendre una mica més sobre les autopsies o prevenir possibles problemes de DNS en el futur.
Això no és DNS
No pot ser DNS
Era DNS
Una mica sobre les autopsies i els processos a Preply
Una autopsia descriu un mal funcionament o algun esdeveniment en producció. L'autopsia inclou una cronologia dels esdeveniments, la descripció de l'impacte de l'usuari, la causa arrel, les accions realitzades i les lliçons apreses.
A les reunions setmanals amb pizza, entre l'equip tècnic, compartim informació diversa. Una de les parts més importants d'aquestes reunions són les autopsies, que solen anar acompanyades d'una presentació amb diapositives i d'una anàlisi més profunda de l'incident. Tot i que no aplaudim després de les autopsies, intentem desenvolupar una cultura de "no culpa" (). Creiem que escriure i presentar autopsies ens pot ajudar a nosaltres (i a altres) prevenir incidents similars en el futur, per això els compartim.
Les persones implicades en un incident haurien de sentir que poden parlar amb detall sense por de càstigs o represàlies. Cap culpa! Escriure una autopsia no és un càstig, sinó una oportunitat d'aprenentatge per a tota l'empresa.
Problemes amb el DNS a Kubernetes. Post mortem
Data: 28.02.2020
Autors: Amet U., Andrey S., Igor K., Alexey P.
Estat: Acabat
Breument: Indisponibilitat parcial de DNS (26 min) per a alguns serveis del clúster de Kubernetes
Influència: 15000 esdeveniments perduts pels serveis A, B i C
Causa arrel: Kube-proxy no ha pogut eliminar correctament una entrada antiga de la taula de conntrack, de manera que alguns serveis encara estaven intentant connectar-se a pods inexistents
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: ...Activador: A causa de la baixa càrrega dins del clúster de Kubernetes, CoreDNS-autoscaler va reduir el nombre de pods en el desplegament de tres a dos
solució: El següent desplegament de l'aplicació va iniciar la creació de nous nodes, CoreDNS-autoscaler va afegir més pods per servir el clúster, cosa que va provocar una reescriptura de la taula de conntrack.
Detecció: El monitoratge de Prometheus va detectar un gran nombre d'errors 5xx per als serveis A, B i C i va iniciar una trucada als enginyers de servei.
Errors 5xx a Kibana
Activitat
efecte
Tipus
Responsable
Tasca
Desactiveu l'escalador automàtic per a CoreDNS
impedit
Amet U.
DEVOPS-695
Configureu un servidor DNS de memòria cau
disminuir
Màxim V.
DEVOPS-665
Configureu el control de conntrack
impedit
Amet U.
DEVOPS-674
Lliçons apreses
Què va anar bé:
- El seguiment va funcionar bé. La resposta va ser ràpida i organitzada
- No vam assolir cap límit als nodes
Què estava malament:
- Causa arrel real encara desconeguda, similar a en contratrack
- Totes les accions corregeixen només les conseqüències, no la causa arrel (error)
- Sabíem que tard o d'hora podríem tenir problemes amb el DNS, però no vam prioritzar les tasques
On hem tingut sort:
- El següent desplegament va ser activat per CoreDNS-autoscaler, que va sobreescriure la taula de conntrack
- Aquest error només va afectar alguns serveis
Cronologia (EET)
Temps
efecte
22:13
CoreDNS-autoscaler va reduir el nombre de pods de tres a dos
22:18
Els enginyers de torn van començar a rebre trucades del sistema de monitoratge
22:21
Els enginyers de guàrdia van començar a esbrinar la causa dels errors.
22:39
Els enginyers de servei van començar a revertir un dels últims serveis a la versió anterior
22:40
Els errors 5xx van deixar d'aparèixer, la situació s'ha estabilitzat
- Temps de detecció: Minuts 4
- Temps abans de l'acció: Minuts 21
- Hora d'arreglar: Minuts 1
Дополнительная информация
- Registres 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 - Enllaços a Kibana (tallat), Grafana (tallat)
Per minimitzar l'ús de la CPU, el nucli de Linux utilitza una cosa anomenada conntrack. En resum, aquesta és una utilitat que conté una llista de registres NAT que s'emmagatzemen en una taula especial. Quan el següent paquet arribi del mateix pod al mateix pod que abans, l'adreça IP final no es tornarà a calcular, sinó que s'agafarà de la taula de conntrack.
Com funciona conttrack
Resultats de
Aquest va ser un exemple d'una de les nostres autopsies amb alguns enllaços útils. Concretament en aquest article, compartim informació que pot ser útil per a altres empreses. Per això no tenim por d'equivocar-nos i per això fem pública una de les nostres autopsies. Aquí hi ha algunes autopsies públiques més interessants:
- GitLab:
- Dropbox:
- Spotify:
- Molts altres de i repositori
- També autopsia pública amb el llibre SRE
Font: www.habr.com