🥇Problemi s DNS-om u Kubernetesu. Javni postmortem

Napomena prevoda: ovo je prijevod javnog postmortema iz inženjerskog bloga kompanije Preply. U njemu se opisuje problem s conntrack u Kubernetes klasteru, koji je doveo do privremenog zastoja nekih produkcijskih usluga.

Ovaj članak može biti koristan onima koji žele saznati malo 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 kronologiju događaja, opis utjecaja na korisnike, osnovni uzrok, akcije i naučene lekcije.
Seeking SRE

Na tjednim sastancima uz pizzu, u krugu tehničkog tima, dijelimo razne informacije. Jedan od najvažnijih dijelova takvih sastanaka su postmortemi, koji najčešće dolaze s prezentacijom i dubljom analizom događaja. Iako ne „apludiramo“ nakon postmortema, nastojimo razviti kulturu „bez optuživanja“ (blameless culture). Vjerujemo da pisanje i predstavljanje postmortema može pomoći nama (i ne samo nama) u sprječavanju sličnih incidenata u budućnosti, zato ih i dijelimo.

Osobe uključene u incident trebaju osjećati da mogu detaljno ispričati o njemu, ne bojeći se kazne ili odmazde. Nema osuđivanja! Pisanje postmortema nije kazna, nego prilika za učenje za cijelu kompaniju.
Keep CALMS & DevOps: S is for Sharing

Problemi s DNS-om u Kubernetesu. Postmortem

Datum: 28.02.2020

Autori: Amet U., Andrija S., Igor K., Aleksej P.

Status: Završeno

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

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

Osnovni uzrok: Kube-proxy nije mogao ispravno ukloniti staru stavku iz conntrack tablice, pa su se neke usluge još uvijek pokušavale spojiti na nepostojeće podove

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 niskog opterećenja unutar Kubernetes klastera, CoreDNS-autoscaler smanjio je broj podova u deploymentu s tri na dva

Rešenje: Novi deployment aplikacije pokrenuo je stvaranje novih nodova, CoreDNS-autoscaler je dodao više podova za usluživanje klastera, što je izazvalo ponovno zapisivanje conntrack tablice

Otkrivanje: Prometheus monitoring je otkrio veliki broj 5xx grešaka za usluge A, B i C i pokrenuo poziv on-call inženjerima

5xx greške u Kibani

Radnje

Akcija
Tip
Odgovorna osoba
Zadatak

Isključiti autoskaliranje za CoreDNS
spriječiti
Amet U.
DEVOPS-695

Postaviti keširajući DNS poslužitelj
smanjiti
Max V.
DEVOPS-665

Konfigurirati monitoring conntracka
spriječiti
Amet U.
DEVOPS-674

Izvučene lekcije

Što je bilo dobro:

Monitoring je radio besprijekorno. Reakcija je bila brza i organizirana
Nismo naišli na nikakve limite na nodovima

Što nije bilo u redu:

Još uvijek nepoznati pravi uzrok, izgleda kao specifična greška u conntracku
Sve radnje ispravljaju samo posljedice, ne uzrok (grešku)
Znali smo da bi prije ili kasnije mogli imati problema s DNS-om, ali nismo prioritizirali zadatke

Gdje nam je išlo dobro:

Novi deployment je aktivirao CoreDNS-autoscaler, koji je ponovno zapisao conntrack tablicu
Ova greška je zahvatila samo dio usluga

Kronologija (EET)

Vrijeme
Akcija

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

22:18
On-call inženjeri su počeli primati pozive iz sustava za monitoring

22:21
On-call inženjeri su počeli utvrđivati uzrok grešaka

22:39
On-call inženjeri su počeli vraćati jednu od posljednjih usluga na prethodnu verziju

22:40
5xx greške su prestale pojavljivati, situacija se stabilizirala

Vrijeme do otkrivanja: 4 min
Vrijeme do poduzimanja radnji: 21 min
Vrijeme do ispravka: 1 min

Dodatne informacije

CoreDNS logovi:

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' Scalirano je dolje replikati coredns-6cbb6646c9 na 2

Linkovi na Kibanu (izrezano), Grafanu (izrezano)
Gdje Linux conntrack više nije vaš prijatelj
Kube-proxy suptilnosti: Debugiranje povremenih resetiranja veze
Racy conntrack i vremenske oznake DNS pretrage

Kako bi minimizirao korištenje procesora, Linux kernel koristi nešto poput conntracka. Ukratko, to je alat koji sadrži popis NAT zapisa koji se čuvaju u posebnoj tablici. Kada sljedeći paket dođe iz istog poda na isti pod kao ranije, krajnja IP adresa se neće ponovno izračunavati, već će se uzeti iz conntrack tablice.

Kako funkcionira conntrack

Zaključci

Ovo je bio primjer jednog od naših postmortema s nekim korisnim linkovima. Konkretno, u ovom članku dijelimo informacije koje bi mogle biti korisne drugim tvrtkama. Zato se ne bojimo griješiti i zato smo jedan od naših postmortema učinili javnim. Evo još nekoliko zanimljivih javnih postmortema: