Note traduction: Ceci est une traduction d'une autopsie publique du blog d'ingénierie de l'entreprise. . Il décrit un problème avec conntrack dans un cluster Kubernetes, qui a entraîné un temps d'arrêt partiel de certains services de production.
Cet article peut être utile à ceux qui souhaitent en savoir un peu plus sur les post-mortems ou éviter certains problèmes DNS potentiels à l'avenir.
Ce n'est pas du DNS
Ça ne peut pas être DNS
C'était DNS
Un peu sur les post-mortems et les processus dans Preply
Une autopsie décrit un dysfonctionnement ou un événement de production. L'autopsie comprend une chronologie des événements, l'impact sur les utilisateurs, la cause profonde, les actions prises et les leçons apprises.
Lors des réunions hebdomadaires avec Pizza, au sein de l'équipe technique, nous partageons diverses informations. L'une des parties les plus importantes de ces réunions sont les autopsies, qui sont le plus souvent accompagnées d'une présentation avec diapositives et d'une analyse plus approfondie de l'incident. Même si nous n'applaudissons pas après les autopsies, nous essayons de développer une culture du « sans reproche » (). Nous pensons que la rédaction et la présentation d'autopsies peuvent nous aider (ainsi que d'autres) à prévenir des incidents similaires à l'avenir, c'est pourquoi nous les partageons.
Les personnes impliquées dans un incident doivent sentir qu'elles peuvent s'exprimer en détail sans craindre de punition ou de représailles. Pas de reproche ! Rédiger un post-mortem n’est pas une punition, mais une opportunité d’apprentissage pour toute l’entreprise.
Problèmes avec DNS dans Kubernetes. Autopsie
Дата: 28.02.2020
Auteurs: Amet U., Andrey S., Igor K., Alexey P.
Titre: Achevé
Brièvement: Indisponibilité partielle du DNS (26 min) pour certains services du cluster Kubernetes
Influence: 15000 XNUMX événements perdus pour les services A, B et C
Cause première: Kube-proxy n'a pas pu supprimer correctement une ancienne entrée de la table conntrack, donc certains services essayaient toujours de se connecter à des pods inexistants
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: ...Déclenchement: En raison de la faible charge à l'intérieur du cluster Kubernetes, CoreDNS-autoscaler a réduit le nombre de pods dans le déploiement de trois à deux.
solution: Le prochain déploiement de l'application a initié la création de nouveaux nœuds, CoreDNS-autoscaler a ajouté plus de pods pour servir le cluster, ce qui a provoqué une réécriture de la table conntrack
Détection: La surveillance Prometheus a détecté un grand nombre d'erreurs 5xx pour les services A, B et C et a lancé un appel aux ingénieurs de service.
Erreurs 5xx dans Kibana
Activité
Действие
type
Responsable
Tâche
Désactiver l'autoscaler pour CoreDNS
empêché
Amet U.
DEVOPS-695
Configurer un serveur DNS de mise en cache
diminuer
Max V.
DEVOPS-665
Configurer la surveillance de Conntrack
empêché
Amet U.
DEVOPS-674
Leçons apprises
Qu'est-ce qui s'est bien passé:
- La surveillance a bien fonctionné. La réponse a été rapide et organisée
- Nous n'avons atteint aucune limite sur les nœuds
Ce qui était faux:
- Cause réelle encore inconnue, similaire à en contact
- Toutes les actions corrigent uniquement les conséquences, pas la cause première (bug)
- Nous savions que tôt ou tard nous pourrions avoir des problèmes avec DNS, mais nous n'avons pas hiérarchisé les tâches
Où nous avons eu de la chance :
- Le déploiement suivant a été déclenché par CoreDNS-autoscaler, qui a écrasé la table conntrack
- Ce bug n'affectait que certains services
Chronologie (EET)
temps
Действие
22:13
CoreDNS-autoscaler a réduit le nombre de pods de trois à deux
22:18
Les ingénieurs de service ont commencé à recevoir des appels du système de surveillance
22:21
Les ingénieurs de service ont commencé à rechercher la cause des erreurs.
22:39
Les ingénieurs en service ont commencé à restaurer l'un des derniers services vers la version précédente
22:40
Les erreurs 5xx ont cessé d'apparaître, la situation s'est stabilisée
- Temps de détection : 4 minutes
- Temps avant l'action : 21 minutes
- Il est temps de réparer : 1 minutes
Informations supplémentaires
- Journaux 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 - Liens vers Kibana (coupé), Grafana (coupé)
Pour minimiser l'utilisation du processeur, le noyau Linux utilise quelque chose appelé conntrack. En bref, il s'agit d'un utilitaire qui contient une liste d'enregistrements NAT stockés dans une table spéciale. Lorsque le prochain paquet arrive du même pod vers le même pod qu'avant, l'adresse IP finale ne sera pas recalculée, mais sera extraite de la table conntrack.
Comment fonctionne Conntrack
Les résultats de
C'était un exemple d'une de nos autopsies avec quelques liens utiles. Plus précisément, dans cet article, nous partageons des informations qui peuvent être utiles à d'autres entreprises. C'est pourquoi nous n'avons pas peur de faire des erreurs et c'est pourquoi nous rendons publique l'une de nos autopsies. Voici quelques post-mortems publics plus intéressants :
- GitLab :
- Dropbox:
- Spotify:
- Beaucoup d'autres de et dépôt
- aussi post-mortem public avec SRE Book
Source: habr.com