Masalah dengan DNS dalam Kubernetes. Postmortem awam

Catatan terjemahan: Ini adalah terjemahan postmortem awam daripada blog kejuruteraan syarikat Pra. Ia menerangkan masalah dengan conntrack dalam gugusan Kubernetes, yang membawa kepada masa henti separa beberapa perkhidmatan pengeluaran.

Artikel ini mungkin berguna untuk mereka yang ingin mengetahui lebih lanjut tentang bedah siasat atau mencegah beberapa masalah DNS yang berpotensi pada masa hadapan.

Ini bukan DNS
Ia tidak boleh menjadi DNS
Ia adalah DNS

Sedikit tentang bedah siasat dan proses dalam Preply

Postmortem menerangkan kerosakan atau beberapa kejadian dalam pengeluaran. Postmortem termasuk garis masa peristiwa, kesan pengguna, punca, tindakan yang diambil dan pengajaran yang dipelajari.

Mencari SRE

Pada mesyuarat mingguan dengan pizza, di kalangan pasukan teknikal, kami berkongsi pelbagai maklumat. Salah satu bahagian terpenting dalam mesyuarat tersebut ialah bedah siasat, yang selalunya disertai dengan pembentangan dengan slaid dan analisis yang lebih mendalam tentang kejadian itu. Walaupun kami tidak bertepuk tangan selepas bedah siasat, kami cuba membangunkan budaya "tidak menyalahkan" (budaya tanpa cela). Kami percaya bahawa menulis dan membentangkan bedah siasat boleh membantu kami (dan orang lain) mencegah kejadian serupa pada masa hadapan, itulah sebabnya kami berkongsinya.

Individu yang terlibat dalam sesuatu kejadian harus merasakan bahawa mereka boleh bersuara secara terperinci tanpa rasa takut akan hukuman atau pembalasan. Tak salahkan! Menulis postmortem bukanlah satu hukuman, tetapi peluang pembelajaran untuk seluruh syarikat.

Keep CALMS & DevOps: S adalah untuk Perkongsian

Masalah dengan DNS dalam Kubernetes. Postmortem

Tarikh: 28.02.2020

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

Status: Selesai

Secara ringkas: Ketidaksediaan DNS separa (26 min) untuk sesetengah perkhidmatan dalam gugusan Kubernetes

Pengaruh: 15000 acara hilang untuk perkhidmatan A, B dan C

Punca punca: Kube-proxy tidak dapat mengalih keluar masukan lama dengan betul daripada jadual conntrack, jadi sesetengah perkhidmatan masih cuba menyambung ke pod yang tidak wujud

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

Pencetus: Disebabkan oleh beban yang rendah di dalam gugusan Kubernetes, CoreDNS-autoscaler mengurangkan bilangan pod dalam penggunaan daripada tiga kepada dua

penyelesaian: Penggunaan aplikasi seterusnya memulakan penciptaan nod baharu, CoreDNS-autoscaler menambah lebih banyak pod untuk menyampaikan kluster, yang mencetuskan penulisan semula jadual conntrack

Pengesanan: Pemantauan Prometheus mengesan sejumlah besar ralat 5xx untuk perkhidmatan A, B dan C dan memulakan panggilan kepada jurutera yang bertugas

5xx ralat dalam Kibana

Aktiviti

kesan
Jenis
Bertanggungjawab
Petugas

Lumpuhkan autoscaler untuk CoreDNS
dihalang
Amet U.
DEVOPS-695

Sediakan pelayan DNS cache
berkurangan
Max V.
DEVOPS-665

Sediakan pemantauan conntrack
dihalang
Amet U.
DEVOPS-674

Pengajaran

Apa yang berjalan lancar:

• Pemantauan berjalan dengan baik. Sambutan adalah pantas dan teratur
• Kami tidak mencapai sebarang had pada nod

Apa yang salah:

• Masih tidak diketahui punca sebenar, serupa dengan pepijat tertentu dalam conntrack
• Semua tindakan membetulkan hanya akibat, bukan punca (pepijat)
• Kami tahu lambat laun kami mungkin menghadapi masalah dengan DNS, tetapi kami tidak mengutamakan tugas

Di mana kita bertuah:

• Arahan seterusnya telah dicetuskan oleh CoreDNS-autoscaler, yang menggantikan jadual conntrack
• Pepijat ini hanya menjejaskan beberapa perkhidmatan

Garis masa (EET)

Masa
kesan

22:13
CoreDNS-autoscaler mengurangkan bilangan pod daripada tiga kepada dua

22:18
Jurutera yang bertugas mula menerima panggilan daripada sistem pemantauan

22:21
Jurutera yang bertugas mula mengetahui punca kesilapan tersebut.

22:39
Jurutera yang bertugas mula melancarkan semula salah satu perkhidmatan terkini kepada versi sebelumnya

22:40
5xx ralat berhenti muncul, keadaan telah stabil

• Masa untuk pengesanan: 4 min
• Masa sebelum tindakan: 21 min
• Masa untuk membaiki: 1 min

maklumat tambahan

• Log 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

• Pautan ke Kibana (potong), Grafana (potong)
• Di mana Linux conntrack bukan lagi rakan anda
• Kehalusan kube-proxy: Menyahpepijat Tetapan Semula Sambungan Selang Sela
• Sambungan racy dan tamat masa carian DNS

Untuk meminimumkan penggunaan CPU, kernel Linux menggunakan sesuatu yang dipanggil conntrack. Ringkasnya, ini adalah utiliti yang mengandungi senarai rekod NAT yang disimpan dalam jadual khas. Apabila paket seterusnya tiba dari pod yang sama ke pod yang sama seperti sebelumnya, alamat IP akhir tidak akan dikira semula, tetapi akan diambil dari jadual conntrack.

Cara conntrack berfungsi

Keputusan

Ini adalah contoh salah satu bedah siasat kami dengan beberapa pautan yang berguna. Khususnya dalam artikel ini, kami berkongsi maklumat yang mungkin berguna kepada syarikat lain. Itulah sebabnya kami tidak takut untuk melakukan kesilapan dan itulah sebabnya kami membuat satu daripada bedah siasat kami kepada umum. Berikut adalah beberapa postmortem awam yang lebih menarik:

• GitLab: Postmortem gangguan pangkalan data pada 31 Januari
• Dropbox: Bedah siasat gangguan
• Spotify: Hubungan Cinta/Benci Spotify dengan DNS
• Ramai lagi dari intipati ini dan repositori Kisah Kegagalan Kubernetes
• Juga contoh bedah siasat awam dengan Buku SRE

Sumber: www.habr.com