Težave z DNS v Kubernetesu. Javni postmortem

Prim. prev.: to je prevod javnog postmortema iz inženjerskog bloga tvrtke Preply. U njemu se opisuje problem s conntrackom u Kubernetes klasteru koji je doveo do povremenog zastoja nekih produkcijskih servisa.

Ovaj članak može biti koristan onima koji žele saznati nešto više o postmortemima ili spriječiti neke potencijalne probleme s DNS-om u budućnosti.

Težave z DNS v Kubernetesu. Javni postmortem
To nije DNS
Ne može biti da je to DNS
To je bio DNS

Malo o postmortemima i procesima u Preply

U postmortemu se opisuje kvar u radu ili neki događaj u produkciji. Postmortem uključuje hronologiju događaja, opis utjecaja na korisnika, uzrok, akcije i naučene lekcije.

Seeking SRE

Na našim tjednim sastancima s pizzom, u krugu tehničkog tima, dijelimo razne informacije. Jedan od najvažnijih dijelova takvih sastanaka su postmortemi, koji obično dolaze s prezentacijom sa slajdovima i dubljom analizom doživljenog incidenta. Iako ne 'plješćemo' nakon postmortema, trudimo se razvijati kulturu 'bez prebacivanja' (blameless culture). Vjerujemo da pisanje i predstavljanje postmortema može pomoći nama (i ne samo nama) da spriječimo slične incidente u budućnosti, upravo zato ih i dijelimo.

Osobe uključene u incident trebaju osjetiti da mogu detaljno ispričati o tome, bez straha od kazne ili odmazde. Nema nikakvog prekoravanja! Pisanje postmortema nije kazna, već mogućnost učenja za cijelu tvrtku.

Keep CALMS & DevOps: S is for Sharing

Problemi s DNS-om u Kubernetesu. Postmortem

Datum: 28.02.2020

Avtorji: Amet U., Andrey S., Igor K., Alexey P.

Status: Završeno

Kratko: Djelomična nedostupnost DNS-a (26 min) za neke servise u Kubernetes klasteru

Utjecaj: 15000 događaja izgubljeno za servise A, B i C

Uzrok: Kube-proxy nije mogao ispravno ukloniti staru stavku iz conntrack tablice, tako da su neki servisi i dalje pokušavali povezati se s nepostojećim podovima

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

Okidač: Zbog niske opterećenosti unutar Kubernetes klastera, CoreDNS-autoscaler smanjio je broj podova u dispeju s tri na dva

Rešenje: Novi deploy aplikacije je pokrenuo kreiranje novih nodova, CoreDNS-autoscaler je dodao više podova za održavanje klastera, što je izazvalo prepisivanje conntrack tabele.

Otkriveno: Prometheus monitoring je otkrio veliki broj 5xx grešaka za servise A, B i C i pokrenuo poziv dežurnim inženjerima.

Težave z DNS v Kubernetesu. Javni postmortem
5xx greške u Kibani

Akcije

Akcija
Tip
Odgovorna osoba
Naloga

Isključiti autoskaler za CoreDNS
sprečiti.
Amet U.
DEVOPS-695

Postaviti keširajući DNS-server
smanjiti.
Maks V.
DEVOPS-665

Podesiti monitoring conntrack-a
sprečiti.
Amet U.
DEVOPS-674

Izvučene lekcije

Šta je bilo dobro:

  • Monitoring je radio efikasno. Reakcija je bila brza i organizovana.
  • Nismo naišli na nikakve limite na nodovima.

Šta nije bilo u redu:

  • Još uvek nepoznati stvarni uzrok, izgleda kao specifična greška. u conntrack-u.
  • Sve akcije ispravljaju samo posledice, ne i uzrok (grešku).
  • Znali smo da ćemo pre ili kasnije imati problema sa DNS-om, ali nismo prioritizovali zadatke.

Gde smo imali sreće:

  • Novi deploy je aktivirao CoreDNS-autoscaler, koji je prepisao conntrack tabelu.
  • Ova greška je zahvatila samo deo servisa.

Hronologija (EET)

Čas
Akcija

22:13
CoreDNS-autoscaler je smanjio broj podova sa tri na dva.

22:18
Dežurni inženjeri su počeli da dobijaju pozive od sistema monitoringa.

22:21
Dežurni inženjeri su počeli da istražuju uzrok grešaka.

22:39
Dežurni inženjeri su započeli vraćanje jednog od poslednjih servisa na prethodnu verziju.

22:40
5xx greške su prestale da se javljaju, situacija se stabilizovala.

  • Vreme do otkrivanja: 4 min
  • Vreme do preduzimanja akcija: 21 min
  • Vreme do ispravke: 1 min

Dodatne informacije

Kako bi se smanjila upotreba procesora, Linux kernel koristi nešto što se zove conntrack. U suštini, to je alat koji sadrži listu NAT zapisa, koji se čuvaju u posebnoj tabeli. Kada sledeći paket stigne iz iste pod grupe u isti pod kao ranije, krajnja IP adresa neće biti ponovo izračunata, već će biti uzeta iz conntrack tabele.
Težave z DNS v Kubernetesu. Javni postmortem
Kako funkcioniše conntrack

Zaključki

To je bil primer enega naših postmortemov z nekaterimi uporabnimi povezavami. Konkretno v tem članku delimo informacije, ki so lahko koristne tudi drugim podjetjem. Zato se ne bojimo narediti napak in zato smo enega naših postmortemov naredili javnega. Tukaj je še nekaj zanimivih javnih postmortemov:

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster