Прим. перев.: это перевод публичного постмортема из инженерного блога компании Preply. В нем описывается проблема с conntrack в Kubernetes-кластере, которая привела к частичному простою некоторых сервисов продакшна.
Данная статья может быть полезной тем, кто хочет узнать немного больше о постмортемах или предотвратить некоторые потенциальные проблемы с DNS в будущем.
Это не DNS
Не может быть что это DNS
Это был DNS
На еженедельных совещаниях с пиццей, в кругу технической команды, мы делимся различной информаций. Одной из важнейшних частей таких совещаний являются постмортемы, которые чаще всего сопровождаются презентацией со слайдами и более глубоким анализом произошедшего инцидента. Несмотря на то, что мы не «хлопаем» после постмортемов, мы стараемся развивать культуру «без упреков» (blameless cluture). Мы верим в то, что написание и представление постмортемов может помочь нам (и не только) в предотвращении подобных инцидентов в будущем, именно поэтому мы и делимся ими.
Дата: 28.02.2020
Авторы: Амет У., Андрей С., Игорь К., Алексей П.
Статус: Законченный
Кратко: Частичная недоступность DNS (26 мин) для некоторых сервисов в Kubernetes-кластере
Влияние: 15000 событий потеряно для сервисов A, B и C
Первопричина: Kube-proxy не смог корректно удалить старую запись из таблицы conntrack, поэтому некоторые сервисы все еще пытались соединиться к несуществующим подам
Триггер: Из-за низкой нагрузки внутри Kubernetes-кластера, CoreDNS-autoscaler уменьшил количество подов в деплойменте с трех до двух
Решение: Очередной деплой приложения инициировал создание новых нод, CoreDNS-autoscaler добавил больше подов для обслуживания кластера, что спровоцировало перезапись таблицы conntrack
Обнаружение: Prometheus мониторинг обнаружил большое количество 5xx ошибок для сервисов A, B и C и инициировал звонок дежурным инженерам
5xx ошибки в Kibana
Что пошло хорошо:
Что было не так:
Где нам повезло:
Для минимизации использования процессора, ядро Linux использует такую штуку как conntrack. Если кратко, то это утилита, которая содержит список NAT-записей, которые хранятся в специальной таблице. Когда следующий пакет приходит из того же пода в тот же под что и раньше, конечный IP-адрес не будет рассчитан заново, а будет взят из таблицы conntrack.
Как работает conntrack
Это был пример одного из наших постмортемов с некоторыми полезными ссылками. Конкретно в этой статье мы делимся информацией, которая может быть полезна другим компаниям. Вот почему мы не боимся совершать ошибок и вот почему мы сделать один из наших постмортемов публичным. Вот еще несколько интересных публичных постмортемов:
Данная статья может быть полезной тем, кто хочет узнать немного больше о постмортемах или предотвратить некоторые потенциальные проблемы с 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
