🥇Masalah DNS di Kubernetes. Postmortem Umum

Catetan tarjamahan: Ieu mangrupikeun tarjamahan tina postmortem umum tina blog rékayasa perusahaan Nyiapkeun. Éta ngajelaskeun masalah sareng conntrack dina klaster Kubernetes, anu nyababkeun downtime parsial sababaraha jasa produksi.

Tulisan ieu tiasa mangpaat pikeun anu hoyong diajar langkung seueur ngeunaan postmortem atanapi nyegah sababaraha masalah DNS poténsial di hareup.

Ieu sanés DNS
Teu tiasa DNS
Éta DNS

Sakedik ngeunaan postmortem sareng prosés di Preply

A postmortem ngajelaskeun malfungsi atawa sababaraha kajadian dina produksi. The postmortem ngawengku hiji timeline kajadian, dampak pamaké, root sabab, lampah dicokot, sarta palajaran diajar.
Néangan SRE

Dina rapat mingguan sareng pizza, diantara tim téknis, kami bagikeun sababaraha inpormasi. Salah sahiji bagian anu paling penting dina rapat sapertos kitu nyaéta post-mortem, anu paling sering dibarengan ku presentasi kalayan slide sareng analisa anu langkung jero ngeunaan kajadian éta. Sanaos urang henteu keprok saatos post-mortem, urang nyobian ngembangkeun budaya "henteu nyalahkeun" (budaya nu teu boga salah). Kami yakin yén tulisan sareng nampilkeun postmortem tiasa ngabantosan urang (sareng anu sanés) nyegah kajadian anu sami di hareup, naha éta kami ngabagikeunana.

Jalma anu kalibet dina hiji kajadian kudu ngarasa yén maranéhna bisa nyarita sacara rinci tanpa sieun hukuman atawa retribusi. Taya nyalahkeun! Nulis postmortem sanes hukuman, tapi kasempetan diajar pikeun sakabéh pausahaan.
Tetep CALMS & DevOps: S kanggo Bagikeun

Masalah sareng DNS di Kubernetes. Postmortem

Kaping: 28.02.2020

Pangarang: Amet U., Andrey S., Igor K., Alexey P.

Status: Réngsé

sakeudeung: Kasadiaan parsial DNS (26 mnt) pikeun sababaraha layanan dina klaster Kubernetes

Pangaruh: 15000 acara leungit pikeun jasa A, B jeung C

Akar panyabab: Kube-proxy henteu tiasa leres ngahapus éntri lami tina méja conntrack, janten sababaraha jasa masih nyobian nyambung ka pods anu henteu aya.

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

pemicu: Kusabab beban low di jero klaster Kubernetes, CoreDNS-autoscaler ngirangan jumlah pod dina penyebaran tina tilu ka dua.

solusi: The deployment saterusna aplikasi ngagagas kreasi titik anyar, CoreDNS-autoscaler nambahkeun leuwih pods pikeun ngawula ka klaster, nu provoked a nulis balik tabel conntrack.

Detéksi: Pemantauan Prometheus mendakan sajumlah ageung kasalahan 5xx pikeun jasa A, B sareng C sareng ngamimitian telepon ka insinyur anu ditugaskeun.

5xx kasalahan dina Kibana

lampah

epek
ngetik
Jawab
tugas

Nonaktipkeun autoscaler pikeun CoreDNS
dicegah
Amet U.
DEVOPS-695

Nyetél server DNS cache
ngurangan
Max V.
DEVOPS-665

Nyetél monitoring conntrack
dicegah
Amet U.
DEVOPS-674

Pangajaran Diajar

Naon anu saé:

Ngawaskeun damel saé. Responna gancang sareng teratur
Kami henteu pencét wates naon waé dina titik

Naon anu salah:

Masih kanyahoan akar sabab nyata, sarupa jeung bug husus dina conntrack
Sadaya tindakan ngabenerkeun konsékuansi, sanés panyabab (bug)
Urang terang yén engké atanapi engké urang tiasa gaduh masalah sareng DNS, tapi kami henteu prioritas tugas

Dimana urang meunang untung:

Panyebaran salajengna dipicu ku CoreDNS-autoscaler, anu nimpa tabel conntrack
Kutu ieu ngan ukur mangaruhan sababaraha jasa

Garis Waktu (EET)

Waktos
epek

22:13
CoreDNS-autoscaler ngurangan jumlah pods ti tilu ka dua

22:18
Insinyur dina tugas mimiti nampa telepon ti sistem monitoring

22:21
Insinyur dina tugas mimiti manggihan anu ngabalukarkeun kasalahan.

22:39
Insinyur on tugas mimiti rolling deui salah sahiji layanan panganyarna pikeun versi saméméhna

22:40
5xx kasalahan dieureunkeun muncul, kaayaan geus stabilized

Waktos pikeun deteksi: 4 menit
Waktos sateuacan tindakan: 21 menit
Waktos pikeun ngalereskeun: 1 menit

informasi tambahan

CoreDNS log:

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

Tumbu ka Kibana (cut), Grafana (cut)
di mana Linux conntrack geus lain babaturan anjeun deui
Subtleties kube-proxy: Debugging Reset Sambungan Intermittent
Racy conntrack sareng DNS lookup timeouts

Pikeun ngaminimalkeun panggunaan CPU, kernel Linux Ieu ngagunakeun hiji hal anu disebut conntrack. Singkatna, éta mangrupikeun utilitas anu ngandung daptar entri NAT anu disimpen dina tabel khusus. Nalika pakét salajengna sumping ti pod anu sami ka pod anu sami sapertos sateuacanna, alamat IP tujuan moal diitung deui, tapi bakal dicandak tina tabel conntrack.

Kumaha conntrack jalan

hasil

Ieu conto salah sahiji postmortems kami kalawan sababaraha tumbu mangpaat. Husus dina artikel ieu, urang babagi informasi nu bisa jadi mangpaat pikeun pausahaan séjén. Éta sababna urang henteu sieun ngalakukeun kasalahan sareng éta sababna urang ngadamel salah sahiji postmortem urang umum. Ieu sababaraha postmortem umum anu langkung narik: