🥇Problémy s DNS v Kubernetes. Veřejný postmortem

Převod: toto je překlad veřejného postmortemu z inženýrského blogu společnosti Preply. V něm se popisuje problém s conntrack v Kubernetes clusteru, který vedl k částečné nedostupnosti některých produkčních služeb.

Tento článek může být užitečný pro ty, kteří se chtějí dozvědět více o postmortemech nebo chtějí předejít některým potenciálním problémům s DNS v budoucnosti.

To není DNS
Nemůže to být DNS
To byl DNS

Něco o postmortemech a procesech v Preply

V postmortemu se popisuje selhání nebo nějaká událost v produkci. Postmortem zahrnuje chronologii událostí, popis dopadu na uživatele, prvotní příčinu, akce a poučení.
Hledání SRE

Na týdenních schůzkách s pizzou, v rámci technického týmu, sdílíme různé informace. Jednou z nejdůležitějších částí těchto schůzek jsou postmortemy, které jsou často doprovázeny prezentací se slajdy a hlubší analýzou proběhlé události. I když po postmortemech nemáme 'potlesk', snažíme se rozvíjet kulturu 'bez obviňování' (blameless culture). Věříme, že psaní a prezentace postmortemů nám (a nejen nám) může pomoci v prevenci podobných incidentů v budoucnosti, a proto je sdílíme.

Osoby zapojené do incidentu by měly cítit, že mohou podrobně vyprávět o něm, aniž by se obávaly trestu nebo odplaty. Žádné pokárání! Psaní postmortemu není trest, ale příležitost k učení pro celou společnost.
Keep CALMS & DevOps: S je pro sdílení

Problémy s DNS v Kubernetes. Postmortem

Datum: 28.02.2020

Autoři: Amet U., Andrej S., Igor K., Alexej P.

Stav: Dokončeno

Stručně: Částečná nedostupnost DNS (26 min) pro některé služby v Kubernetes clusteru

Dopad: 15000 událostí ztraceno pro služby A, B a C

Prvotní příčina: Kube-proxy nedokázal správně odstranit starý záznam z tabulky conntrack, takže některé služby se stále pokoušely spojit s neexistujícími pody

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: ...

Spouštěč: V důsledku nízké zátěže uvnitř Kubernetes clusteru, CoreDNS-autoscaler snížil počet podů v nasazení z tří na dvě

Řešení: Další nasazení aplikace vyvolalo vytvoření nových uzlů, CoreDNS-autoscaler přidal více podů pro obsluhu klastra, což vedlo k přepsání tabulky conntrack.

Zjištění: Monitorování Prometheus zjistilo velké množství chyb 5xx pro služby A, B a C a vyvolalo telefonát pohotovostním inženýrům.

Chyby 5xx v Kibana.

Akce

Činnost
Typ
Odpovědný
Úkol

Vypnout autoskaler pro CoreDNS.
prevence.
Amet U.
DEVOPS-695

Nastavit cachující DNS server.
snížit.
Max V.
DEVOPS-665

Nastavit monitorování conntrack.
prevence.
Amet U.
DEVOPS-674

Získané lekce

Co šlo dobře:

Monitorování fungovalo přesně. Reakce byla rychlá a organizovaná.
Nepřekročili jsme žádné limity na uzlech.

Co bylo špatně:

Skutečná příčina stále není známa, vypadá to na specifickou chybu. v conntrack.
Všechny akce opravují pouze následky, nikoli příčinu (chybu).
Věděli jsme, že dříve či později budeme mít problémy s DNS, ale úkoly jsme nepřipravili jako prioritu.

Kde jsme měli štěstí:

Další nasazení spustilo CoreDNS-autoscaler, který přepsal tabulku conntrack.
Tato chyba zasáhla pouze část služeb.

Chronologie (EET)

Čas
Činnost

22:13
CoreDNS-autoscaler snížil počet podů ze tří na dva.

22:18
Pohotovostní inženýři začali dostávat telefonáty od monitorovacího systému.

22:21
Pohotovostní inženýři začali zjišťovat příčinu chyb.

22:39
Pohotovostní inženýři začali vracet jednu z posledních verzí služeb na předchozí verzi.

22:40
Chyby 5xx přestaly objevovat, situace se stabilizovala.

Čas do zjištění: 4 min
Čas do provedení akcí: 21 min
Čas do opravy: 1 min

Další informace

Logy CoreDNS:

I0228 20:13:53.507780       1 event.go:221] Událost(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): typ: 'Normal' důvod: 'ScalingReplicaSet' Zmenšeno replikované množství coredns-6cbb6646c9 na 2.

Odkazy na Kibana (výřez), Grafana (výřez).
Kde Linux conntrack už není vaším přítelem.
Zádrhele kube-proxy: ladění příležitostného obnovení připojení.
Chybné conntrack a časové limity DNS vyhledávání.

Aby se minimalizovalo využití procesoru, jádro Linuxu používá něco jako conntrack. Pokud to shrneme, jedná se o nástroj, který obsahuje seznam NAT záznamů, které jsou uchovávány ve speciální tabulce. Když následující paket přichází ze stejného podu do stejného podu jako dříve, cílová IP adresa nebude znovu vypočítána, ale bude převezena z tabulky conntrack.

Jak funguje conntrack.

Závěry

Toto byl příklad jednoho z našich postmortemů s několika užitečnými odkazy. V tomto článku sdílíme informace, které mohou být užitečné i jiným společnostem. Proto se nebojíme dělat chyby a proto jsme jeden z našich postmortemů udělali veřejným. Zde je několik dalších zajímavých veřejných postmortemů: