Remarque perev.: il s'agit d'une traduction du post-mortem public du blog d'ingénierie de Preply . Il décrit le problème avec conntrack dans le cluster Kubernetes, qui a conduit à l'arrêt partiel de certains services de production.Cet article peut être utile pour ceux qui souhaitent en savoir un peu plus sur l'autopsie ou pour éviter certains problèmes potentiels avec le DNS à l'avenir.DNS
DNS
DNSPreply
- . , , , .
Seeking SRE
Lors de réunions hebdomadaires avec pizza, dans le cercle de l'équipe technique, nous partageons diverses informations. L'une des parties les plus importantes de ces réunions est l'autopsie, qui s'accompagne le plus souvent d'une présentation avec des diapositives et d'une analyse plus approfondie de l'incident. Malgré le fait de ne pas «applaudir» après l'autopsie, nous essayons de développer une culture «sans blâme » ( cluture irréprochable ). Nous pensons que la rédaction et la présentation de l'autopsie peuvent nous aider (et pas seulement) à prévenir des incidents similaires à l'avenir, c'est pourquoi nous les partageons.Les personnes impliquées dans l'incident doivent avoir le sentiment qu'elles peuvent en parler en détail sans crainte de punition ou de représailles. Pas de censure! Écrire un post-mortem n'est pas une punition, mais une opportunité d'apprendre pour toute l'entreprise.
Gardez CALMS & DevOps: S est pour le partage
Problèmes avec DNS dans Kubernetes. Post mortem
Date: 28/02/2020Auteurs: Amet U., Andrei S., Igor K., Aleksey P.Statut: TerminéBrief: Indisponibilité partielle du DNS (26 min) pour certains services du cluster KubernetesImpact: 15 000 événements perdus pour les services A, B et CCause racine: Kube-proxy n'a pas pu supprimer correctement l'ancienne entrée de la table conntrack, donc certains services ont quand même essayé de se connecter à des soumissions inexistantesE0228 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éclencheur: 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 à deuxdécisions: une autre application de déploiement a lancé la création de nouveaux nœuds, CoreDNS-autoscaler a ajouté plus de ponts pour le service de cluster, ce qui a provoqué la réécriture de ladétection de la table des conntracks. : 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 en service
5xx dans KibanaActions
Leçons apprises
Qu'est-ce qui s'est bien passé:- La surveillance a fonctionné clairement. La réaction a été rapide et organisée.
::- CoreDNS-autoscaler, conntrack
(EET)
- Temps de détection: 4 min.
- Temps pour terminer l'action: 21 min.
- Temps de réparation: 1 min
Information additionnelle
Pour minimiser l'utilisation du processeur, le noyau Linux utilise une chose telle que conntrack. En bref, il s'agit d'un utilitaire qui contient une liste d'entrées NAT stockées dans une table spéciale. Lorsque le prochain paquet provient du même pod vers le même pod que précédemment, l'adresse IP finale ne sera pas recalculée, mais sera extraite de la table conntrack.
Comment fonctionne conntrackSommaire
Ce fut un exemple de l'un de nos post-mortem avec quelques liens utiles. Plus précisément, dans cet article, nous partageons des informations qui peuvent être utiles à d'autres sociétés. C'est pourquoi nous n'avons pas peur de faire des erreurs et c'est pourquoi nous rendons public un de nos post-mortem. Voici quelques thèmes post-mortem publics plus intéressants: