Tandaan pagsasalin: Isa itong pagsasalin ng pampublikong postmortem mula sa engineering blog ng kumpanya . Inilalarawan nito ang isang problema sa conntrack sa isang Kubernetes cluster, na humantong sa bahagyang downtime ng ilang mga serbisyo sa produksyon.
Maaaring maging kapaki-pakinabang ang artikulong ito para sa mga gustong matuto nang kaunti pa tungkol sa mga postmortem o maiwasan ang ilang potensyal na problema sa DNS sa hinaharap.
Hindi ito DNS
Hindi ito maaaring DNS
Ito ay DNS
Kaunti tungkol sa mga postmortem at mga proseso sa Preply
Ang isang postmortem ay naglalarawan ng isang malfunction o ilang kaganapan sa produksyon. Ang postmortem ay may kasamang timeline ng mga kaganapan, epekto ng user, ugat na sanhi, mga aksyon na ginawa, at mga aral na natutunan.
Sa lingguhang pagpupulong kasama ang pizza, kasama ng technical team, nagbabahagi kami ng iba't ibang impormasyon. Ang isa sa pinakamahalagang bahagi ng naturang mga pagpupulong ay ang mga post-mortem, na kadalasang sinasamahan ng isang pagtatanghal na may mga slide at isang mas malalim na pagsusuri sa insidente. Kahit na hindi kami pumapalakpak pagkatapos ng post-mortem, sinisikap naming bumuo ng kulturang "walang sisihan" (). Naniniwala kami na ang pagsulat at pagpapakita ng mga postmortem ay makakatulong sa amin (at sa iba pa) na maiwasan ang mga katulad na insidente sa hinaharap, kaya naman ibinabahagi namin ang mga ito.
Ang mga indibidwal na nasasangkot sa isang insidente ay dapat makaramdam na maaari silang magsalita nang detalyado nang walang takot sa parusa o paghihiganti. Walang sisihan! Ang pagsulat ng postmortem ay hindi isang parusa, ngunit isang pagkakataon sa pag-aaral para sa buong kumpanya.
Mga problema sa DNS sa Kubernetes. Postmortem
Petsa: 28.02.2020
Mga May-akda: Amet U., Andrey S., Igor K., Alexey P.
Katayuan: Tapos na
Sa madaling sabi: Hindi available ang bahagyang DNS (26 min) para sa ilang serbisyo sa cluster ng Kubernetes
Epekto: 15000 kaganapan ang nawala para sa mga serbisyo A, B at C
ugat na sanhi: Hindi naalis nang tama ng Kube-proxy ang isang lumang entry mula sa conntrack table, kaya sinusubukan pa rin ng ilang serbisyo na kumonekta sa mga hindi umiiral na pod
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: ...Trigger: Dahil sa mababang load sa loob ng Kubernetes cluster, binawasan ng CoreDNS-autoscaler ang bilang ng mga pod sa deployment mula tatlo hanggang dalawa.
solusyon: Ang susunod na deployment ng application ay nagpasimula ng paglikha ng mga bagong node, nagdagdag ang CoreDNS-autoscaler ng higit pang mga pod upang ihatid ang cluster, na nag-udyok ng muling pagsulat ng conntrack table
Pagtuklas: Ang pagsubaybay ng Prometheus ay nakakita ng malaking bilang ng 5xx na mga error para sa mga serbisyong A, B at C at nagpasimula ng isang tawag sa mga on-duty na inhinyero
5xx error sa Kibana
Aktibidad
epekto
Uri
May pananagutan
Gawain
Huwag paganahin ang autoscaler para sa CoreDNS
pinigilan
Amet U.
DEVOPS-695
Mag-set up ng cache ng DNS server
bumaba
Max V.
DEVOPS-665
I-set up ang conntrack monitoring
pinigilan
Amet U.
DEVOPS-674
Mga aral na natutunan
Ano ang naging maayos:
- Naging maayos ang monitoring. Mabilis at organisado ang tugon
- Hindi namin naabot ang anumang mga limitasyon sa mga node
Ano ang mali:
- Hindi pa rin alam ang tunay na sanhi, katulad ng sa conntrack
- Ang lahat ng mga aksyon ay itinatama lamang ang mga kahihinatnan, hindi ang ugat na sanhi (bug)
- Alam namin na sa kalaunan ay maaaring magkaroon kami ng mga problema sa DNS, ngunit hindi namin inuuna ang mga gawain
Kung saan tayo swerte:
- Ang susunod na deployment ay na-trigger ng CoreDNS-autoscaler, na nag-overwrote sa conntrack table
- Ilang serbisyo lang ang naapektuhan ng bug na ito
Timeline (EET)
oras
epekto
22:13
Binawasan ng CoreDNS-autoscaler ang bilang ng mga pod mula tatlo hanggang dalawa
22:18
Ang mga inhinyero na naka-duty ay nagsimulang makatanggap ng mga tawag mula sa sistema ng pagsubaybay
22:21
Ang mga inhinyero sa tungkulin ay nagsimulang malaman ang sanhi ng mga pagkakamali.
22:39
Ang mga inhinyero na naka-duty ay nagsimulang ibalik ang isa sa mga pinakabagong serbisyo sa nakaraang bersyon
22:40
Huminto sa paglitaw ang 5xx na mga error, naging matatag ang sitwasyon
- Oras para sa pagtuklas: 4 minuto
- Oras bago ang pagkilos: 21 minuto
- Oras para ayusin: 1 minuto
karagdagang impormasyon
- Mga log ng 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 - Mga link sa Kibana (cut), Grafana (cut)
Upang mabawasan ang paggamit ng CPU, ang Linux kernel ay gumagamit ng tinatawag na conntrack. Sa madaling salita, ito ay isang utility na naglalaman ng isang listahan ng mga NAT record na naka-imbak sa isang espesyal na talahanayan. Kapag ang susunod na packet ay dumating mula sa parehong pod patungo sa parehong pod tulad ng dati, ang huling IP address ay hindi muling kakalkulahin, ngunit kukunin mula sa conntrack table.
Paano gumagana ang conntrack
Mga resulta ng
Ito ay isang halimbawa ng isa sa aming mga postmortem na may ilang mga kapaki-pakinabang na link. Partikular sa artikulong ito, nagbabahagi kami ng impormasyon na maaaring maging kapaki-pakinabang sa ibang mga kumpanya. Kaya naman hindi kami natatakot na magkamali at iyon ang dahilan kung bakit isapubliko namin ang isa sa aming mga postmortem. Narito ang ilang mas kawili-wiling pampublikong postmortem:
- GitLab:
- Dropbox:
- Spotify:
- Marami pang iba mula sa at imbakan
- Rin pampublikong postmortem na may SRE Book
Pinagmulan: www.habr.com