ინციდენტებზე რეაგირება
რეალური ინციდენტების ანალიზი: პირველი მცდარი ვარაუდი, როგორ დამტკიცდა ძირეული მიზეზი და რა შეიცვალა შემდეგ.
9 სტატია
- ჩატვირთვის ეკრანი retry-ციკლი იყო და არა გაჭედვა — გადატვირთვა საჭირო არ ყოფილათამაში ჩემს Linux-კომპიუტერზე ჩატვირთვის ეკრანზე იჭედებოდა, ცნობილი წამალი კი სრული გადატვირთვა იყო. /proc-ის მთვლელების ხუთმა წამმა აჩვენა ციკლი, რომელიც ერთი SIGTERM-ით სრულდება.
- ექვსი საათი NotReady-ში, ნოდა კი მთელი ამ დროის განმავლობაში ცოცხალი იყოყველა სიგნალი ამბობდა, რომ ნოდა მკვდარია. სინამდვილეში მეხსიერება აკლდა, ხოლო აშკარა გამოსავალი — ნოდის წაშლა და ტომის იძულებითი მოხსნა — ერთი ბრძანებით იყო დაშორებული ბაზის დაზიანებისგან.
- ოთხი შემოწმება, რომელიც ტყუოდა, სანამ სისტემა ჯანსაღი იყოპლატფორმის მიგრაციების ერთ დღეში ოთხი შემოწმება შეცდომას აცხადებდა, თუმცა ყველაფერი რიგზე იყო. როცა ერთი სიგნალი ყველა დანარჩენს ეწინააღმდეგება, პირველ რიგში თავად სიგნალს ეჭვობდეთ.
- Vault თავისით ილუქებოდა. მიზეზი კლასტერის ქვემოთ VM-ის 15-წუთიანი გაყინვა იყოVault-ის ოთხი seal სამ კვირაში, თითოეული ცალკე ინციდენტად განიხილებოდა. journald-ის პაუზების ანალიზმა აჩვენა, რომ ჰიპერვიზორი ბექაპისას VM-ს ყინავს, Longhorn კი ამას კასკადად აქცევს.
- ერთმა დავიწყებულმა DHCP ოფციამ მთელი Kubernetes კლასტერი გათიშაჰოსტის გადატვირთვის შემდეგ ორმოცდაათამდე პოდი CrashLoop-ში წავიდა, თუმცა ყველა ნოდა Ready იყო. მიზეზი დავიწყებული DHCP classless routes ოფცია იყო, რომელმაც ნაგულისხმევი შლუზი ჩუმად წაშალა.
- სამი ინციდენტი, რომელიც ერთი აღმოჩნდა: კონფიგში ჩაწერილი მონაცემთა ბაზის IP500 შესვლისას, CrashLoopBackOff-ში მყოფი ბექენდები და გაჭედილი დეპლოი სამ პრობლემად გამოიყურებოდა. სამივე pgbouncer-ის კონფიგში ჩაწერილი ერთი IP აღმოჩნდა.
- „დისკის შეცდომები“ OOM აღმოჩნდა: როგორ დაკარგეს Longhorn-ის ტომებმა ბექენდიEIO, read-only ext4, დაზიანებული MySQL datadir და დალუქული Vault მომაკვდავ დისკს ჰგავდა. ჰოსტის dmesg-მა მთელი ნოდის OOM აჩვენა, რომელმაც პირველად Longhorn-ის instance-manager მოკლა.
- Longhorn-ის ტომი, რომელსაც გაზრდა არ სურდა: ცუდ ნოდაზე მიმაგრებული attachment ticketPVC დაუსრულებლად იდგა Resizing-ში, Longhorn კი ყოველ ხუთ წამში იმეორებდა გაფართოებას ერთი შეცდომის გარეშე. მოძველებული attachment ticket ტომს ერთ არაჯანსაღ ნოდაზე აკავებდა.
- Helm წერს „another operation is in progress“, თუმცა არაფერი მიმდინარეობსგაუქმებულმა CI ჯობმა ორი Helm რელიზი pending-upgrade-ში დატოვა და ყველა დეპლოი დაბლოკა. როგორ ვიპოვოთ lock, უსაფრთხოდ მოვხსნათ და მთელი namespace ერთბაშად შევამოწმოთ.