Catatan perev.: ini adalah terjemahan dari post- mortem publik dari blog Preply engineering . Ini menggambarkan masalah hubungan di kluster Kubernetes yang menyebabkan beberapa waktu berhenti layanan produksi.Artikel ini mungkin berguna bagi mereka yang ingin belajar sedikit lebih banyak tentang post-mortem atau untuk mencegah beberapa masalah potensial dengan DNS di masa depan.DNS
DNS
DNSPreply
- . , , , .
Seeking SRE
Pada pertemuan mingguan dengan pizza, di lingkaran tim teknis, kami berbagi berbagai informasi. Salah satu bagian terpenting dari pertemuan tersebut adalah post-mortem, yang paling sering disertai dengan presentasi dengan slide dan analisis yang lebih mendalam dari insiden tersebut. Terlepas dari kenyataan bahwa kita tidak "bertepuk tangan" setelah bedah mayat, kami mencoba mengembangkan budaya "tanpa menyalahkan " ( cluture tanpa cela ). Kami percaya bahwa menulis dan menyajikan post-mortem dapat membantu kami (dan tidak hanya) dalam mencegah insiden serupa di masa depan, itulah sebabnya kami membagikannya.Orang yang terlibat dalam insiden tersebut harus merasa bahwa mereka dapat berbicara secara terperinci tentang hal itu tanpa takut akan hukuman atau pembalasan. Tidak ada celaan! Menulis post-mortem bukanlah hukuman, tetapi kesempatan untuk belajar bagi seluruh perusahaan.
Pertahankan CALMS & DevOps: S untuk Berbagi
Masalah dengan DNS di Kubernetes. Post mortem
Tanggal: 02/28/2020Penulis: Amet U., Andrey S., Igor K., Aleksey P.Status: SelesaiSingkat: Tidak tersedianya sebagian DNS (26 mnt) untuk beberapa layanan di kluster KubernetesDampak: 15.000 acara hilang untuk layanan A,Penyebab root B dan C : Kube-proxy tidak dapat menghapus entri lama dari tabel conntrack dengan benar, sehingga beberapa layanan masih mencoba untuk terhubung ke pengiriman yang tidak adaE0228 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 kluster Kubernetes, CoreDNS-autoscaler mengurangi jumlah polong dalam penyebaran dari tiga menjadi duakeputusan: Aplikasi penyebaran lain memprakarsai pembuatan node baru, CoreDNS-autoscaler menambahkan lebih banyak deck untuk layanan cluster, yang memicu overtrite tabel daftar jejakDeteksi : Pemantauan Prometheus mendeteksi sejumlah besar kesalahan 5xx untuk layanan A, B dan C dan memulai panggilan ke teknisi yang sedang bertugas
kesalahan 5xx di KibanaTindakan
Pelajaran yang dipetik
Apa yang berjalan dengan baik:- Pemantauan bekerja dengan jelas. Reaksinya cepat dan teratur.
::- CoreDNS-autoscaler, conntrack
(EET)
- Waktu untuk deteksi: 4 mnt.
- Waktu untuk menyelesaikan tindakan: 21 mnt.
- Waktu untuk memperbaiki: 1 mnt
informasi tambahan
Untuk meminimalkan pemanfaatan prosesor, kernel Linux menggunakan hal seperti itu sebagai conntrack. Singkatnya, ini adalah utilitas yang berisi daftar entri NAT yang disimpan dalam tabel khusus. Ketika paket berikutnya datang dari pod yang sama ke pod yang sama seperti sebelumnya, alamat IP final tidak akan dihitung ulang, tetapi akan diambil dari tabel conntrack.
Bagaimana cara kerja conntrackRingkasan
Ini adalah contoh dari salah satu post-mortem kami dengan beberapa tautan yang bermanfaat. Khususnya dalam artikel ini kami membagikan informasi yang mungkin berguna bagi perusahaan lain. Itulah mengapa kita tidak takut untuk melakukan kesalahan dan itulah sebabnya kita membuat salah satu dari post-mortem menjadi publik. Berikut adalah beberapa tema post-mortem publik yang lebih menarik: