{"id":80532,"date":"2020-05-07T01:42:17","date_gmt":"2020-05-06T23:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem"},"modified":"2020-05-07T01:42:17","modified_gmt":"2020-05-06T23:42:17","slug":"problemy-s-dns-v-kubernetes-publichnyj-postmortem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem","title":{"rendered":"Probl\u00e8mes de DNS dans Kubernetes. Rapport post-mortem public","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Rem. trad.:<\/b> c'est la traduction d'un postmortem public du blog technique de l'entreprise Preply<\/a><\/noindex>. Il d\u00e9crit un probl\u00e8me avec conntrack dans un cluster Kubernetes, qui a conduit \u00e0 une interruption partielle de certains services en production.<\/i><\/p>\n

Cet article peut \u00eatre utile pour ceux qui souhaitent en savoir un peu plus sur les postmortems ou pr\u00e9venir certains probl\u00e8mes potentiels avec DNS \u00e0 l'avenir.<\/p>\n

\"Probl\u00e8mes
\nCe n'est pas DNS
\nImpossible que ce soit DNS
\nC'\u00e9tait DNS<\/i>
\n<\/a><\/noindex><\/p>\n

Un peu sur les postmortems et les processus chez Preply<\/h2>\n

<\/p>\n

Dans un postmortem, un \u00e9chec de fonctionnement ou un \u00e9v\u00e9nement dans la production est d\u00e9crit. Le postmortem comprend une chronologie des \u00e9v\u00e9nements, une description de l'impact sur l'utilisateur, la cause premi\u00e8re, les actions effectu\u00e9es et les le\u00e7ons apprises.<\/p>\n

Recherche SRE<\/a><\/noindex><\/i><\/p><\/blockquote>\n

\nLors de nos r\u00e9unions hebdomadaires avec des pizzas, entour\u00e9s de l'\u00e9quipe technique, nous partageons diverses informations. Une des parties les plus importantes de ces r\u00e9unions est les postmortems, qui sont souvent accompagn\u00e9s d'une pr\u00e9sentation avec des diapositives et d'une analyse plus approfondie de l'incident survenu. Bien que nous ne \u00ab applaudissions \u00bb pas apr\u00e8s les postmortems, nous essayons de Cultiver une culture \u00ab sans reproches \u00bb (blameless culture<\/a><\/noindex>). Nous croyons que r\u00e9diger et pr\u00e9senter des postmortems peut nous aider (et pas seulement) \u00e0 pr\u00e9venir de tels incidents \u00e0 l'avenir, c'est pourquoi nous les partageons.<\/p>\n

Les personnes impliqu\u00e9es dans l'incident doivent sentir qu'elles peuvent en parler en d\u00e9tail, sans craindre de sanctions ou de repr\u00e9sailles. Aucune r\u00e9primande ! R\u00e9diger un postmortem n'est pas une punition, mais une opportunit\u00e9 d'apprentissage pour l'ensemble de l'entreprise.<\/p>\n

Keep CALMS & DevOps: S est pour le Partage<\/a><\/noindex><\/i><\/p><\/blockquote>\n

<\/p>\n

Probl\u00e8mes de DNS dans Kubernetes. Postmortem<\/h2>\n

\nDate :<\/b> 28.02.2020<\/p>\n

Auteurs :<\/b> Amet U., Andrey S., Igor K., Alexey P.<\/p>\n

Statut :<\/b> Termin\u00e9<\/p>\n

En r\u00e9sum\u00e9 :<\/b> Indisponibilit\u00e9 partielle de DNS (26 min) pour certains services dans le cluster Kubernetes<\/p>\n

Impact :<\/b> 15000 \u00e9v\u00e9nements perdus pour les services A, B et C<\/p>\n

Cause premi\u00e8re :<\/b> Kube-proxy n'a pas pu supprimer correctement l'ancienne entr\u00e9e de la table conntrack, donc certains services essayaient toujours de se connecter \u00e0 des pods inexistants<\/p>\n

E0228 20:13:53.795782       1 proxier.go:610] \u00c9chec de la suppression des connexions d'extr\u00e9mit\u00e9 dns kube-system\/kube-dns, erreur : \u00e9chec de la suppression des entr\u00e9es conntrack pour le pair UDP {100.64.0.10, 100.110.33.231}, erreur : la commande conntrack a \u00e9chou\u00e9 : ...<\/code><\/pre>\n
\nD\u00e9clencheur :<\/b> En raison de la faible charge au sein du cluster Kubernetes, CoreDNS-autoscaler a r\u00e9duit le nombre de pods dans le d\u00e9ploiement de trois \u00e0 deux<\/p>\n
Solution :<\/b> Un nouveau d\u00e9ploiement de l'application a d\u00e9clench\u00e9 la cr\u00e9ation de nouveaux n\u0153uds, le CoreDNS-autoscaler a ajout\u00e9 plus de pods pour g\u00e9rer le cluster, ce qui a provoqu\u00e9 une r\u00e9\u00e9criture de la table conntrack.<\/p>\n
D\u00e9tection :<\/b> La surveillance Prometheus a d\u00e9tect\u00e9 un grand nombre d'erreurs 5xx pour les services A, B et C et a d\u00e9clench\u00e9 un appel aux ing\u00e9nieurs de garde.<\/p>\n
\"Probl\u00e8mes
\nErreurs 5xx dans Kibana<\/i><\/p>\n
Actions<\/h3>\n
<\/p>\n
Action
\nType
\nResponsable
\nLa t\u00e2che<\/p>\n
D\u00e9sactiver l'autoscaler pour CoreDNS
\npr\u00e9venir.
\nAmet U.
\nDEVOPS-695<\/p>\n
Installer un serveur DNS cache
\nr\u00e9duire.
\nMax V.
\nDEVOPS-665<\/p>\n
Configurer la surveillance conntrack
\npr\u00e9venir.
\nAmet U.
\nDEVOPS-674<\/p>\n
<\/p>\n
Le\u00e7ons tir\u00e9es<\/h3>\n
\nCe qui a bien fonctionn\u00e9 :<\/b><\/p>\n