Prim. prev.: to je prevod javnog postmortema iz inženjerskog bloga tvrtke . 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.

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.
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' (). 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.
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.

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 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
- Lepi 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' Smanjen replica set coredns-6cbb6646c9 na 2. - Linkovi na Kibanu (izrezano), Grafanu (izrezano)
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.

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:
- GitLab:
- Dropbox:
- Spotify:
- Številni drugi iz in repozitorija
- Takođe javnega postmortema s SRE knjigo
Izvor: habr.com
