Problemen mei DNS yn Kubernetes. Iepenbiere postmortem

Noat oersetting: Dit is in oersetting fan in iepenbiere postmortem fan it engineeringblog fan it bedriuw preply. It beskriuwt in probleem mei conntrack yn in Kubernetes-kluster, wat late ta in part downtime fan guon produksje tsjinsten.

Dit artikel kin nuttich wêze foar dyjingen dy't in bytsje mear wolle leare oer postmortems of wat potinsjele DNS-problemen yn 'e takomst foarkomme.

Problemen mei DNS yn Kubernetes. Iepenbiere postmortem
Dit is gjin DNS
It kin gjin DNS wêze
It wie DNS

In bytsje oer postmortems en prosessen yn Preply

In postmortem beskriuwt in steuring of wat barren yn produksje. De postmortem omfettet in tiidline fan eveneminten, brûkersynfloed, root-oarsaak, nommen aksjes en learde lessen.

Op syk nei SRE

Op wyklikse gearkomsten mei pizza, ûnder it technyske team, diele wy ferskate ynformaasje. Ien fan 'e wichtichste ûnderdielen fan sokke gearkomsten is post-mortems, dy't meastentiids begelaat wurde troch in presintaasje mei dia's en in mear yngeande analyze fan it foarfal. Ek al klappe wy nei post-mortems net, wy besykje in kultuer te ûntwikkeljen fan "gjin skuld" (ûnskuldich kultuer). Wy leauwe dat it skriuwen en presintearjen fan postmortems ús (en oaren) kin helpe om ferlykbere ynsidinten yn 'e takomst te foarkommen, dat is wêrom wy se diele.

Persoanen belutsen by in ynsidint moatte fiele dat se yn detail kinne prate sûnder eangst foar straf of ferjilding. Gjin skuld! It skriuwen fan in postmortem is gjin straf, mar in learmooglikheid foar it hiele bedriuw.

Keep CALMS & DevOps: S is foar dielen

Problemen mei DNS yn Kubernetes. Postmortem

Datum: 28.02.2020

De auteurs: Amet U., Andrey S., Igor K., Alexey P.

Status: Finished

Koarte: Diellike DNS-ûnbeskikberens (26 min) foar guon tsjinsten yn it Kubernetes-kluster

Ynfloed: 15000 eveneminten ferlern foar tsjinsten A, B en C

Root oarsaak: Kube-proxy koe in âlde yngong net korrekt fuortsmite fan 'e conntrack-tabel, sadat guon tsjinsten noch besochten te ferbinen mei net-besteande pods

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

Trekker: Troch de lege lading yn it Kubernetes-kluster fermindere CoreDNS-autoscaler it oantal pods yn 'e ynset fan trije nei twa

oplossing: De folgjende ynset fan 'e applikaasje begon de skepping fan nije knooppunten, CoreDNS-autoscaler tafoege mear pods om it kluster te tsjinjen, wat in herskriuwen fan' e conntrack-tabel útlokte

Deteksje: Prometheus-monitoring ûntduts in grut oantal 5xx-flaters foar tsjinsten A, B en C en inisjearre in oprop oan de yngenieurs fan tsjinst

Problemen mei DNS yn Kubernetes. Iepenbiere postmortem
5xx flaters yn Kibana

Aksjes

effekt
Typ
Ferantwurdlik
Objective

Utskeakelje autoscaler foar CoreDNS
foarkommen
Amet U.
DEVOPS-695

Stel in caching DNS-tsjinner yn
ferminderje
Max V.
DEVOPS-665

Konfigurearje ferbiningsmonitoring
foarkommen
Amet U.
DEVOPS-674

Lessen leard

Wat gie goed:

  • De tafersjoch wurke goed. De reaksje wie rap en organisearre
  • Wy troffen gjin grinzen op 'e knopen

Wat wie der mis:

  • Noch ûnbekende echte root oarsaak, fergelykber mei spesifike bug yn ferbining
  • Alle aksjes korrigearje allinich de gefolgen, net de root oarsaak (bug)
  • Wy wisten dat wy ier of letter problemen hawwe mei DNS, mar wy hawwe de taken net prioritearre

Wêr't wy gelok hawwe:

  • De folgjende ynset waard aktivearre troch CoreDNS-autoscaler, dy't de conntrack-tabel oerskriuwt
  • Dizze brek hat allinnich ynfloed op guon tsjinsten

Timeline (EET)

Время
effekt

22:13
CoreDNS-autoscaler fermindere it oantal pods fan trije nei twa

22:18
Yngenieurs op plicht begon te ûntfangen oproppen fan it tafersjochsysteem

22:21
De yngenieurs yn tsjinst begûnen út te sykjen nei de oarsaak fan de flaters.

22:39
Yngenieurs op plicht begon ien fan 'e lêste tsjinsten werom te rôljen nei de foarige ferzje

22:40
5xx flaters stoppe mei ferskinen, de situaasje is stabilisearre

  • Tiid foar deteksje: 4 min
  • Tiid foar aksje: 21 min
  • Tiid om te reparearjen: 1 min

oanfoljende ynformaasje

Om CPU-gebrûk te minimalisearjen, brûkt de Linux-kernel wat conntrack neamd wurdt. Koartsein, dit is in hulpprogramma dat in list befettet mei NAT-records dy't wurde opslein yn in spesjale tabel. As it folgjende pakket komt fan deselde pod nei deselde pod as earder, sil it definitive IP-adres net opnij berekkene wurde, mar sil wurde nommen út 'e conntrack-tabel.
Problemen mei DNS yn Kubernetes. Iepenbiere postmortem
Hoe conntrack wurket

Resultaten

Dit wie in foarbyld fan ien fan ús postmortems mei wat nuttige keppelings. Spesifyk yn dit artikel diele wy ynformaasje dy't nuttich kin wêze foar oare bedriuwen. Dêrom binne wy ​​net bang om flaters te meitsjen en dêrom meitsje wy ien fan ús postmortems iepenbier. Hjir binne wat mear nijsgjirrige iepenbiere postmortems:

Boarne: www.habr.com

Add a comment