DNS-probleemid Kubernetesis. Avalik post-mortem

Märkus: see on tõlge avalikust postmortemist ettevõtte inseneriblogist Preply. Selles kajastatakse probleemi conntrack'iga Kubernetes'i klastris, mis viis osalise seiskumiseni mõnedes tootmisteenustes.

See artikkel võib olla kasulik neile, kes soovivad teada saada rohkem postmortem'ite kohta või ennetada tulevikus potentsiaalseid DNS-probleeme.

DNS-probleemid Kubernetesis. Avalik post-mortem
See ei ole DNS
Ei saa olla, et see on DNS
See oli DNS

Veidi postmortem'itest ja protsessidest Preply's

Postmortemis kirjeldatakse tõrget või mõnda sündmust tootmisprotsessis. Postmortem sisaldab sündmuste kronoloogiat, kasutaja mõjutamise kirjeldust, algpõhjust, rakendatud meetmeid ja saadud õppetunde.

Otsime SRE-d

Igal nädalal toimuvatel pizzakohtumistel tehnilise meeskonnaga jagame mitmesugust teavet. Üks selliste kohtumiste olulisemaid osi on postmortem'id, mis on enamasti kaasas esitlustega ja sügavamal analüüsil toimunud juhtumist. Kuigi me ei „aplodeeri“ postmortem'ite ajal, püüame arendada „ilma süüdistusteta“ kultuuri (blame'itav kultuur). Me usume, et postmorte kirjutamine ja esitlemine võivad aidata meil (ja mitte ainult) sarnaseid intsidendid tulevikus ära hoida, just seetõttu jagame me neid.

Intsidenti osalenud isikud peaksid tundma, et nad saavad selle kohta põhjalikult rääkida, kartmata karistust või kättemaksu. Pole ühtegi hukkamõistu! Postmorte kirjutamine ei ole karistus, vaid õppimise võimalus kogu ettevõttele.

Keep CALMS & DevOps: S on jagamine

DNS-probleemid Kuberneteses. Postmorte

Kuupäev: 28.02.2020

Autorid: Amet U., Andrei S., Igor K., Aleksei P.

Olek: Lõpetatud

Lühidalt: Osaline DNS-ülesolek (26 min) mõnede teenuste jaoks Kubernetes-klusteris

Mõju: 15000 sündmust kadus teenuste A, B ja C jaoks

Põhjus: Kube-proxy ei suutnud korralikult eemaldada vana kirjet conntrack tabelist, seega mõned teenused proovisid endiselt luua ühendust mitteeksisteerivate podidega

E0228 20:13:53.795782       1 proxier.go:610] Ebaõnnestus kube-system/kube-dns:dns lõpp-punkti ühenduste kustutamine, viga: viga conntracki kirje kustutamisel UDP partnerile {100.64.0.10, 100.110.33.231}, viga: conntracki käsk tagastas: ...

Käivitaja: Kuna Kubernetes-klusteris on väike koormus, vähendas CoreDNS-autoscaler podide arvu nas kolme kahe peale.

Lahenduseks on: Rakenduse uus juurutamine käivitas uute sõlmede loomise, CoreDNS-autoscaler lisas klastriteenuse haldamiseks rohkem pod'e, mis põhjustas conntracki tabeli ülekirjutamise.

Avastatud: Prometheus jälgimine tuvastas suure hulga 5xx vigu teenustes A, B ja C ning käivitas hädaolukorra teadlikkuse.

DNS-probleemid Kubernetesis. Avalik post-mortem
5xx vead Kibanas

Toimingud

Tegevus
Tüüp
Vastutav
Ülesanne

Lülita CoreDNS-autoskaleerija välja
ennetamine.
Amet U.
DEVOPS-695

Sea sisse vahemälus hoiduv DNS-server
vähenda.
Max V.
DEVOPS-665

Seadista conntracki jälgimine
ennetamine.
Amet U.
DEVOPS-674

Tõstatatud õppetunnid

Mis läks hästi:

  • Jälgimine toimis täpselt. Reaktsioon oli kiire ja korralik.
  • Me ei jooksnud sõlmedes ühtegi limiiti kokku.

Mis polnud nii:

  • Endiselt teadmata reaalse põhjus, tundub olevat spetsiifiline bug conntrackis.
  • Kõik tegevused parandavad ainult tagajärgi, mitte päästiku (bugi).
  • Me teadsime, et varem või hiljem võivad meil DNS-iga probleemid tekkida, kuid ei prioriseerinud ülesandeid.

Kus meil vedas:

  • Uue juurutamise tõttu aktiveerus CoreDNS-autoskaleerija, mis ülekirjutas conntracki tabeli.
  • See bug puudutas ainult osa teenustest.

Ajaskaalal (EET)

Aeg
Tegevus

22:13
CoreDNS-autoskaleerija vähendas pod'ide arvu kolme pealt kaheni.

22:18
Valvakompanii insenerid hakkasid saama kõnesid jälgimissüsteemilt

22:21
Valvakompanii insenerid hakkasid uurima vigade põhjuseid

22:39
Valvakompanii insenerid hakkasid tagasi kerima ühte viimast teenust eelmine versioon

22:40
5xx vead lakkasid ilmumast, olukord stabiliseerus

  • Aeg avastamiseni: 4 min
  • Aeg tegevuste alustamiseni: 21 min
  • Aeg parandamiseni: 1 min

Lisainformatsioon

Protsessori kasutamise minimeerimiseks kasutab Linuxi tuum sellist asja nagu conntrack. Lihtsalt öeldes, see on utiliit, mis sisaldab NAT-kandeid, mis salvestatakse spetsiaalsesse tabelisse. Kui järgmine pakett tuleb samast podist ja samasse podi nagu varem, ei arvutata lõpp-IP-aadressi uuesti, vaid see võetakse conntracki tabelist.
DNS-probleemid Kubernetesis. Avalik post-mortem
Kuidas conntrack toimib

Kokkuvõte

See oli näide meie postmorteemist koos mõningate kasulike linkidega. Just selles artiklis jagame teavet, mis võib osutuda kasulikuks ka teistele ettevõtetele. Seepärast ei karda me eksida ning just sellepärast tegime ühe meie postmortemia avalikuks. Siin on veel mõned huvitavad avalikud postmortemid:

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster