Обратите внимание на перевод: Это перевод публичного заключения из инженерного блога компании.
Preply .
В нем описана проблема с conntrack в кластере Kubernetes, которая привела к частичному простою некоторых производственных сервисов.
Эта статья может быть полезна для тех, кто хочет узнать немного больше о вскрытиях или предотвратить некоторые потенциальные проблемы DNS в будущем.
Это не ДНС
Это не может быть DNS
Это был ДНС
Немного о постмортемах и процессах в Preply
Вскрытие описывает неисправность или какое-то событие в производстве.На еженедельных встречах с пиццерией среди технической команды мы делимся различной информацией.Вскрытие включает в себя хронологию событий, влияние пользователей, первопричину, предпринятые действия и извлеченные уроки.
Одной из важнейших частей таких встреч являются вскрытия, которые чаще всего сопровождаются презентацией со слайдами и более глубоким анализом происшествия.
Несмотря на то, что мы не аплодируем после вскрытия, мы пытаемся развивать культуру отсутствия вины ( безупречная культура ).
Мы считаем, что написание и представление результатов вскрытия может помочь нам (и другим людям) предотвратить подобные инциденты в будущем, поэтому мы делимся ими.
Лица, вовлеченные в инцидент, должны чувствовать, что они могут рассказать подробности, не опасаясь наказания или возмездия.Никакой вины! Написание вскрытие — это не наказание, а возможность обучения для всей компании.
Сохраняйте спокойствие и DevOps: S означает совместное использование
Проблемы с DNS в Kubernetes. Посмертное
Дата: 28.02.2020 Авторы: Амет Ю., Андрей С.
, Игорь К.
, Алексей П.
Положение дел: Законченный Кратко: Частичная недоступность DNS (26 минут) для некоторых сервисов в кластере Kubernetes. Влияние: Потеряно 15 000 событий для сервисов A, B и C Первопричина: Kube-proxy не смог правильно удалить старую запись из таблицы conntrack, поэтому некоторые сервисы все еще пытались подключиться к несуществующим подам.
Курок: За счет низкой нагрузки внутри кластера Kubernetes CoreDNS-автомасштабирование сократило количество подов в развертывании с трех до двух.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: .
Решение: Очередной развертывание приложения инициировало создание новых нод, CoreDNS-автомасштабер добавил больше подов для обслуживания кластера, что спровоцировало перезапись таблицы conntrack Обнаружение: Мониторинг Prometheus обнаружил большое количество ошибок 5xx для сервисов A, B и C и инициировал вызов дежурных инженеров.
5xx ошибок в Кибане
Действия
Действие Тип Ответственный Задача Отключить автомасштабирование для CoreDNS предотвращено Амет У.ДЕВОПС-695 Настройте кеширующий DNS-сервер снижаться Макс В.
ДЕВОПС-665 Настроить мониторинг conntrack предотвращено Амет У.
ДЕВОПС-674
Уроки выучены
Что прошло хорошо: Мониторинг работал хорошо.Реакция была быстрой и организованной Мы не превысили лимиты по узлам Что случилось: До сих пор неизвестна реальная первопричина, аналогичная конкретная ошибка в контакте Все действия исправляют только последствия, а не первопричину (ошибку) Мы знали, что рано или поздно у нас могут возникнуть проблемы с DNS, но не расставляли приоритеты в задачах.
Где нам повезло: Следующее развертывание было вызвано CoreDNS-autoscaler, который перезаписал таблицу conntrack.
Эта ошибка затронула только некоторые сервисы
Хронология (EET)
Время Действие 22:13 CoreDNS-автомасштабирование уменьшило количество подов с трёх до двух 22:18 Дежурным инженерам начали поступать звонки из системы мониторинга 22:21 Дежурные инженеры начали выяснять причину ошибок.22:39 Дежурные инженеры начали откатывать один из последних сервисов к предыдущей версии 22:40 Ошибки 5хх перестали появляться, ситуация стабилизировалась Время обнаружения: 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Ссылки на Кибану (вырезано), Графану (вырезано) Linux conntrack больше не ваш друг kube-proxy Тонкости: отладка прерывистого сброса соединения Racy conntrack и таймауты поиска DNS Чтобы минимизировать загрузку ЦП, ядро Linux использует нечто, называемое conntrack. Если кратко, то это утилита, содержащая список записей NAT, хранящихся в специальной таблице.
Когда следующий пакет придет от того же пода к тому же поду, что и раньше, конечный IP-адрес не будет пересчитываться, а будет взят из таблицы conntrack. 
Как работает контрек
Полученные результаты
Это был пример одного из наших постмортемов с некоторыми полезными ссылками.Конкретно в этой статье мы делимся информацией, которая может быть полезна другим компаниям.
Вот почему мы не боимся совершать ошибки и публикуем одно из наших вскрытий.
Вот еще несколько интересных публичных вскрытий: ГитЛаб: Анализ сбоя базы данных 31 января Дропбокс: Посмертное отключение Спотифай: Отношения любви/ненависти Spotify с DNS Многие другие из эта суть и репозиторий Истории неудач Kubernetes Также пример публичное вскрытие с помощью SRE Book Теги: #Kubernetes #DevOps #настройка Linux #postmortem #dns #conntrack
-
Открытый Исходный Код И Бизнес
19 Oct, 24 -
Интересные Международные События В Апреле
19 Oct, 24
