Problemet me DNS në Kubernetes. Postmortem publik

Shënim: kjo është një përkthim i një postmortemi publik nga blogu inxhinierik i kompanisë Preply. Në të përshkruhet problemi me conntrack në klasterin Kubernetes, i cili çoi në një bllokim të pjesshëm të disa shërbimeve të prodhimit.

Ky artikull mund të jetë i dobishëm për ata që dëshirojnë të dinë pak më shumë rreth postmortemeve ose të parandalojnë disa probleme të mundshme me DNS në të ardhmen.

Nuk është DNS
Nuk mund të jetë që është DNS
Ishte DNS

Pak fjalë për postmortemet dhe proceset në Preply

Në postmortem përshkruhet një dështim në funksionim ose ndonjë ngjarje në prodhim. Postmortemi përfshin një kronologji të ngjarjeve, përshkrimin e ndikimit mbi përdoruesin, shkakun e parë, veprimet dhe mësimet e nxjerra.

Seeking SRE

Në mbledhjet javore me pizzë, në mesin e ekipit teknik, ne ndajmë informacion të ndryshëm. Një nga pjesët më të rëndësishme të këtyre mbledhjeve janë postmortemet, të cilat shpesh shoqërohen me prezantime dhe një analizë më të thellë të incidentit të ndodhur. Edhe pse ne nuk 'duartrokasim' pas postmortemeve, ne përpiqemi të zhvillojmë një kulturë 'pa fajësim' (blameless culture). Besojmë se shkruarja dhe paraqitja e postmortemeve mund të na ndihmojnë (dhe jo vetëm ne) në parandalimin e incidenteve të ngjashme në të ardhmen, prandaj ne i ndajmë ato.

Personat e involvuar në incident duhet të ndihen se mund të flasin hollësisht për të, pa frikë nga dënimi ose hakmarrja. Asnjë faji! Shkruarja e postmortemit nuk është një dënim, por një mundësi për të mësuar për të gjithë kompaninë.

Keep CALMS & DevOps: S is for Sharing

Problemet me DNS në Kubernetes. Postmortem

Data: 28.02.2020

Shkruar nga: Amet U., Andrey S., Igor K., Alexey P.

Statusi: E përfunduar

Shkurtimisht: Disponueshmëria e pjesshme e DNS (26 minuta) për disa shërbime në klasterin Kubernetes

Ndikimi: 15000 ngjarje të humbura për shërbimet A, B dhe C

Shkaku i parë: Kube-proxy nuk arriti të fshijë siç duhet regjistrimin e vjetër nga tabela conntrack, prandaj disa shërbime vazhduan të përpiqen të lidheshin me podet që nuk ekzistonin

E0228 20:13:53.795782       1 proxier.go:610] Dështoi të fshijë kube-system/kube-dns:dns endpoint connections, gabim: gabim në fshirjen e regjistrimeve conntrack për UDP peer {100.64.0.10, 100.110.33.231}, gabim: komanda conntrack ktheu: ...

Gara: Për shkak të ngarkesës së ulët brenda klasterit Kubernetes, CoreDNS-autoscaler reduktoi numrin e podëve në deployment nga tre në dy

Zgjidhja: Një tjetër deployment aplikacioni inicoi krijimin e nodeve të reja, CoreDNS-autoscaler shtoi më shumë podë për të shërbyer klasterin, çfarë shkaktoi përshkrimin e tabelës conntrack

Zbulimi: Monitorimi Prometheus zbuloi një numër të madh të gabimeve 5xx për shërbimet A, B dhe C dhe inicioi një thirrje për inxhinierët në detyrë

Gabimet 5xx në Kibana

Veprime

Veprimi
Tipo
Përgjegjës
Detyra

Çaktivizoni autoscaler-in për CoreDNS
parandaloni.
Amet U.
DEVOPS-695

Instaloni serverin DNS memorizues
pakësimet.
Max V.
DEVOPS-665

Konfiguroni monitorimin conntrack
parandaloni.
Amet U.
DEVOPS-674

Mësimet e nxjerra

Çfarë shkoi mirë:

• Monitorimi funksionoi saktë. Reagimi ishte i shpejtë dhe i organizuar
• Nuk u përballëm me asnjë kufizim në node

Çfarë nuk shkoi siç duhet:

• Akoma një shkak i parë i panjohur, duke dukur si një bug specifik në conntrack
• Të gjitha veprimet korrigjojnë vetëm pasojat, jo shkakun e parë (bugun)
• E dinim se një ose më vonë mund të kishim probleme me DNS, por nuk e prioritizuam detyrën

Ku patëm fat:

• Një tjetër ndihmës inicoi CoreDNS-autoscaler, i cili përshkroi tabelën conntrack
• Ky bug preku vetëm një pjesë të shërbimeve

Kronologjia (EET)

Koha
Veprimi

22:13
CoreDNS-autoscaler reduktoi numrin e podëve nga tre në dy

22:18
Inxhinierët në detyrë filluan të merrnin telefonata nga sistemi i monitorimit

22:21
Inxhinierët në detyrë filluan të hetojnë shkakun e gabimeve

22:39
Inxhinierët në detyrë filluan të rikthejnë një nga shërbimet e fundit në versionin e mëparshëm

22:40
Gabimet 5xx ndaluan së shfaquri, situata u stabilizua

• Koha deri në zbulim: 4 minuta
• Koha deri në veprim: 21 minuta
• Koha deri në korrigjim: 1 minutë

Informacione shtesë

• Loget 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:""}): tipi: 'Normal' arsye: 'ScalingReplicaSet' U reduktua grupi i kopjeve coredns-6cbb6646c9 në 2

• Linket në Kibana (të prerë), Grafana (të prerë)
• Ku Linux conntrack nuk është më miku juaj
• Nënkuptimet e kube-proxy: Debugging një rivendosje të lidhjes
• Konfliktet e conntrack dhe kohëzgjatjet e kërkesave DNS

Për të minimizuar përdorimin e procesorit, bërthama Linux përdor një gjë si conntrack. Nëse e shqyrtojmë shkurt, kjo është një utilitare që përmban një listë të regjistrimeve NAT, të cilat mbahen në një tabelë të veçantë. Kur paketa e ardhshme vjen nga e njëjta pod në të njëjtin pod si më parë, adresa përfundimtare IP nuk do të llogaritet nga e para, por do të merret nga tabela conntrack.

Si funksionon conntrack

Përfundimet

Ky ishte një shembull i një prej postmortem-ëve tona me disa lidhje të dobishme. Konkretisht në këtë artikull, ne ndajmë informacion që mund të jetë i dobishëm për kompanitë e tjera. Këtu është arsyja pse ne nuk kemi frikë të bëjmë gabime dhe pse ne e bëjmë një prej postmortem-ëve tona publike. Këtu janë disa postmortem të tjera interesante publikisht:

• GitLab: Postmortem-i i ndërprerjes së databazës më 31 janar
• Dropbox: Postmortem-i i ndërprerjes
• Spotify: Marrëdhënia Love/Hate e Spotify me DNS
• Shumë të tjera nga ky gist dhe repository Historitë e Dështimeve në Kubernetes
• Po ashtu shembull postmortemi publik me SRE Book

Burimi: habr.com