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

Прим. прев.: това е превод на публичен постмортем от инженерния блог на компанията Preply. В него се описва проблем с conntrack в Kubernetes клъстера, който доведе до частично спиране на някои производствени услуги.

Тази статия може да бъде полезна за тези, които искат да научат малко повече за постмортемите или да предотвратят някои потенциални проблеми с DNS в бъдеще.

Това не е DNS
Не може да бъде, че е DNS
Това беше DNS

Няколко думи за постмортемите и процесите в Preply

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

Търсене на SRE

На седмичните събирания с пица, в компанията на техническия екип, споделяме различна информация. Една от най-важните части на тези срещи са постмортемите, които по-често са съпроводени от презентация със слайдове и по-дълбок анализ на настъпилото събитие. Въпреки че не „аплодираме“ след постмортемите, се стремим да развием култура без укори (blameless culture). Вярваме, че записването и представянето на постмортеми може да ни помогне (и не само) да предотвратим подобни инциденти в бъдеще, именно поради тази причина ги споделяме.

Лицата, участващи в инцидента, трябва да чувстват, че могат подробно да разкажат за него, без да се страхуват от наказание или отмъщение. Никакво укоряване! Записването на постмортем е не наказание, а възможност за обучение за цялата компания.

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' Скалированието на реплика сет coredns-6cbb6646c9 до 2.

• Връзки до Kibana (изрязано), Grafana (изрязано).
• Където Linux conntrack вече не е твой приятел.
• Финни детайли за kube-proxy: Отстраняване на проблеми с интермитентни нулирания на връзки.
• Проблеми с conntrack и таймаути при DNS търсене.

За минимизиране на използването на процесора, ядрото на Linux използва нещо, наречено conntrack. Ако накратко, това е утилита, която съдържа списък с NAT записи, хранящи се в специална таблица. Когато следващият пакет идва от същия под към същия под както преди, крайната IP адрес не ще бъде пресметнат отново, а ще бъде взет от таблицата conntrack.

Как работи conntrack.

Резюме

Това беше пример за един от нашите постмортеми с някои полезни връзки. Конкретно в тази статия споделяме информация, която може да бъде полезна на други компании. Затова не се страхуваме да правим грешки и затова решихме да направим един от нашите постмортеми публичен. Ето още няколко интересни публични постмортеми:

• GitLab: Постмортем на извънредно положение в базата данни от 31 януари
• Dropbox: Постмортем на извънредно положение
• Spotify: Любовно/Ненавистно отношение на Spotify с DNS
• Множество други от този гист и репозитория Истории на провали в Kubernetes
• Също така пример публичния постмортем с SRE Book

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