Kubernetes жүйесінде DNS ақаулары. Қоғамдық өлімнен кейінгі

Ескерту аударма: Бұл компанияның инженерлік блогындағы жалпыға ортақ өлімнен кейінгі жазбаның аудармасы Алдын ала. Ол Kubernetes кластеріндегі қосылу мәселесін сипаттайды, бұл кейбір өндірістік қызметтердің ішінара тоқтап қалуына әкелді.

Бұл мақала постмортемдер туралы көбірек білгісі келетіндерге немесе болашақта кейбір ықтимал DNS ақауларының алдын алғысы келетіндерге пайдалы болуы мүмкін.

Бұл DNS емес
Бұл DNS болуы мүмкін емес
Бұл DNS болды

Preply-дегі өлімнен кейінгі және процестер туралы аздап

Өлімнен кейінгі ақаулық немесе өндірістегі қандай да бір оқиғаны сипаттайды. Өлімнен кейінгі кезең оқиғалардың уақыт кестесін, пайдаланушының әсерін, негізгі себебін, қабылданған әрекеттерді және алынған сабақтарды қамтиды.

SRE іздейді

Пиццамен апта сайынғы кездесулерде техникалық топ арасында біз әртүрлі ақпараттармен бөлісеміз. Мұндай кездесулердің ең маңызды бөліктерінің бірі - көбінесе слайдтармен презентациямен және оқиғаны тереңірек талдаумен сүйемелденетін постмортемдер. Біз өлгеннен кейін қол шапалақтамасақ та, «кінә жоқ» мәдениетін дамытуға тырысамыз (мінсіз мәдениет). Өлімнен кейінгі мәліметтерді жазу және ұсыну бізге (және басқаларға) болашақта осындай оқиғалардың алдын алуға көмектеседі деп сенеміз, сондықтан біз оларды бөлісеміз.

Оқиғаға қатысы бар адамдар жазадан немесе жазадан қорықпай егжей-тегжейлі айта алатынын сезінуі керек. Айып жоқ! Постмортем жазу - бұл жаза емес, бүкіл компания үшін оқу мүмкіндігі.

Keep CALMS & DevOps: S ортақ пайдалануға арналған

Kubernetes жүйесінде DNS ақаулары. Өлімнен кейінгі

Күні: 28.02.2020

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

Мәртебесі: Аяқталды

Қысқаша: Kubernetes кластеріндегі кейбір қызметтер үшін жартылай DNS қолжетімсіздігі (26 мин).

Әсері: A, B және C қызметтері үшін жоғалған 15000 XNUMX оқиға

Түбірлі себеп: Kube-proxy қосылым кестесінен ескі жазбаны дұрыс жоя алмады, сондықтан кейбір қызметтер әлі де жоқ подкасттарға қосылуға әрекеттенді.

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-автомасштабтаушысы орналастырудағы подкасттардың санын үштен екіге дейін қысқартты.

шешім: Қолданбаның келесі қолдануы жаңа түйіндерді құруды бастады, CoreDNS-автомасштабтаушысы кластерге қызмет көрсету үшін қосымша подкасттарды қосты, бұл conntrack кестесін қайта жазуды тудырды.

Анықтау: Prometheus мониторингі A, B және C қызметтері үшін көптеген 5xx қателерін анықтады және кезекші инженерлерге қоңырау шалды.

Кибанадағы 5xx қатесі

Әрекеттер

әсер
Түрі
Жауапты
Мақсаты

CoreDNS үшін автоматты масштабтауды өшіріңіз
алдын алды
Әмет У.
DEVOPS-695

Кэштеу DNS серверін орнату
төмендеуі
Макс В.
DEVOPS-665

Контракт мониторингін орнату
алдын алды
Әмет У.
DEVOPS-674

Сабақтар

Не жақсы өтті:

• Мониторинг жақсы нәтиже берді. Жауап жылдам әрі ұйымшыл болды
• Біз түйіндерге ешқандай шектеулер қойған жоқпыз

Не болды:

• Осыған ұқсас нақты түпкі себебі әлі белгісіз арнайы қате қарсы
• Барлық әрекеттер түпкі себебін емес, тек салдарын түзетеді (қате)
• Біз ерте ме, кеш пе, DNS-ке қатысты проблемалар болуы мүмкін екенін білдік, бірақ біз тапсырмаларды бірінші орынға қоймадық

Бізге сәттілік қай жерде:

• Келесі орналастыруды қосу кестесінің үстінен жазған CoreDNS-автомасштабтаушысы іске қосты.
• Бұл қате кейбір қызметтерге ғана әсер етті

Хронология (EET)

Время
әсер

22:13
CoreDNS-автомасштабтауыш қосқыштар санын үштен екіге дейін қысқартты

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

• Кибана (кесілген), Графана (кесілген) сілтемелері
• Linux conntrack енді сіздің досыңыз емес
• kube-proxy нәзіктіктері: үзіліссіз қосылымды қалпына келтіруді түзету
• Racy conntrack және DNS іздеу күту уақыттары

Орталық процессорды пайдалануды азайту үшін Linux ядросы conntrack деп аталатын нәрсені пайдаланады. Қысқаша айтқанда, бұл арнайы кестеде сақталатын NAT жазбаларының тізімін қамтитын қызметтік бағдарлама. Келесі пакет бұрынғыдай бір подкастқа келген кезде, соңғы IP мекенжайы қайта есептелмейді, бірақ conntrack кестесінен алынады.

Conntrack қалай жұмыс істейді

Нәтижелері

Бұл кейбір пайдалы сілтемелері бар біздің постмортемдердің бірінің мысалы болды. Атап айтқанда, осы мақалада біз басқа компанияларға пайдалы болуы мүмкін ақпаратты бөлісеміз. Сондықтан біз қателесуден қорықпаймыз және сол себепті біз өлгеннен кейінгі зерттеулеріміздің бірін көпшілікке жария етеміз. Міне, бірнеше қызықты қоғамдық өлімнен кейінгі зерттеулер:

• GitLab: 31 қаңтарда деректер базасының тоқтатылуынан кейінгі өлім
• Dropbox: Өлімнен кейінгі үзіліс
• Spotify: Spotify-дың DNS-мен махаббат/жек көрушілік қатынасы
• Көптеген басқалардан бұл түйін және репозиторий Kubernetes сәтсіз оқиғалары
• Сондай-ақ, мысал SRE кітабымен өлімнен кейінгі жария

Ақпарат көзі: www.habr.com