Masalah dengan DNS di Kubernetes. Postmortem publik

Catatan terjemahan: Ini adalah terjemahan dari postmortem publik dari blog teknik perusahaan Siap. Ini menjelaskan masalah koneksi di cluster Kubernetes, yang menyebabkan downtime sebagian pada beberapa layanan produksi.

Artikel ini mungkin berguna bagi mereka yang ingin mempelajari lebih lanjut tentang postmortem atau mencegah beberapa potensi masalah DNS di masa mendatang.

Ini bukan DNS
Itu tidak mungkin DNS
Itu adalah DNS

Sedikit tentang postmortem dan proses di Preply

Postmortem menggambarkan kegagalan fungsi atau kejadian tertentu dalam produksi. Postmortem mencakup kronologi peristiwa, deskripsi dampak pengguna, akar permasalahan, tindakan yang diambil, dan pembelajaran.

Mencari SRE

Pada pertemuan mingguan dengan pizza, di antara tim teknis, kami berbagi berbagai informasi. Salah satu bagian terpenting dari pertemuan tersebut adalah pemeriksaan mayat, yang paling sering disertai dengan presentasi dengan slide dan analisis yang lebih mendalam mengenai kejadian tersebut. Meskipun kami tidak bertepuk tangan setelah pemeriksaan mayat, kami berusaha mengembangkan budaya “tidak menyalahkan” (budaya yang tidak bercela). Kami percaya bahwa menulis dan menyajikan pemeriksaan postmortem dapat membantu kami (dan orang lain) mencegah kejadian serupa di masa depan, itulah sebabnya kami membagikannya.

Individu yang terlibat dalam suatu insiden harus merasa bahwa mereka dapat berbicara secara rinci tanpa takut akan hukuman atau pembalasan. Jangan salahkan! Menulis postmortem bukanlah hukuman, melainkan kesempatan belajar bagi seluruh perusahaan.

Tetap Tenang & DevOps: S untuk Berbagi

Masalah dengan DNS di Kubernetes. Postmortem

Дата: 28.02.2020

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

Judul: Selesai

Secara singkat: Tidak tersedianya DNS parsial (26 menit) untuk beberapa layanan di cluster Kubernetes

Dampak: 15000 kejadian hilang untuk layanan A, B dan C

Akar masalah: Kube-proxy tidak dapat menghapus entri lama dengan benar dari tabel conntrack, sehingga beberapa layanan masih mencoba terhubung ke pod yang tidak ada

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: Karena beban rendah di dalam cluster Kubernetes, autoscaler CoreDNS mengurangi jumlah pod dalam penerapan dari tiga menjadi dua

solusi: Penerapan aplikasi berikutnya memulai pembuatan node baru, CoreDNS-autoscaler menambahkan lebih banyak pod untuk melayani cluster, yang memicu penulisan ulang tabel conntrack

Deteksi: Pemantauan Prometheus mendeteksi sejumlah besar kesalahan 5xx untuk layanan A, B, dan C dan memulai panggilan ke teknisi yang bertugas

Kesalahan 5xx di Kibana

Aktivitas

efek
Jenis
Bertanggung jawab
Tugas

Nonaktifkan penskala otomatis untuk CoreDNS
dicegah
Amet U.
DEVOPS-695

Siapkan server DNS caching
mengurangi
Maks V.
DEVOPS-665

Siapkan pemantauan koneksi
dicegah
Amet U.
DEVOPS-674

Pelajaran yang Dipetik

Apa yang berjalan dengan baik:

• Pemantauannya berjalan dengan baik. Responsnya cepat dan terorganisir
• Kami tidak mencapai batasan apa pun pada node

Apa yang salah:

• Masih belum diketahui akar penyebab sebenarnya, mirip dengan bug tertentu dalam koneksi
• Semua tindakan hanya memperbaiki konsekuensinya, bukan akar permasalahannya (bug)
• Kami tahu bahwa cepat atau lambat kami mungkin mengalami masalah dengan DNS, namun kami tidak memprioritaskan tugas tersebut

Dimana kami beruntung:

• Penerapan berikutnya dipicu oleh autoscaler CoreDNS, yang menimpa tabel conntrack
• Bug ini hanya mempengaruhi beberapa layanan

Garis Waktu (EET)

Waktu
efek

22:13
CoreDNS-autoscaler mengurangi jumlah pod dari tiga menjadi dua

22:18
Insinyur yang bertugas mulai menerima panggilan dari sistem pemantauan

22:21
Para insinyur yang bertugas mulai mencari tahu penyebab kesalahan tersebut.

22:39
Insinyur yang bertugas mulai mengembalikan salah satu layanan terbaru ke versi sebelumnya

22:40
Kesalahan 5xx berhenti muncul, situasi sudah stabil

• Waktu untuk mendeteksi: 4 menit
• Waktu sebelum bertindak: 21 menit
• Saatnya untuk memperbaiki: 1 menit

informasi 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

• Tautan ke Kibana (potong), Grafana (potong)
• Dimana koneksi Linux bukan lagi teman Anda
• Kehalusan kube-proxy: Men-debug Reset Koneksi Intermiten
• Koneksi bersemangat dan batas waktu pencarian DNS

Untuk meminimalkan penggunaan CPU, kernel Linux menggunakan sesuatu yang disebut conntrack. Singkatnya, ini adalah utilitas yang berisi daftar catatan NAT yang disimpan dalam tabel khusus. Ketika paket berikutnya tiba dari pod yang sama ke pod yang sama seperti sebelumnya, alamat IP akhir tidak akan dihitung ulang, tetapi akan diambil dari tabel conntrack.

Cara kerja koneksi

Hasil

Ini adalah contoh salah satu postmortem kami dengan beberapa tautan bermanfaat. Khusus pada artikel kali ini kami berbagi informasi yang mungkin bermanfaat bagi perusahaan lain. Itu sebabnya kami tidak takut membuat kesalahan dan itulah sebabnya kami mempublikasikan salah satu postmortem kami. Berikut beberapa postmortem publik yang lebih menarik:

• GitLab: Postmortem pemadaman basis data pada 31 Januari
• Dropbox: Pemadaman bedah mayat
• Spotify: Hubungan Cinta/Benci Spotify dengan DNS
• Banyak lainnya dari inti ini dan repositori Kisah Kegagalan Kubernetes
• Juga contoh postmortem publik dengan Buku SRE

Sumber: www.habr.com