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

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

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

Это не 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 мин

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

• Логи 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

• Ссылки на Kibana (вырезано), Grafana (вырезано)
• Where Linux conntrack is no longer your friend
• kube-proxy Subtleties: Debugging an Intermittent Connection Reset
• Racy conntrack and DNS lookup timeouts

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

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

Итоги

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

• GitLab: Postmortem of database outage of January 31
• Dropbox: Outage post-mortem
• Spotify: Spotify’s Love/Hate Relationship with DNS
• Множество других из этого гиста и репозитория Kubernetes Failure Stories
• Также пример публичного постмортема с SRE Book

Источник: habr.com