Pull to refresh

Проблемы с DNS в Kubernetes. Публичный постмортем

Configuring LinuxDNSDevOpsKubernetes
Translation
Original author: Amet Umerov
Прим. перев.: это перевод публичного постмортема из инженерного блога компании Preply. В нем описывается проблема с conntrack в Kubernetes-кластере, которая привела к частичному простою некоторых сервисов продакшна.

Данная статья может быть полезной тем, кто хочет узнать немного больше о постмортемах или предотвратить некоторые потенциальные проблемы с DNS в будущем.

image

Это не DNS
Не может быть что это DNS
Это был DNS


Немного о постмортемах и процессах в Preply


В постмортеме описывается сбой в работе или какое-либо событие в продашкне. Постмортем включает в себя хронологию событий, описание воздействия на пользователя, первопричину, действия и извлеченные уроки.

Seeking SRE

На еженедельных совещаниях с пиццей, в кругу технической команды, мы делимся различной информаций. Одной из важнейшних частей таких совещаний являются постмортемы, которые чаще всего сопровождаются презентацией со слайдами и более глубоким анализом произошедшего инцидента. Несмотря на то, что мы не «хлопаем» после постмортемов, мы стараемся развивать культуру «без упреков» (blameless cluture). Мы верим в то, что написание и представление постмортемов может помочь нам (и не только) в предотвращении подобных инцидентов в будущем, именно поэтому мы и делимся ими.

Лица, вовлеченные в инцидент, должны чувствовать, что они могут подробно рассказать о нем, не опасаясь наказания или возмездия. Никакого порицания! Написание постмортема — это не наказание, а возможность обучения для всей компании.

Keep CALMS & DevOps: S is for Sharing

Проблемы с DNS в Kubernetes. Постмортем


Дата: 28.02.2020

Авторы: Амет У., Андрей С., Игорь К., Алексей П.

Статус: Законченный

Кратко: Частичная недоступность DNS (26 мин) для некоторых сервисов в Kubernetes-кластере

Влияние: 15000 событий потеряно для сервисов A, B и C

Первопричина: Kube-proxy не смог корректно удалить старую запись из таблицы conntrack, поэтому некоторые сервисы все еще пытались соединиться к несуществующим подам
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: ...

Триггер: Из-за низкой нагрузки внутри Kubernetes-кластера, CoreDNS-autoscaler уменьшил количество подов в деплойменте с трех до двух

Решение: Очередной деплой приложения инициировал создание новых нод, CoreDNS-autoscaler добавил больше подов для обслуживания кластера, что спровоцировало перезапись таблицы conntrack

Обнаружение: Prometheus мониторинг обнаружил большое количество 5xx ошибок для сервисов A, B и C и инициировал звонок дежурным инженерам


5xx ошибки в Kibana

Действия


Действие Тип Ответственный Задача
Отключить автоскейлер для CoreDNS предотвр. Амет У. DEVOPS-695
Установить кеширующий DNS-сервер уменьш. Макс В. DEVOPS-665
Настроить мониторинг conntrack предотвр. Амет У. DEVOPS-674

Извлеченные уроки


Что пошло хорошо:

  • Мониторинг сработал четко. Реакция была быстрой и организованной
  • Мы не уперлись ни в какие лимиты на нодах


Что было не так:

  • Все еще неизвестная реальная первопричина, похоже на специфический баг в conntrack
  • Все действия исправляют только последствия, не первопричину (баг)
  • Мы знали, что рано или поздно у нас могут быть проблемы с DNS, но не приоритизировали задачи

Где нам повезло:

  • Очередной деплой затриггерил CoreDNS-autoscaler, который перезаписал таблицу conntrack
  • Данный баг затронул только часть сервисов

Хронология (EET)


Время Действие
22:13 CoreDNS-autoscaler уменьшил число подов с трех до двух
22:18 Дежурные инженеры стали получать звонки от системы мониторинга
22:21 Дежурные инженеры начали выяснять причину ошибок
22:39 Дежурные инженеры начали откатывать один из последних сервисов на предыдущую версию
22:40 5xx ошибки перестали появляться, ситуация стабилизировалась

  • Время до обнаружения: 4 мин
  • Время до совершения действий: 21 мин
  • Время до исправления: 1 мин

Дополнительная информация



Для минимизации использования процессора, ядро Linux использует такую штуку как conntrack. Если кратко, то это утилита, которая содержит список NAT-записей, которые хранятся в специальной таблице. Когда следующий пакет приходит из того же пода в тот же под что и раньше, конечный IP-адрес не будет рассчитан заново, а будет взят из таблицы conntrack.

Как работает conntrack

Итоги


Это был пример одного из наших постмортемов с некоторыми полезными ссылками. Конкретно в этой статье мы делимся информацией, которая может быть полезна другим компаниям. Вот почему мы не боимся совершать ошибок и вот почему мы сделать один из наших постмортемов публичным. Вот еще несколько интересных публичных постмортемов:

Tags:dnskubernetesconntrackpostmortemdevops
Hubs: Configuring Linux DNS DevOps Kubernetes
Total votes 6: ↑5 and ↓1 +4
Views3.1K

Popular right now

Top of the last 24 hours