Masalah karo DNS ing Kubernetes. Postmortem umum

Cathetan ngartekne: Iki minangka terjemahan postmortem umum saka blog teknik perusahaan Cepet. Iki nggambarake masalah karo conntrack ing kluster Kubernetes, sing nyebabake downtime sebagian saka sawetara layanan produksi.

Artikel iki bisa uga migunani kanggo wong-wong sing pengin sinau luwih akeh babagan postmortems utawa nyegah sawetara masalah DNS potensial ing mangsa ngarep.

Iki dudu DNS
Ora bisa dadi DNS
Iku DNS

A sethitik babagan postmortems lan pangolahan ing Preply

A postmortem nggambarake malfunction utawa sawetara acara ing produksi. Postmortem kalebu garis wektu acara, pengaruh pangguna, sababe, tumindak sing ditindakake, lan pelajaran sing disinaoni.

Nggoleki SRE

Ing rapat mingguan karo pizza, ing antarane tim teknis, kita nuduhake macem-macem informasi. Salah sawijining bagéan paling penting saka rapat kasebut yaiku post-mortem, sing paling kerep diiringi presentasi kanthi slide lan analisis sing luwih jero babagan kedadeyan kasebut. Sanadyan kita ora clap sawise post-mortem, kita nyoba kanggo ngembangake budaya "ora nyalahke" (budaya tanpa cacad). Kita yakin manawa nulis lan nampilake postmortem bisa mbantu kita (lan liya-liyane) nyegah kedadeyan sing padha ing mangsa ngarep, mula kita nuduhake.

Wong sing melu kedadean kudu ngrasa yen dheweke bisa ngomong kanthi rinci tanpa wedi marang paukuman utawa retribusi. Ora disalahake! Nulis postmortem dudu paukuman, nanging kesempatan sinau kanggo kabeh perusahaan.

Tansah CALMS & DevOps: S kanggo Nuduhake

Masalah karo DNS ing Kubernetes. Postmortem

Tanggal: 28.02.2020

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

Status: Rampung

Sedhela: Ora kasedhiya DNS parsial (26 menit) kanggo sawetara layanan ing kluster Kubernetes

Pengaruh: 15000 acara ilang kanggo layanan A, B lan C

Akar sabab: Kube-proxy ora bisa mbusak entri lawas kanthi bener saka tabel conntrack, mula sawetara layanan isih nyoba nyambung menyang pod sing ora ana.

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: Amarga beban sing sithik ing kluster Kubernetes, CoreDNS-autoscaler nyuda jumlah pod ing panyebaran saka telu dadi loro.

solusi: Penyebaran aplikasi sabanjure miwiti nggawe simpul anyar, CoreDNS-autoscaler nambahake polong liyane kanggo ngladeni kluster, sing nyebabake nulis ulang tabel conntrack.

Deteksi: Pemantauan Prometheus ndeteksi akeh kesalahan 5xx kanggo layanan A, B lan C lan miwiti telpon menyang insinyur sing tugas.

5xx kasalahan ing Kibana

Tindakan

efek
Gaya
Tanggung jawab
Tujuan

Pateni autoscaler kanggo CoreDNS
dicegah
Amet U.
DEVOPS-695

Nggawe server DNS cache
nyuda
Maks V.
DEVOPS-665

Nggawe conntrack monitoring
dicegah
Amet U.
DEVOPS-674

Piwulang sing Disinaoni

Apa sing apik:

• Pemantauan kerjane apik. Respon cepet lan diatur
• Kita ora kenek watesan ing kelenjar

Apa salah:

• Isih dingerteni sabab nyata, padha karo bug tartamtu ing conntrack
• Kabeh tumindak mbenerake mung akibat, dudu sabab (bug)
• Kita ngerti yen cepet utawa mengko kita bakal duwe masalah karo DNS, nanging kita ora prioritas tugas

Ing ngendi kita entuk begja:

• Penyebaran sabanjure dipicu dening CoreDNS-autoscaler, sing nimpa tabel conntrack
• Bug iki mung kena pengaruh sawetara layanan

Garis wektu (EET)

Время
efek

22:13
CoreDNS-autoscaler suda jumlah pods saka telu dadi loro

22:18
Engineers ing tugas wiwit nampa telpon saka sistem ngawasi

22:21
Insinyur sing tugas wiwit nemokake sababe kesalahan kasebut.

22:39
Insinyur sing tugas wiwit nggulung maneh salah sawijining layanan paling anyar menyang versi sadurunge

22:40
5xx kasalahan mandheg katon, kahanan wis stabil

• Wektu kanggo deteksi: 4 menit
• Wektu sadurunge tumindak: 21 menit
• Wektu kanggo ndandani: 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

• Link menyang Kibana (cut), Grafana (cut)
• Ing ngendi Linux conntrack ora dadi kanca sampeyan
• Subtleties kube-proxy: Debugging Reset Sambungan Intermiten
• Racy conntrack lan DNS lookup wektu entek

Kanggo nyilikake panggunaan CPU, kernel Linux nggunakake sing diarani conntrack. Ing cendhak, iki minangka sarana sing ngemot dhaptar cathetan NAT sing disimpen ing tabel khusus. Nalika paket sabanjure teka saka polong sing padha menyang polong sing padha kaya sadurunge, alamat IP pungkasan ora bakal diitung maneh, nanging bakal dijupuk saka meja conntrack.

Cara kerjane conntrack

Hasil

Iki minangka conto salah sawijining postmortems kanthi sawetara tautan sing migunani. Khusus ing artikel iki, kita nuduhake informasi sing bisa migunani kanggo perusahaan liyane. Pramila kita ora wedi nggawe kesalahan lan mula kita nggawe salah sawijining postmortem umum. Ing ngisor iki sawetara postmortem umum sing luwih menarik:

• GitLab: Postmortem database outage tanggal 31 Januari
• Dropbox: Post-mortem mati
• Spotify: Hubungan Tresna / Sengit Spotify karo DNS
• Akeh liyane saka inti iki lan gudang Kisah Gagal Kubernetes
• Uga conto postmortem umum karo SRE Book

Source: www.habr.com