ProHoster > Blog > Bestjoer > Problemen mei DNS yn Kubernetes. Iepenbiere postmortem
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.
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 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.
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
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
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
CoreDNS logs:
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
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.
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: