Eslatma tarjima: Bu kompaniyaning muhandislik blogidan ommaviy o'limdan keyingi tarjimasi . U Kubernetes klasteridagi ulanish bilan bog'liq muammoni tasvirlaydi, bu esa ba'zi ishlab chiqarish xizmatlarining qisman ishdan chiqishiga olib keldi.
Ushbu maqola postmortems haqida biroz ko'proq ma'lumot olishni yoki kelajakda ba'zi DNS muammolarini oldini olishni istaganlar uchun foydali bo'lishi mumkin.
Bu DNS emas
Bu DNS bo'lishi mumkin emas
Bu DNS edi
Preply-da o'limdan keyingi jarayonlar va jarayonlar haqida bir oz
Postmortem ishlab chiqarishdagi nosozlik yoki biron bir hodisani tasvirlaydi. O'limdan keyingi voqealar vaqt jadvalini, foydalanuvchi ta'sirini, ildiz sababini, qilingan harakatlarni va olingan saboqlarni o'z ichiga oladi.
Pitssa bilan haftalik uchrashuvlarda, texnik guruh o'rtasida biz turli xil ma'lumotlarni almashamiz. Bunday uchrashuvlarning eng muhim qismlaridan biri o'limdan keyin bo'lib, ular ko'pincha slaydlar bilan taqdimot va voqeani chuqurroq tahlil qilish bilan birga keladi. O'limdan keyin qarsak chalmasak ham, biz "ayb yo'q" madaniyatini rivojlantirishga harakat qilamiz (). Biz o'limdan keyin yozish va taqdim etish bizga (va boshqalarga) kelajakda shunga o'xshash hodisalarning oldini olishga yordam berishi mumkinligiga ishonamiz, shuning uchun biz ularni baham ko'ramiz.
Voqea sodir bo'lgan shaxslar jazo yoki qasos olishdan qo'rqmasdan batafsil gapira olishlarini his qilishlari kerak. Ayb yo'q! Postmortem yozish jazo emas, balki butun kompaniya uchun o'rganish imkoniyatidir.
Kubernetes-da DNS bilan bog'liq muammolar. O'limdan keyingi
Sana: 28.02.2020
Mualliflar: Amet U., Andrey S., Igor K., Aleksey P.
Holat: Tugallandi
Qisqacha: Kubernetes klasteridagi ba'zi xizmatlar uchun qisman DNS mavjud emas (26 daqiqa).
Ta'sir: A, B va C xizmatlari uchun 15000 XNUMX ta voqea yo'qolgan
Asosiy sabab: Kube-proksi eski yozuvni ulanish jadvalidan to'g'ri olib tashlay olmadi, shuning uchun ba'zi xizmatlar hali ham mavjud bo'lmagan podslarga ulanishga harakat qilmoqda.
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: ...Trigger: Kubernetes klasteridagi yuk pastligi tufayli CoreDNS-autoscaler tarqatishdagi podalar sonini uchtadan ikkitaga qisqartirdi.
yechim: Ilovaning navbatdagi joylashtirilishi yangi tugunlarni yaratishni boshladi, CoreDNS-autoscaler klasterga xizmat ko'rsatish uchun qo'shimcha podkastlarni qo'shdi, bu esa ulanish jadvalini qayta yozishga sabab bo'ldi.
Aniqlash: Prometey monitoringi A, B va C xizmatlari uchun ko'p sonli 5xx xatolarni aniqladi va navbatchi muhandislarga qo'ng'iroq qilishni boshladi.
Kibanada 5xx xatolik
Amallar
ta'sir
Kesuvchi apparat
Mas'ul
Maqsad
CoreDNS uchun avtomatik o'lchovni o'chirib qo'ying
oldini oldi
Amet U.
DEVOPS-695
Keshlash DNS serverini sozlang
pasayish
Maks V.
DEVOPS-665
Conntrack monitoringini o'rnating
oldini oldi
Amet U.
DEVOPS-674
O'rganilgan saboqlar
Nima yaxshi o'tdi:
- Monitoring yaxshi ishladi. Javob tez va tartibli edi
- Biz tugunlarda hech qanday cheklovga erishmadik
Nima bo'ldi:
- Haligacha noma'lum haqiqiy ildiz sababi, shunga o'xshash qarama-qarshilikda
- Barcha harakatlar asosiy sababni emas, balki faqat oqibatlarni tuzatadi (xato)
- Biz ertami-kechmi DNS bilan bog'liq muammolarga duch kelishimiz mumkinligini bilardik, lekin biz vazifalarni birinchi o'ringa qo'ymadik
Qayerda omadimiz keldi:
- Keyingi joylashtirish CoreDNS-autoscaler tomonidan ishga tushirildi, u ulanish jadvalini qayta yozdi.
- Bu xato faqat ba'zi xizmatlarga ta'sir qildi
Xronologiya (EET)
vaqt
ta'sir
22:13
CoreDNS-autoscaler podkastlar sonini uchtadan ikkitaga qisqartirdi
22:18
Navbatchi muhandislar monitoring tizimidan qo‘ng‘iroqlarni qabul qila boshladi
22:21
Navbatchi muhandislar xatolar sababini aniqlashga kirishdilar.
22:39
Navbatchi muhandislar so'nggi xizmatlardan birini oldingi versiyaga qaytarishni boshladilar
22:40
5xx xatolar paydo bo'lishni to'xtatdi, vaziyat barqarorlashdi
- Aniqlash vaqti: 4 daqiqa
- Harakatdan oldingi vaqt: 21 daqiqa
- Tuzatish vaqti: 1 daqiqa
qo'shimcha ma'lumot
- CoreDNS jurnallari:
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 - Kibana (kesilgan), Grafana (kesilgan) ga havolalar
CPU foydalanishni minimallashtirish uchun Linux yadrosi conntrack deb ataladigan narsadan foydalanadi. Qisqacha aytganda, bu maxsus jadvalda saqlanadigan NAT yozuvlari ro'yxatini o'z ichiga olgan yordamchi dastur. Keyingi paket bir xil poddan oldingi kabi bir xil podkaga kelganda, yakuniy IP manzil qayta hisoblanmaydi, lekin ulanish jadvalidan olinadi.
Contrack qanday ishlaydi
natijalar
Bu ba'zi foydali havolalar bilan bizning postmortems bir misol edi. Xususan, ushbu maqolada biz boshqa kompaniyalar uchun foydali bo'lishi mumkin bo'lgan ma'lumotlarni baham ko'ramiz. Shuning uchun biz xato qilishdan qo'rqmaymiz va shuning uchun biz o'limdan keyingi tekshiruvlarimizdan birini ommaga e'lon qilamiz. Mana yana bir nechta qiziqarli ommaviy o'limdan keyin:
- GitLab:
- Dropbox:
- Spotify:
- Ko'pgina boshqalardan va ombor
- Bundan tashqari SRE kitobi bilan ommaviy o'lim
Manba: www.habr.com