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

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

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

Това не е DNS
Не може да е DNS
Беше DNS

Малко за аутопсиите и процесите в Preply

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

Търсене на SRE

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

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

Keep CALMS & DevOps: S е за споделяне

Проблеми с DNS в Kubernetes. Посмъртно

Дата: 28.02.2020

Автори: Амет У., Андрей С., Игор К., Алексей П.

Състояние: Готово

накратко: Частична недостъпност на DNS (26 минути) за някои услуги в клъстера Kubernetes

Влияние: 15000 XNUMX загубени събития за услуги 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
предотвратено
Амет У.
ДЕВОПС-695

Настройте кеширащ DNS сървър
намаляване
Макс В.
ДЕВОПС-665

Настройте наблюдение на conntrack
предотвратено
Амет У.
ДЕВОПС-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 (cut), Grafana (cut)
• Където Linux conntrack вече не е ваш приятел
• Тънкости на kube-proxy: Отстраняване на грешки при нулиране на прекъсваща връзка
• Racy conntrack и изчакване за DNS търсене

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

Как работи conntrack

Резултати от

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

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

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