Problemoj kun DNS en Kubernetes. Publika postmortem

Notu. traduko: Ĉi tio estas traduko de publika postmorto el la inĝenieristika blogo de la firmao Prefere. Ĝi priskribas problemon kun conntrack en Kubernetes-areto, kiu kaŭzis partan malfunkcion de iuj produktadservoj.

Ĉi tiu artikolo povas esti utila por tiuj, kiuj volas lerni iom pli pri postmortems aŭ malhelpi iujn eblajn DNS-problemojn en la estonteco.

Ĉi tio ne estas DNS
Ĝi ne povas esti DNS
Ĝi estis DNS

Iom pri postmortems kaj procezoj en Preply

Postmorto priskribas misfunkcion aŭ iun eventon en produktado. La postmorto inkluzivas templinion de eventoj, uzanta efiko, radika kaŭzo, agoj faritaj kaj lernitaj lecionoj.

Serĉante SRE

Ĉe semajnaj renkontiĝoj kun pico, inter la teknika teamo, ni dividas diversajn informojn. Unu el la plej gravaj partoj de tiaj renkontiĝoj estas postmortemuloj, kiuj plej ofte estas akompanataj de prezento kun lumbildoj kaj pli profunda analizo de la okazaĵo. Kvankam ni ne aplaŭdas post mortigo, ni provas evoluigi kulturon de "senkulpigo" (senriproĉa kulturo). Ni kredas ke skribi kaj prezenti postmortems povas helpi nin (kaj aliajn) malhelpi similajn okazaĵojn en la estonteco, tial ni dividas ilin.

Individuoj implikitaj en okazaĵo devus senti, ke ili povas paroli detale sen timo de puno aŭ venĝo. Neniu kulpo! Skribi postmortan ne estas puno, sed lernebleco por la tuta kompanio.

Konservu trankvilon kaj DevOps: S estas por Kundivido

Problemoj kun DNS en Kubernetes. Postmortem

Dato: 28.02.2020

Aŭtoroj: Amet U., Andrey S., Igor K., Alexey P.

Statuso: Finita

Nelonge: Parta DNS-malhavebleco (26 min) por iuj servoj en la Kubernetes-areto

Efiko: 15000 okazaĵoj perditaj por servoj A, B kaj C

Radika kaŭzo: Kube-proxy ne povis ĝuste forigi malnovan eniron de la kontraka tabelo, do iuj servoj ankoraŭ provis konektiĝi al neekzistantaj podoj.

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: ...

ellasilo: Pro la malalta ŝarĝo ene de la Kubernetes-areto, CoreDNS-autoscaler reduktis la nombron da balgoj en la deplojo de tri al du.

solvo: La sekva deplojo de la aplikaĵo iniciatis la kreadon de novaj nodoj, CoreDNS-autoscaler aldonis pli da podoj por servi la areton, kio provokis reverkon de la conntrack-tabelo.

Detekto: Prometheus-monitorado detektis grandan nombron da 5xx-eraroj por servoj A, B kaj C kaj iniciatis vokon al la deĵorantaj inĝenieroj.

5xx eraroj en Kibana

Agoj

efiko
Tajpu
Respondeca
Objektivo

Malŝaltu aŭtomatan skalilon por CoreDNS
malhelpis
Amet U.
DEVOPS-695

Agordu kaŝan DNS-servilon
malpliigi
Max V.
DEVOPS-665

Agordu kontran monitoradon
malhelpis
Amet U.
DEVOPS-674

Lecionoj lernitaj

Kio bone iris:

• La monitorado funkciis bone. La respondo estis rapida kaj organizita
• Ni ne trafis neniujn limojn sur la nodoj

Kio estis malĝusta:

• Ankoraŭ nekonata vera radika kaŭzo, simila al specifa cimo en kontrako
• Ĉiuj agoj korektas nur la sekvojn, ne la radikan kaŭzon (cimo)
• Ni sciis, ke pli aŭ malpli frue ni eble havos problemojn kun DNS, sed ni ne prioritatis la taskojn

Kie ni bonŝancis:

• La sekva deplojo estis ekigita de CoreDNS-autoscaler, kiu anstataŭis la kontraŭtraktabelon.
• Ĉi tiu cimo influis nur kelkajn servojn

Templinio (EET)

Время
efiko

22:13
CoreDNS-autoscaler reduktis la nombron da balgoj de tri al du

22:18
Inĝenieroj deĵorantaj komencis ricevi vokojn de la monitora sistemo

22:21
La deĵorantaj inĝenieroj komencis ekscii la kaŭzon de la eraroj.

22:39
Deĵorantaj inĝenieroj komencis refari unu el la plej novaj servoj al la antaŭa versio

22:40
5xx-eraroj ĉesis aperi, la situacio stabiliĝis

• Tempo por detekto: 4 minutoj
• Tempo antaŭ ago: 21 minutoj
• Tempo por ripari: 1 minutoj

aldona informo

• Protokoloj de 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

• Ligiloj al Kibana (tranĉo), Grafana (tranĉo)
• Kie Linukso conttrack ne plu estas via amiko
• kube-proxy Subtilaĵoj: Sencimigado de Intermita Konekto-Restarigi
• Racy conntrack kaj DNS-serĉaj temporompoj

Por minimumigi CPU-uzadon, la Linukso-kerno uzas ion nomatan conntrack. Mallonge, ĉi tio estas ilo, kiu enhavas liston de NAT-rekordoj, kiuj estas konservitaj en speciala tabelo. Kiam la sekva pakaĵeto alvenas de la sama pod al la sama pod kiel antaŭe, la fina IP-adreso ne estos rekalkulita, sed estos prenita de la kontrack-tabelo.

Kiel funkcias conttrack

Rezultoj

Ĉi tio estis ekzemplo de unu el niaj postmortemuloj kun kelkaj utilaj ligiloj. Specife en ĉi tiu artikolo, ni dividas informojn, kiuj povas esti utilaj al aliaj kompanioj. Tial ni ne timas erari kaj tial ni publikigas unu el niaj postmortemuloj. Jen kelkaj pli interesaj publikaj postmortems:

• GitLab: Postmorto de datumbazo-malfunkcio de januaro 31
• Dropbox: Malfunkcio post-mortem
• Spotify: La amo/malamo-rilato de Spotify kun DNS
• Multaj aliaj de ĉi tiu esenco kaj deponejo Kubernetes Fiaskaj Rakontoj
• Ankaŭ ekzemplo publika postmortem kun SRE Book

fonto: www.habr.com