{"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\/es\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem","title":{"rendered":"Problemas de DNS en Kubernetes. Informe post-mortem p\u00fablico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota del traductor:<\/b> esta es la traducci\u00f3n de un informe post-mortem p\u00fablico del blog de ingenier\u00eda de la empresa Preply<\/a><\/noindex>. En \u00e9l se describe un problema con conntrack en el cl\u00faster de Kubernetes, que provoc\u00f3 un tiempo de inactividad parcial de algunos servicios de producci\u00f3n.<\/i><\/p>\n

Este art\u00edculo puede ser \u00fatil para aquellos que desean aprender un poco m\u00e1s sobre los informes post-mortem o prevenir posibles problemas de DNS en el futuro.<\/p>\n

\"Problemas
\nNo es DNS
\nNo puede ser que sea DNS
\nEso fue DNS<\/i>
\n<\/a><\/noindex><\/p>\n

Un poco sobre los informes post-mortem y los procesos en Preply<\/h2>\n

<\/p>\n

El informe post-mortem describe una falla en el funcionamiento o alg\u00fan evento en producci\u00f3n. Un post-mortem incluye una cronolog\u00eda de eventos, descripci\u00f3n del impacto en el usuario, la causa ra\u00edz, las acciones y las lecciones aprendidas.<\/p>\n

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

\nEn las reuniones semanales con pizza, en el c\u00edrculo del equipo t\u00e9cnico, compartimos diversa informaci\u00f3n. Una de las partes m\u00e1s importantes de estas reuniones son los post-mortem, que a menudo van acompa\u00f1ados de una presentaci\u00f3n con diapositivas y un an\u00e1lisis m\u00e1s profundo del incidente ocurrido. Aunque no 'aplaudimos' tras los post-mortem, nos esforzamos por fomentar una cultura de 'sin culpa' (blameless culture<\/a><\/noindex>). Creemos que redactar y presentar informes post-mortem puede ayudarnos (y no solo a nosotros) a prevenir incidentes similares en el futuro, por eso los compartimos.<\/p>\n

Las personas involucradas en el incidente deben sentir que pueden contar en detalle sobre \u00e9l, sin temor a castigos o represalias. \u00a1Nada de reprensiones! Redactar un post-mortem no es un castigo, sino una oportunidad de aprendizaje para toda la empresa.<\/p>\n

Keep CALMS & DevOps: S es por Compartir<\/a><\/noindex><\/i><\/p><\/blockquote>\n

<\/p>\n

Problemas de DNS en Kubernetes. Informe post-mortem<\/h2>\n

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

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

Estado:<\/b> Concluido<\/p>\n

Resumen:<\/b> Interrupci\u00f3n parcial del DNS (26 min) para algunos servicios en el cl\u00faster de Kubernetes<\/p>\n

Impacto:<\/b> 15000 eventos perdidos para los servicios A, B y C<\/p>\n

Causa ra\u00edz:<\/b> Kube-proxy no pudo eliminar correctamente la antigua entrada de la tabla de conntrack, por lo que algunos servicios segu\u00edan intentando conectarse a pods inexistentes<\/p>\n

E0228 20:13:53.795782       1 proxier.go:610] Fall\u00f3 al eliminar kube-system\/kube-dns:dns endpoint connections, error: error al eliminar entradas de conntrack para el par UDP {100.64.0.10, 100.110.33.231}, error: el comando de conntrack devolvi\u00f3: ...<\/code><\/pre>\n
\nDetonante:<\/b> Debido a la baja carga dentro del cl\u00faster de Kubernetes, el CoreDNS-autoscaler redujo el n\u00famero de pods en el despliegue de tres a dos<\/p>\n
Soluci\u00f3n:<\/b> El \u00faltimo despliegue de la aplicaci\u00f3n inici\u00f3 la creaci\u00f3n de nuevos nodos, el CoreDNS-autoscaler agreg\u00f3 m\u00e1s pods para servir al cl\u00faster, lo que provoc\u00f3 la reescritura de la tabla de conntrack.<\/p>\n
Detecci\u00f3n:<\/b> La monitorizaci\u00f3n de Prometheus detect\u00f3 una gran cantidad de errores 5xx para los servicios A, B y C e inici\u00f3 una llamada a los ingenieros de guardia.<\/p>\n
\"Problemas
\nErrores 5xx en Kibana.<\/i><\/p>\n
Acciones<\/h3>\n
<\/p>\n
Acci\u00f3n
\nTipo
\nResponsable.
\nTarea<\/p>\n
Desactivar el autoescalador para CoreDNS.
\nprevenci\u00f3n.
\nAmet U.
\nDEVOPS-695.<\/p>\n
Instalar un servidor DNS con cach\u00e9.
\nreducir.
\nMax V.
\nDEVOPS-665.<\/p>\n
Configurar la monitorizaci\u00f3n de conntrack.
\nprevenci\u00f3n.
\nAmet U.
\nDEVOPS-674.<\/p>\n
<\/p>\n
Lecciones aprendidas.<\/h3>\n
\nLo que sali\u00f3 bien:<\/b><\/p>\n