Pozn. prekl.: Toto je preklad verejného postmortemu z inžinierskeho blogu spoločnosti . Popisuje problém s conntrack v Kubernetes klastri, ktorý viedol k čiastočnému výpadku niektorých produkčných služieb.
Tento článok môže byť užitočný pre tých, ktorí sa chcú dozvedieť viac o postmortemoch alebo predísť niektorým potenciálnym problémom s DNS v budúcnosti.
To nie je DNS
Nemôže to byť DNS
To bol DNS
Trocha o postmortemoch a procesoch v Preply
V postmorteme je popísaný výpadok v prevádzke alebo nejaká udalosť v produkcii. Postmortem obsahuje chronológiu udalostí, popis vplyvu na používateľov, prvotnú príčinu, opatrenia a získané ponaučenia.
Na našich týždenných stretnutiach s pizzou, v kruhu technického tímu, zdieľame rôzne informácie. Jednou z najdôležitejších častí takýchto stretnutí sú postmortemy, ktoré zvyčajne sprevádza prezentácia so snímkami a hĺbkovou analýzou udalosti. Napriek tomu, že po postmortemoch neapplaudujeme, snažíme sa podporovať kultúru bez obviňovania (). Veríme, že písanie a prezentácia postmortemov nám (a nielen nám) môže pomôcť predchádzať podobným incidentom v budúcnosti, a preto sa o ne delíme.
Osoby zapojené do incidentu by mali cítiť, že môžu podrobne hovoriť o ňom bez strachu z trestu alebo odvety. Žiadne odmietanie! Písanie postmortemu nie je trest, ale možnosť vzdelávania pre celú spoločnosť.
Problémy s DNS v Kubernetes. Postmortem
Dátum: 28.02.2020
Autori: Amet U., Andrej S., Igor K., Alexej P.
Stav: Ukončené
Stručne: Čiastočná nedostupnosť DNS (26 min) pre niektoré služby v Kubernetes klastri
Vplyv: 15 000 udalostí stratilo pre služby A, B a C
Prvotná príčina: Kube-proxy sa nedokázal správne zbaviť starej položky z tabuľky conntrack, a preto sa niektoré služby stále pokúšali pripojiť k neexistujúcim podom.
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: ...Spúšťač: V dôsledku nízkej záťaže vnútri Kubernetes klastra, CoreDNS-autoscaler znížil počet podov v nasadení z troch na dva.
Riešenie: Nové nasadenie aplikácie iniciovalo vytvorenie nových uzlov, CoreDNS-autoscaler pridal viac podov na obsluhu klastra, čo vyvolalo prepisovanie tabuľky conntrack
Zistenie: Monitoring Prometheus zistil vysoký počet 5xx chýb pre služby A, B a C a inicioval výzvu pre pohotovostných inžinierov
5xx chyby v Kibana
Akcie
Akcia
Typ
Zodpovedný
Úloha
Deaktivovať autoskaler pre CoreDNS
prevencia
Amet U.
DEVOPS-695
Nastaviť caching DNS server
znížiť
Max V.
DEVOPS-665
Nastaviť monitoring conntrack
prevencia
Amet U.
DEVOPS-674
Získané ponaučenia
Čo išlo dobre:
- Monitoring fungoval presne. Reakcia bola rýchla a organizovaná
- Nepotýkali sme sa s žiadnymi limitmi na uzloch
Čo bolo zlé:
- Stále neznáma reálna príčina, vyzerá to na v conntrack
- Všetky akcie opravujú iba následky, nie príčinu (chybu)
- Vedeli sme, že skôr alebo neskôr môžeme mať problémy s DNS, ale nezprioritizovali sme úlohy
Kde sme mali šťastie:
- Nové nasadenie spustilo CoreDNS-autoscaler, ktorý prepísal tabuľku conntrack
- Táto chyba zasiahla iba časť služieb
Chronológia (EET)
Čas
Akcia
22:13
CoreDNS-autoscaler znížil počet podov z troch na dva
22:18
Pohotovostní inžinieri začali dostávať výzvy od monitorovacieho systému
22:21
Pohotovostní inžinieri začali zisťovať príčinu chýb
22:39
Pohotovostní inžinieri začali vracať jednu z posledných služieb na predchádzajúcu verziu
22:40
5xx chyby prestali objavovať, situácia sa stabilizovala
- Čas do zistenia: 4 min
- Čas do vykonania akcií: 21 min
- Čas do opravy: 1 min
Ďalšie informácie
- Logy 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' Zmenený replica set coredns-6cbb6646c9 na 2 - Odkazy na Kibana (vymazané), Grafana (vymazané)
Aby sa minimalizovalo využitie CPU, jadro Linuxu používa niečo, ako je conntrack. V skratke, je to nástroj, ktorý obsahuje zoznam NAT záznamov, ktoré sú uložené v špeciálnej tabuľke. Keď ďalší paket prichádza z toho istého podu do toho istého podu ako predtým, koncová IP adresa sa nanovo nepočítava, ale berie sa z tabuľky conntrack.
Ako funguje conntrack
Zhrnutie
Toto bol príklad jedného z našich postmortemov s niektorými užitočnými odkazmi. Konkrétne v tomto článku zdieľame informácie, ktoré môžu byť prospešné iným spoločnostiam. Preto sa nebojíme robiť chyby a preto robíme jeden z našich postmortemov verejným. Tu je niekoľko ďalších zaujímavých verejných postmortemov:
- GitLab:
- Dropbox:
- Spotify:
- Množstvo ďalších z a repozitára
- Takisto verejného postmortemu s SRE Book
Zdroj: habr.com
