Прим. перекл.: це переклад публічного постмортему з інженерного блогу компанії . У ньому описується проблема з conntrack у Kubernetes-кластері, яка призвела до часткового простою деяких сервісів продакшну.
Ця стаття може бути корисною тим, хто хоче дізнатися трохи більше про постмортеми або запобігти деяким потенційним проблемам з DNS в майбутньому.
Це не DNS
Не може бути, що це DNS
Це був DNS
Трохи про постмортеми та процеси в Preply
У постмортемі описується збій у роботі або будь-яка подія у продашкні. Постмортем включає хронологію подій, опис впливу на користувача, першопричину, дії і викладені уроки.
На щотижневих нарадах з піцою, у колі технічної команди, ми ділимося різною інформацією. Однією з найважливіших частин таких нарад є постмортеми, які найчастіше супроводжуються презентацією зі слайдами та глибшим аналізом інциденту. Незважаючи на те, що ми не «плескаємо» після постмортемів, ми намагаємося розвивати культуру «без докорів» (). Ми віримо в те, що написання та представлення постмортемів може допомогти нам (і не тільки) у запобіганні подібним інцидентам у майбутньому, саме тому ми й ділимося ними.
Особи, залучені до інциденту, повинні відчувати, що вони можуть докладно розповісти про нього, не побоюючись покарання чи відплати. Жодного осуду! Написання постмортему - це не покарання, а можливість навчання для всієї компанії.
Проблеми з 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 (вирізано)
Для мінімізації використання процесора ядро Linux використовує таку штуку як conntrack. Якщо коротко, це утиліта, що містить список NAT-записів, які зберігаються у спеціальній таблиці. Коли наступний пакет приходить з того ж пода в той же під що і раніше, кінцева IP-адреса не буде розрахована заново, а буде взята з таблиці conntrack.
Як працює conntrack
Підсумки
Це був приклад одного з наших постмортемів із деякими корисними посиланнями. Саме в цій статті ми ділимося інформацією, яка може бути корисною іншим компаніям. Ось чому ми не боїмося робити помилок і ось чому ми зробити один із наших постмортемів публічним. Ось ще кілька цікавих публічних постмортемів:
- GitLab:
- Dropbox:
- Spotify:
- Безліч інших з та репозиторія
- Також публічного постмортему із SRE Book
Джерело: habr.com