Problemet me DNS në Kubernetes. Postmortem publik

Shënim: përkthimi: ky është përkthimi 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ë ndërprerje të pjesshme të disa shërbimeve në prodhim.

Ky artikull mund të jetë i dobishëm për ata që dëshirojnë të dinë pak më shumë rreth postmortemëve ose për të parandaluar disa probleme potenciale me DNS në të ardhmen.

Kjo nuk është DNS
Nuk mund të jetë që kjo është DNS
Kjo ishte DNS

Pak rreth postmortemëve dhe proceseve në Preply

Në postmortem përshkruhet një dështim në funksionim ose ndonjë ngjarje në prodhim. Postmortemi përfshin një kronologji ngjarjesh, përshkrimin e ndikimit te përdoruesi, shkakun kryesor, veprimet dhe mësimet e nxjerra.

Kërkimi SRE

Në mbledhjet tona javore me pizzë, rreth ekipit teknik, ndajmë informacion të ndryshëm. Një nga pjesët më të rëndësishme të këtyre mbledhjeve janë postmortemët, të cilat shpesh shoqërohen me prezantime me slaide dhe një analizë më të thellë të incidentit që ka ndodhur. Pavarësisht se nuk 'duam' pas përfundimit të postmortemëve, përpiqemi të zhvillojmë kulturën e 'pa akuza' (kultura pa akuza). Ne besojmë se shkruajtja dhe paraqitja e postmortemëve mund të na ndihmojë (dhe jo vetëm) për të parandaluar incidente të ngjashme në të ardhmen, për këtë arsye ne ndajmë ato.

Personat e përfshirë në incident duhet të ndihen se mund të flasin në detaje rreth tij pa pasur frikë nga ndëshkimi ose hakmarrja. Asnjë përbuzje! Shkruajtja e postmortemëve nuk është një ndëshkim, por një mundësi për të mësuar për të gjithë kompaninë.

Mbani CALMS & DevOps: S është për NdSharing

Probleme me DNS në Kubernetes. Postmortem

Data: 28.02.2020

Autorët: Amet U., Andrey S., Igor K., Alexey P.

Statusi: Përfunduar

Përmbledhje: Disponueshmëri e pjesshme e DNS (26 min) për disa shërbime në klasterin Kubernetes

Ndikimi: 15000 ngjarje janë humbur për shërbimet A, B dhe C

Shkaku kryesor: Kube-proxy nuk mundi të fshijë korrektësisht regjistrimin e vjetër nga tabela conntrack, prandaj disa shërbime vazhduan të përpiqen të lidhen me pod të paekzistueshëm.

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 hyrjeve conntrack për UDP peer {100.64.0.10, 100.110.33.231}, gabim: komanda conntrack ktheu: ...

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

Zgjidhja: Një tjetër deploy i aplikacionit shkaktoi krijimin e nyjave të reja, CoreDNS-autoscaler shtoi më shumë pods për të shërbyer klasterin, çka shkaktoi rinovimin e tabelës conntrack

Zbulimi: Monitorimi Prometheus zbuloi një numër të madh gabimesh 5xx për shërbimet A, B dhe C dhe iniciatoi një telefonatë për inxhinierët e kujdesit

Gabimet 5xx në Kibana

Veprimet

Veprim
Lloji
Përgjegjës
Detyra

Çaktivizo autoscaler për CoreDNS
parandalimi
Amet U.
DEVOPS-695

Vendos një server DNS që ruan cache
reduktim
Max V.
DEVOPS-665

Konfiguro monitorimin e conntrack
parandalimi
Amet U.
DEVOPS-674

Mësimet e nxjerra

Çfarë shkoi mirë:

• Monitorimi funksionoi në mënyrë të qartë. Reagimi ishte i shpejtë dhe i organizuar
• Nuk u përballëm me limite në nyja

Çfarë nuk shkoi mirë:

• Akoma nuk dihet shkaku real, duket si një bug specifik në conntrack
• Të gjitha veprimet e korrigjojnë vetëm pasojat, jo shkakun (bugun)
• E dinim se disa herë do të kishim probleme me DNS, por nuk prioritizuam detyrat

Ku kemi pasur fat:

• Një tjetër deploy aktivizoi CoreDNS-autoscaler, i cili rinovoi tabelën conntrack
• Ky bug preku vetëm një pjesë të shërbimeve

Kronologjia (EET)

Koha
Veprim

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

22:18
Inxhinierët e kujdesit filluan të merrnin telefonata nga sistemi i monitorimit

22:21
Inxhinierët e kujdesit filluan të hetojnë shkakun e gabimeve

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

22:40
Gabimet 5xx pushtuan të ndalnin shfaqjen, situata u stabilizua

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

Informacione shtesë

• Log-et 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

• Lidhjet për Kibana (e prerë), Grafana (e prerë)
• Ku Linux conntrack nuk është më shoku juaj
• Hollësitë e kube-proxy: Debugging një rivendosje ndërlidhjeje intermittente
• Conntrack i trazuar dhe kohët e krijimit të DNS

Për të minimizuar përdorimin e procesorit, bërthama Linux përdor një gjë të tillë si conntrack. Në përmbledhje, kjo është një utilitare që mban një listë të regjistrimeve NAT, të cilat ruhen në një tabelë të veçantë. Kur mbërrin paketi tjetër nga i njëjti pod në të njëjtin pod si më parë, adresa IP përfundimtare nuk do të llogaritet sërish, por do të merret nga tabela conntrack.

Si e drejton conntrack

Përfundime

Ky ishte një shembull i një nga postmortemët tanë me disa lidhje të dobishme. Konkretisht në këtë artikull ne ndajmë informacion që mund të jetë i dobishëm për kompani të tjera. Kjo është arsyeja pse nuk kemi frikë të bëjmë gabime dhe kjo është arsyeja pse ne e kemi bërë një nga postmortemët tanë publik. Ja disa postmortemë interesante publike:

• GitLab: Postmortem i ndërprerjes së databazës më 31 Janar
• Dropbox: Postmortem i ndërprerjes
• Spotify: Marredhënia Dashuri/Udhëheqëse e Spotify me DNS
• Shumë të tjerë nga këtë gist dhe repositorin Historitë e Dështimit të Kubernetes
• Gjithashtu është postmortem publik me SRE Book

Burimi: habr.com