Заўв. перав.: гэта пераклад публічнага постмартэма з інжынернага блога кампаніі . У ім апісваецца праблема з 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