ProHoster > Blogs > Administrācija > Problēmas ar DNS Kubernetes. Publisks pēcnāves periods

Problēmas ar DNS Kubernetes. Publisks pēcnāves periods

PiezÄ«me tulkojums: Å is ir publiskas pēcnāves tulkojums no uzņēmuma inženierzinātņu emuāra Gatavs. Tajā ir aprakstÄ«ta problēma, kas saistÄ«ta ar conntrack Kubernetes klasterÄ«, kas izraisÄ«ja dažu ražoÅ”anas pakalpojumu daļēju dÄ«kstāvi.

Šis raksts var būt noderīgs tiem, kuri vēlas uzzināt vairāk par pēcnāves gadījumiem vai novērst dažas iespējamās DNS problēmas nākotnē.

Problēmas ar DNS Kubernetes. Publisks pēcnāves periods
Tas nav DNS
Tas nevar būt DNS
Tas bija DNS

Mazliet par pēcnāves gadījumiem un procesiem Preply

Pēcnāves gadÄ«jums apraksta darbÄ«bas traucējumu vai kādu notikumu ražoÅ”anā. Pēcnāves pārbaudē ir ietverta notikumu laika skala, lietotāju ietekme, galvenais iemesls, veiktās darbÄ«bas un gÅ«tās mācÄ«bas.

Meklēju SRE

Iknedēļas tikÅ”anās reizēs ar picu, tehniskās komandas starpā dalāmies ar dažādu informāciju. Viena no svarÄ«gākajām Ŕādu sanāksmju daļām ir pēcnāves gadÄ«jumi, ko visbiežāk pavada prezentācija ar slaidiem un padziļināta incidenta analÄ«ze. Pat ja mēs neaplaudējam pēc pēcnāves gadÄ«jumiem, mēs cenÅ”amies attÄ«stÄ«t "bez vainas" kultÅ«ru (nevainojama kultÅ«ra). Mēs uzskatām, ka pēcnāves ierakstu rakstÄ«Å”ana un prezentÄ“Å”ana var palÄ«dzēt mums (un citiem) novērst lÄ«dzÄ«gus incidentus nākotnē, tāpēc mēs tos kopÄ«gojam.

Personām, kas iesaistÄ«tas incidentā, jājÅ«t, ka viņi var runāt detalizēti, nebaidoties no soda vai atriebÄ«bas. Nav vainas! Pēcnāves ziņojuma rakstÄ«Å”ana nav sods, bet gan iespēja mācÄ«ties visam uzņēmumam.

Saglabājiet CALMS & DevOps: S ir paredzēts kopÄ«goÅ”anai

Problēmas ar DNS Kubernetes. Pēcnāves

Datums: 28.02.2020

Autori: Amets U., Andrejs S., Igors K., Aleksejs P.

Statuss: Pabeigts

ÄŖsumā: Daļēja DNS nepieejamÄ«ba (26 minÅ«tes) dažiem Kubernetes klastera pakalpojumiem

Ietekme: Pakalpojumos A, B un C zaudēti 15000 XNUMX notikumu

Galvenais cēlonis: Kube starpniekserveris nevarēja pareizi noņemt veco ierakstu no conntrack tabulas, tāpēc daži pakalpojumi joprojām mēģināja izveidot savienojumu ar neesoÅ”iem podiem

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

Aktivizētājs: Sakarā ar zemo slodzi Kubernetes klasterÄ«, CoreDNS-autoscaler samazināja podiņu skaitu izvietoÅ”anā no trim uz diviem.

Ŕķīdums: Lietojumprogrammas nākamā izvietoŔana uzsāka jaunu mezglu izveidi, CoreDNS-autoscaler pievienoja vairāk podi, lai apkalpotu klasteru, kas izraisīja conntrack tabulas pārrakstīŔanu.

AtklāŔana: Prometheus monitorings atklāja lielu skaitu 5xx kļūdu pakalpojumiem A, B un C un sāka zvanu dežurējoÅ”ajiem inženieriem

Problēmas ar DNS Kubernetes. Publisks pēcnāves periods
5xx kļūdas Kibanā

Aktivitāte

efekts
RўReRї
Atbildīgs
Uzdevums

Atspējot automātisko mērogoÅ”anu CoreDNS
novērsta
Amets U.
DEVOPS-695

Iestatiet keÅ”atmiņas DNS serveri
samazināt
Makss V.
DEVOPS-665

Iestatiet kontrakciju uzraudzību
novērsta
Amets U.
DEVOPS-674

Gūtās mācības

Kas gāja labi:

  • UzraudzÄ«ba darbojās labi. Atbilde bija ātra un organizēta
  • Mēs nesasniedzām nekādus mezglu ierobežojumus

Kas bija nepareizi:

  • Joprojām nezināms Ä«stais cēlonis, lÄ«dzÄ«gs specifiska kļūda in kontraktā
  • Visas darbÄ«bas novērÅ” tikai sekas, nevis galveno cēloni (kļūdu)
  • Mēs zinājām, ka agrāk vai vēlāk mums varētu rasties problēmas ar DNS, taču mēs nenoteicām uzdevumu prioritātes

Kur mums paveicās:

  • Nākamo izvietoÅ”anu aktivizēja CoreDNS-autoscaler, kas pārrakstÄ«ja conntrack tabulu
  • Å Ä« kļūda skāra tikai dažus pakalpojumus

Laika skala (EET)

Laiks
efekts

22:13
CoreDNS-autoscaler samazināja podiņu skaitu no trim līdz diviem

22:18
DežurējoÅ”ie inženieri sāka saņemt zvanus no uzraudzÄ«bas sistēmas

22:21
DežurējoÅ”ie inženieri sāka noskaidrot kļūdu cēloni.

22:39
DežurējoÅ”ie inženieri sāka vienu no jaunākajiem pakalpojumiem atjaunot uz iepriekŔējo versiju

22:40
5xx kļūdas pārstāja parādīties, situācija ir stabilizējusies

  • Laiks noteikÅ”anai: 4 minÅ«tes
  • Laiks pirms darbÄ«bas: 21 minÅ«tes
  • Laiks labot: 1 minÅ«tes

papildu informācija

Lai samazinātu CPU izmantoÅ”anu, Linux kodols izmanto kaut ko, ko sauc par conntrack. ÄŖsāk sakot, Ŕī ir utilÄ«ta, kas satur NAT ierakstu sarakstu, kas tiek glabāti Ä«paŔā tabulā. Kad nākamā pakete pienāk no tā paÅ”a pod uz to paÅ”u pod kā iepriekÅ”, galÄ«gā IP adrese netiks pārrēķināta, bet tiks ņemta no conntrack tabulas.
Problēmas ar DNS Kubernetes. Publisks pēcnāves periods
Kā darbojas conntrack

Rezultāti

Å is bija piemērs vienai no mÅ«su pēcnāves gadÄ«jumiem ar dažām noderÄ«gām saitēm. Konkrēti Å”ajā rakstā mēs dalāmies ar informāciju, kas var bÅ«t noderÄ«ga citiem uzņēmumiem. Tāpēc mēs nebaidāmies kļūdÄ«ties un tāpēc vienu no mÅ«su pēcnāves izmeklējumiem publiskojam. Å eit ir vēl daži interesanti publiskie pēcnāves gadÄ«jumi:

Avots: www.habr.com

Pievieno komentāru