Opomba prevod: To je prevod javne obdukcije iz inženirskega bloga podjetja . Opisuje težavo s conntrackom v gruči Kubernetes, ki je povzročila delne izpade nekaterih proizvodnih storitev.
Ta članek je lahko koristen za tiste, ki želijo izvedeti nekaj več o posmrtnih ostankih ali preprečiti morebitne težave z DNS v prihodnosti.
To ni DNS
Ne more biti DNS
Bil je DNS
Nekaj o obdukciji in postopkih v Preply
Obdukcija opisuje okvaro ali nek dogodek v proizvodnji. Obdukcija vključuje časovnico dogodkov, vpliv na uporabnika, osnovni vzrok, izvedene ukrepe in pridobljene izkušnje.
Na tedenskih srečanjih s pico, med tehnično ekipo, delimo različne informacije. Eden najpomembnejših delov tovrstnih srečanj so obdukcije, ki jih največkrat spremlja predstavitev z diapozitivi in poglobljena analiza dogodka. Čeprav po obdukciji ne ploskamo, poskušamo razviti kulturo "brez obtoževanja" (). Verjamemo, da lahko pisanje in predstavitev posmrtnih ostankov nam (in drugim) pomaga preprečiti podobne incidente v prihodnosti, zato jih delimo.
Posamezniki, vpleteni v incident, bi morali čutiti, da lahko podrobno spregovorijo brez strahu pred kaznijo ali maščevanjem. Brez zamere! Pisanje obdukcije ni kazen, ampak priložnost za učenje za celotno podjetje.
Težave z DNS v Kubernetesu. Posmrtno
Datum: 28.02.2020
Avtorji: Amet U., Andrej S., Igor K., Aleksej P.
Stanje: Dokončano
Na kratko: Delna nedosegljivost DNS (26 min) za nekatere storitve v gruči Kubernetes
Vpliv: 15000 izgubljenih dogodkov za storitve A, B in C
Glavni vzrok: Kube-proxy ni mogel pravilno odstraniti starega vnosa iz tabele conntrack, zato so se nekatere storitve še vedno poskušale povezati z neobstoječimi sklopi
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: ...Sprožilec: Zaradi majhne obremenitve znotraj gruče Kubernetes je CoreDNS-autoscaler zmanjšal število podov v razmestitvi s treh na dva
raztopina: Naslednja uvedba aplikacije je sprožila ustvarjanje novih vozlišč, CoreDNS-autoscaler je dodal več podov, ki so služili gruči, kar je povzročilo prepis tabele conntrack
Zaznavanje: Prometheus monitoring je zaznal veliko število napak 5xx za storitve A, B in C in sprožil klic dežurnim inženirjem
5xx napak v Kibani
Dejavnost
učinek
Tip
Odgovorni
Naloga
Onemogoči samodejno skaliranje za CoreDNS
preprečili
Amet U.
DEVOPS-695
Nastavite strežnik DNS za predpomnjenje
zmanjšanje
Max V.
DEVOPS-665
Nastavite nadzor conntrack
preprečili
Amet U.
DEVOPS-674
Naučena lekcija
Kaj je šlo dobro:
- Spremljanje je dobro delovalo. Odziv je bil hiter in organiziran
- Na vozliščih nismo dosegli nobenih omejitev
Kaj je bilo narobe:
- Še neznan pravi vzrok, podoben v conntrack
- Vsa dejanja popravijo le posledice, ne temeljnega vzroka (napaka)
- Vedeli smo, da bomo prej ali slej lahko imeli težave z DNS, vendar nalog nismo prioritetizirali
Kje smo imeli srečo:
- Naslednjo uvedbo je sprožil CoreDNS-autoscaler, ki je prepisal tabelo conntrack
- Ta napaka je vplivala samo na nekatere storitve
Časovnica (EET)
Čas
učinek
22:13
CoreDNS-autoscaler je zmanjšal število podov s treh na dva
22:18
Dežurni inženirji so začeli prejemati klice iz nadzornega sistema
22:21
Dežurni inženirji so začeli ugotavljati vzrok napak.
22:39
Dežurni inženirji so začeli vračati eno najnovejših storitev na prejšnjo različico
22:40
Napake 5xx so se prenehale pojavljati, stanje se je stabiliziralo
- Čas do zaznave: 4 minut
- Čas pred akcijo: 21 minut
- Čas za popravek: 1 minut
dodatne informacije
- Dnevniki 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 - Povezave do Kibana (cut), Grafana (cut)
Da bi zmanjšali porabo procesorja, jedro Linuxa uporablja nekaj, kar se imenuje conntrack. Skratka, to je pripomoček, ki vsebuje seznam zapisov NAT, ki so shranjeni v posebni tabeli. Ko naslednji paket prispe iz iste skupine v isto enoto kot prej, končni naslov IP ne bo ponovno izračunan, ampak bo vzet iz tabele conntrack.
Kako deluje conntrack
Rezultati
To je bil primer enega od naših posmrtnih ostankov z nekaj uporabnimi povezavami. Natančneje v tem članku delimo informacije, ki so lahko koristne za druga podjetja. Zato se ne bojimo delati napak in zato javno objavimo enega od naših posmrtnih ostankov. Tu je še nekaj zanimivih javnih posmrtnih ostankov:
- GitLab:
- Dropbox:
- Spotify:
- Mnogi drugi iz in repozitorij
- Tudi javna obdukcija s knjigo SRE
Vir: www.habr.com