Poznámka. překlad: Toto je překlad veřejné pitvy z inženýrského blogu společnosti . Popisuje problém s conntrackem v clusteru Kubernetes, který vedl k částečnému výpadku 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 něco více o pitvě nebo předejít některým potenciálním problémům s DNS v budoucnu.
Toto není DNS
Nemůže to být DNS
Byl to DNS
Něco málo o pitvách a procesech v Preply
Postmortem popisuje poruchu nebo nějakou událost ve výrobě. Postmortem zahrnuje časovou osu událostí, dopad na uživatele, hlavní příčinu, přijatá opatření a poučení.
Na týdenních schůzkách s pizzou mezi technickým týmem sdílíme různé informace. Jednou z nejdůležitějších částí takových setkání jsou pitvy, které jsou nejčastěji doprovázeny prezentací s diapozitivy a hlubší analýzou incidentu. I když po posmrtných akcích netleskáme, snažíme se rozvíjet kulturu „bez viny“ (). Věříme, že psaní a předkládání posmrtných zpráv nám (i ostatním) může pomoci předcházet podobným incidentům v budoucnu, a proto je sdílíme.
Jednotlivci zapojení do incidentu by měli mít pocit, že mohou mluvit podrobně bez strachu z trestu nebo odplaty. Žádná vina! Psaní pitvy není trestem, ale příležitostí k učení pro celou společnost.
Problémy s DNS v Kubernetes. Postmortem
Дата: 28.02.2020
Autoři: Amet U., Andrey S., Igor K., Alexey P.
Status: Hotovo
Stručně: Částečná nedostupnost DNS (26 min) pro některé služby v clusteru Kubernetes
Dopad: 15000 XNUMX ztracených událostí pro služby A, B a C
Příčina: Kube-proxy nedokázal správně odstranit starou položku z tabulky conntrack, takže se některé služby stále pokoušely připojit k neexistujícím modulům
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šť: Kvůli nízké zátěži uvnitř clusteru Kubernetes snížil CoreDNS-autoscaler počet modulů v nasazení ze tří na dva.
řešení: Další nasazení aplikace iniciovalo vytváření nových uzlů, CoreDNS-autoscaler přidal další moduly pro obsluhu clusteru, což vyvolalo přepsání tabulky conntrack.
Detekce: Monitoring Prometheus zjistil velký počet chyb 5xx pro služby A, B a C a inicioval volání techniků ve službě
5xx chyb v Kibaně
Činnost
účinek
Typ
Odpovědný
Úkol
Zakázat automatické škálování pro CoreDNS
zabráněno
Amet U.
DEVOPS-695
Nastavte server DNS pro ukládání do mezipaměti
pokles
Max V.
DEVOPS-665
Nastavte sledování conntrack
zabráněno
Amet U.
DEVOPS-674
Ponaučení
Co se povedlo:
- Monitoring fungoval dobře. Odezva byla rychlá a organizovaná
- U uzlů jsme nenarazili na žádné limity
Co bylo špatně:
- Stále neznámá skutečná základní příčina, podobná v conntrack
- Všechny akce opravují pouze následky, nikoli hlavní příčinu (chybu)
- Věděli jsme, že dříve nebo později můžeme mít problémy s DNS, ale nestanovili jsme priority
Kde jsme měli štěstí:
- Další nasazení spustil CoreDNS-autoscaler, který přepsal tabulku conntrack
- Tato chyba ovlivnila pouze některé služby
Časová osa (EET)
čas
účinek
22:13
CoreDNS-autoscaler snížil počet modulů ze tří na dva
22:18
Inženýři ve službě začali přijímat hovory z monitorovacího systému
22:21
Inženýři ve službě začali zjišťovat příčinu chyb.
22:39
Inženýři ve službě začali jednu z nejnovějších služeb vrátit na předchozí verzi
22:40
Chyby 5xx se přestaly objevovat, situace se stabilizovala
- Čas do detekce: 4 minut
- Čas před akcí: 21 minut
- Čas na opravu: 1 minut
doplňující informace
- Protokoly 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 - Odkazy na Kibana (střih), Grafana (střih)
Для минимизации использования процессора, ядро Linux использует такую штуку как conntrack. Если кратко, то это утилита, которая содержит список NAT-записей, которые хранятся в специальной таблице. Когда следующий пакет приходит из того же пода в тот же под что и раньше, конечный IP-адрес не будет рассчитан заново, а будет взят из таблицы conntrack.
Jak conntrack funguje
Výsledky
Toto byl příklad jedné z našich pitev s několika užitečnými odkazy. Konkrétně v tomto článku sdílíme informace, které mohou být užitečné pro jiné společnosti. Proto se nebojíme dělat chyby a proto zveřejňujeme jednu z našich pitev. Zde jsou některé další zajímavé veřejné pitvy:
- GitLab:
- Dropbox:
- Spotify:
- Mnoho dalších z a úložiště
- Také veřejná pitva s knihou SRE
Zdroj: www.habr.com
