shënim përkthimi: Ky është një përkthim i një postmortemi publike nga blogu inxhinierik i kompanisë . Ai përshkruan një problem me lidhjen në një grupim Kubernetes, i cili çoi në ndërprerje të pjesshme të disa shërbimeve të prodhimit.
Ky artikull mund të jetë i dobishëm për ata që duan të mësojnë pak më shumë rreth postmortemave ose të parandalojnë disa probleme të mundshme DNS në të ardhmen.
Ky nuk është DNS
Nuk mund të jetë DNS
Ishte DNS
Pak rreth vdekjeve dhe proceseve në Preply
Një postmortem përshkruan një mosfunksionim ose ndonjë ngjarje në prodhim. Postmortem përfshin një afat kohor të ngjarjeve, ndikimin e përdoruesit, shkakun rrënjësor, veprimet e ndërmarra dhe mësimet e nxjerra.
Në takimet javore me pica, mes ekipit teknik, ndajmë informacione të ndryshme. Një nga pjesët më të rëndësishme të takimeve të tilla janë ato postmortem, të cilat më së shpeshti shoqërohen me një prezantim me sllajde dhe një analizë më të thellë të incidentit. Edhe pse nuk duartrokasim pas vdekjes, ne përpiqemi të zhvillojmë një kulturë të "pa fajësimit" (). Ne besojmë se shkrimi dhe prezantimi i postmortemave mund të na ndihmojë ne (dhe të tjerët) të parandalojmë incidente të ngjashme në të ardhmen, kjo është arsyeja pse ne po i ndajmë ato.
Individët e përfshirë në një incident duhet të mendojnë se mund të flasin në detaje pa frikë nga ndëshkimi ose ndëshkimi. Pa faj! Shkrimi i një postmortemi nuk është një dënim, por një mundësi mësimi për të gjithë kompaninë.
Probleme me DNS në Kubernetes. Pas vdekjes
Data: 28.02.2020
Autorët: Amet U., Andrey S., Igor K., Alexey P.
Statusi: Përfunduar
shkurtimisht: Mosdisponueshmëri e pjesshme DNS (26 min) për disa shërbime në grupin Kubernetes
Ndikimi: 15000 ngjarje të humbura për shërbimet A, B dhe C
Shkaku kryesor: Kube-proxy nuk ishte në gjendje të hiqte saktë një hyrje të vjetër nga tabela e kontrollit, kështu që disa shërbime po përpiqeshin ende të lidheshin me pods që nuk ekzistonin
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: ...Shkaktësi: Për shkak të ngarkesës së ulët brenda grupit Kubernetes, CoreDNS-autoscaler zvogëloi numrin e pods në vendosje nga tre në dy
zgjidhje: Shpërndarja e radhës e aplikacionit nisi krijimin e nyjeve të reja, CoreDNS-autoscaler shtoi më shumë pods për t'i shërbyer grupit, gjë që provokoi një rishkrim të tabelës së lidhjes
Zbulim: Monitorimi i Prometheus zbuloi një numër të madh gabimesh 5xx për shërbimet A, B dhe C dhe nisi një thirrje për inxhinierët në detyrë
5xx gabime në Kibana
Aktivitet
efekt
Lloj
I përgjegjshëm
Detyrë
Çaktivizo shkallëzuesin automatik për CoreDNS
parandalohet
Amet U.
DEVOPS-695
Vendosni një server DNS memorie të fshehtë
zvogëlohet
Maks V.
DEVOPS-665
Vendosni monitorimin e kontrollit
parandalohet
Amet U.
DEVOPS-674
Mesimet e mesuara
Çfarë shkoi mirë:
- Monitorimi funksionoi mirë. Përgjigja ishte e shpejtë dhe e organizuar
- Ne nuk kemi arritur asnjë kufi në nyjet
Çfarë nuk shkonte:
- Shkaku i vërtetë rrënjësor ende i panjohur, i ngjashëm me në kontrak
- Të gjitha veprimet korrigjojnë vetëm pasojat, jo shkakun rrënjësor (bug)
- E dinim që herët a vonë mund të kishim probleme me DNS, por nuk i kishim prioritet detyrave
Ku patëm fat:
- Vendosja e radhës u shkaktua nga CoreDNS-autoscaler, i cili mbishkroi tabelën e kontrollit
- Ky gabim preku vetëm disa shërbime
Afati kohor (EET)
Kohë
efekt
22:13
CoreDNS-autoscaler zvogëloi numrin e pods nga tre në dy
22:18
Inxhinierët në detyrë filluan të merrnin thirrje nga sistemi i monitorimit
22:21
Inxhinierët në detyrë filluan të zbulojnë shkakun e gabimeve.
22:39
Inxhinierët në detyrë filluan të kthejnë një nga shërbimet më të fundit në versionin e mëparshëm
22:40
Gabimet 5xx pushuan së shfaquri, situata është stabilizuar
- Koha për zbulim: Minuta 4
- Koha para veprimit: Minuta 21
- Koha për të rregulluar: Minuta 1
Informacion shtesë
- Regjistrat e 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 - Lidhje me Kibana (prerë), Grafana (prerë)
Për të minimizuar përdorimin e CPU-së, kerneli Linux përdor diçka të quajtur conntrack. Me pak fjalë, ky është një mjet që përmban një listë të të dhënave NAT që ruhen në një tabelë të veçantë. Kur paketa tjetër të arrijë nga i njëjti pod në të njëjtin pod si më parë, adresa IP përfundimtare nuk do të rillogaritet, por do të merret nga tabela e kontrrollit.
Si funksionon contrack
Rezultatet e
Ky ishte një shembull i një prej vdekjeve tona me disa lidhje të dobishme. Në mënyrë të veçantë në këtë artikull, ne ndajmë informacione që mund të jenë të dobishme për kompanitë e tjera. Kjo është arsyeja pse ne nuk kemi frikë të bëjmë gabime dhe kjo është arsyeja pse ne bëjmë publike një nga postmortemet tona. Këtu janë disa postmorte publike më interesante:
- GitLab:
- Dropbox:
- Spotify:
- Shumë të tjerë nga dhe depoja
- Edhe postmortem publik me Librin SRE
Burimi: www.habr.com