Problemos su DNS Kubernetes. Viešas pomirtinis

Pastaba vertimas: Tai viešo postmortem vertimas iš įmonės inžinerijos tinklaraščio Paruošti. Jame aprašoma „Conntrack“ problema „Kubernetes“ klasteryje, dėl kurios kai kurios gamybos paslaugos buvo iš dalies prastovos.

Šis straipsnis gali būti naudingas tiems, kurie nori sužinoti daugiau apie mirtį arba užkirsti kelią kai kurioms galimoms DNS problemoms ateityje.

Tai nėra DNS
Tai negali būti DNS
Tai buvo DNS

Šiek tiek apie postmortems ir procesus Preply

Postmortem apibūdina gedimą ar tam tikrą gamybos įvykį. Postmortem apima įvykių laiko juostą, poveikį vartotojui, pagrindinę priežastį, veiksmus, kurių buvo imtasi, ir išmoktas pamokas.

Ieškau SRE

Kassavaitiniuose susitikimuose su pica tarp techninės komandos dalijamės įvairia informacija. Viena iš svarbiausių tokių susitikimų dalių – pomirtiniai tyrimai, kuriuos dažniausiai lydi pristatymas su skaidrėmis ir nuodugnesnė įvykio analizė. Nors po mirties neplojame, stengiamės ugdyti „nekaltinimo“ kultūrą (nepriekaištinga kultūra). Tikime, kad pomirtinių įvykių rašymas ir pristatymas gali padėti mums (ir kitiems) išvengti panašių incidentų ateityje, todėl jais dalinamės.

Į incidentą patekę asmenys turėtų jausti, kad gali kalbėti išsamiai, nebijodami bausmės ar atpildo. Jokios kaltės! Postmortem rašymas nėra bausmė, o galimybė mokytis visai įmonei.

Keep CALMS & DevOps: S skirtas bendrinti

Problemos su DNS Kubernetes. Postmortem

Дата: 28.02.2020

Autoriai: Ametas U., Andrejus S., Igoris K., Aleksejus P.

Būsena: Baigta

Trumpai: Dalinis DNS nepasiekiamumas (26 min.) kai kurioms Kubernetes klasterio paslaugoms

Poveikis: 15000 XNUMX įvykių prarasta dėl paslaugų A, B ir C

Pagrindinė priežastis: Kube-proxy nepavyko teisingai pašalinti seno įrašo iš conntrack lentelės, todėl kai kurios paslaugos vis dar bandė prisijungti prie neegzistuojančių rinkinių

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

Suaktyvinimas: Dėl mažos apkrovos „Kubernetes“ klasterio viduje „CoreDNS-autoscaler“ sumažino diegimo blokų skaičių nuo trijų iki dviejų.

sprendimas: Kitas programos diegimas inicijavo naujų mazgų kūrimą, „CoreDNS-autoscaler“ pridėjo daugiau blokų, skirtų klasteriui aptarnauti, o tai išprovokavo perrašymą „Conntrack“ lentelę.

Aptikimas: „Prometheus“ stebėjimas aptiko daug 5xx klaidų A, B ir C tarnybose ir iškvietė budinčius inžinierius.

5xx klaidos Kibanoje

Veikla

poveikis
Tipas
Atsakingas
Užduotis

Išjungti „CoreDNS“ automatinį mastelį
užkirto kelią
Ametas U.
DEVOPS-695

Nustatykite talpyklos DNS serverį
mažinti
Maksas V.
DEVOPS-665

Nustatykite ryšio stebėjimą
užkirto kelią
Ametas U.
DEVOPS-674

Išmoktos pamokos

Kas sekėsi gerai:

• Stebėjimas veikė gerai. Atsakymas buvo greitas ir organizuotas
• Mes nepasiekėme jokių mazgų apribojimų

Kas buvo blogai:

• Vis dar nežinoma tikroji pagrindinė priežastis, panaši į specifinė klaida in contrack
• Visi veiksmai ištaiso tik pasekmes, o ne pagrindinę priežastį (klaidą)
• Žinojome, kad anksčiau ar vėliau gali kilti problemų su DNS, bet nesuskirstėme užduočių prioritetų

Kur mums pasisekė:

• Kitas diegimas buvo suaktyvintas CoreDNS-autoscaler, kuris perrašė conntrack lentelę
• Ši klaida paveikė tik kai kurias paslaugas

Laiko juosta (EET)

Laikas
poveikis

22:13
„CoreDNS-autoscaler“ sumažino ankščių skaičių nuo trijų iki dviejų

22:18
Budintys inžinieriai pradėjo sulaukti skambučių iš stebėjimo sistemos

22:21
Budėję inžinieriai ėmė aiškintis klaidų priežastis.

22:39
Budintys inžinieriai vieną iš naujausių paslaugų pradėjo grąžinti į ankstesnę versiją

22:40
5xx klaidos nustojo atsirasti, situacija stabilizavosi

• Laikas iki aptikimo: 4 minučių
• Laikas prieš veiksmą: 21 minučių
• Laikas taisyti: 1 minučių

Papildoma informacija

• CoreDNS žurnalai:

  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

• Nuorodos į Kibana (iškirpti), Grafana (iškirpti)
• Kur Linux conntrack nebėra jūsų draugas
• „kube-proxy“ subtilybės: pertraukiamo ryšio nustatymo iš naujo derinimas
• Racy conntrack ir DNS paieškos laikas

Kad sumažintų procesoriaus naudojimą, Linux branduolys naudoja tai, kas vadinama conntrack. Trumpai tariant, tai yra programa, kurioje yra NAT įrašų, saugomų specialioje lentelėje, sąrašas. Kai kitas paketas atkeliauja iš tos pačios grupės į tą patį, kaip ir anksčiau, galutinis IP adresas nebus perskaičiuojamas, o paimtas iš conntrack lentelės.

Kaip veikia conntrack

rezultatai

Tai buvo vieno iš mūsų pomirtinių tyrimų pavyzdys su naudingomis nuorodomis. Šiame straipsnyje mes dalinamės informacija, kuri gali būti naudinga kitoms įmonėms. Štai kodėl mes nebijome klysti ir todėl vieną iš savo pomirtinių darbų skelbiame viešai. Štai keletas įdomesnių viešų postmortemų:

• GitLab: Sausio 31 d., kai buvo nutraukta duomenų bazė
• „Dropbox“: Pomirtinis gedimas
• Spotify: „Spotify“ meilės / neapykantos santykiai su DNS
• Daugelis kitų iš ši esmė ir saugykla „Kubernetes“ nesėkmių istorijos
• Taip pat pavyzdys viešas pomirtinis su SRE knyga

Šaltinis: www.habr.com