Vault თავისით ილუქებოდა. მიზეზი კლასტერის ქვემოთ VM-ის 15-წუთიანი გაყინვა იყო

Optimacros-ში ჩვენს ერთ-ერთ Kubernetes კლასტერში Vault სამ კვირაში ოთხჯერ დაილუქა — ყოველ ჯერზე სხვა პოდზე. ყოველ ჯერზე Vault Secrets Operator იყინებოდა და სინქრონიზებული 55 საიდუმლოებიდან 53 წყვეტდა განახლებას 503 Vault is sealed-ით. ყოველ შემთხვევას ცალკე ინციდენტად განიხილავდნენ და ხელით ასწორებდნენ.

დეტალი, რომელმაც გამოძიების მიმართულება შეცვალა: Vault-ის პოდები არ გადაიტვირთებოდა. restartCount ნულზე რჩებოდა. მათ ახალი UID-ებით ქმნიდნენ ხელახლა — და ყოველთვის ერთსა და იმავე ღამის ფანჯარაში.

ჯაჭვი

ტრიგერი კლასტერის ქვემოთ აღმოჩნდა. ჰიპერვიზორი VM-ის დონის ბექაპისას VM-ს „აყუჩებს“, დანარჩენი კი Kubernetes-მა გააკეთა:

ჰიპერვიზორი ყინავს VM-ს (13-15 წთ, ღამით)
  -> liveness პრობები ვადაგასულია
     -> Longhorn engine-ს მკვდრად აცხადებს 8-10 წამში
        -> instance-manager პოდი ხელახლა იქმნება, iSCSI სესიები წყდება
           -> ნოდზე Longhorn ტომების მქონე ყველა პოდი ხელახლა იქმნება
              -> Vault ახალ პოდად ბრუნდება -> Shamir -> sealed
                 -> საიდუმლოებების სინქრონიზაცია 503-ს იჭერს და ეკიდება

როგორ დავამტკიცე, რომ VM გაყინული იყო

აშკარა ეჭვმიტანილები ნელი დისკი და მეხსიერების ნაკლებობა იყო და ორივე მონაცემებმა გამორიცხა:

• journald-ის დროის ნიშნულები. kubelet-ის ჩანაწერები ნიშნულით 21:27 journald-ში 21:42-ზე მოხვდა. პროცესი 15 წუთის განმავლობაში არაფერს წერდა, შემდეგ კი ბუფერი გადმოყარა. Prometheus-ის საკუთარ მონაცემებშიც ზუსტად ასეთი ხვრელი იყო.
• dmesg იმავე მომენტში: მასობრივი EXT4-fs unmounting, attempt to access beyond end of device, შემდეგ iSCSI ინიციატორის ახალი სესია. ტომები იხსნებოდა და ხელახლა უერთდებოდა.
• დისკი უქმად იყო. IO time და iowait პაუზისას ნულთან ახლოს იყო. I/O-ს ნახტომი მოგვიანებით მოხდა — ხელახლა მიერთებისას.
• მეხსიერება ზღვართან ახლოსაც არ მისულა: შვიდი დღის განმავლობაში ხელმისაწვდომი მეხსიერების მინიმუმი 48-დან 71 პროცენტამდე იყო.

გადამწყვეტი ტესტი იყო journald-ის პაუზების ანალიზი 14 დღის განმავლობაში ყოველ ნოდზე: ყოველი ადგილის გამოტანა, სადაც OS ათ წუთზე მეტხანს არაფერს წერდა. იყინებოდა შვიდიდან მხოლოდ ორი ნოდი, ყოველ ჯერზე 13–15 წუთით, და instance-manager ყოველი „გალღობის“ შემდეგ მაშინვე ხელახლა იქმნებოდა. სწორედ ამ ნოდებზე იყო ჩართული VM-ის ბექაპები.

იმავე მონაცემებიდან კიდევ ერთი გაკვეთილი: steal time და გაყინვები სხვადასხვა მოვლენაა. იმავე გადატვირთულ ჰიპერვიზორზე მყოფ control plane ნოდს იმდენივე steal ჰქონდა, რამდენიც გაყინულ ვორკერს, მაგრამ არც ერთხელ არ გაყინულა. ბექაპები ცალკეული VM-ის დონეზე ირთვება, steal კი ფიზიკური ჰოსტის თვისებაა. 15-წუთიანი „დაყუჩება“ პათოლოგიაა: ჯანსაღი სნეპშოტისას ის წამზე ნაკლებია.

რისი გამოსწორება შეგვეძლო ჩვენი მხრიდან

ძირეული მიზეზი ვირტუალიზაციის გუნდის ზონაში იყო, ამიტომ ის ზუსტი დროის ნიშნულებით ესკალაციაში გადავეცით. კლასტერში:

1. Longhorn engine-replica-timeout 8-დან 30 წამამდე — მისი მაქსიმუმი, გამოყენებული ერთი instance-manager-ის ხელახლა შექმნის გარეშე.
2. საიდუმლოებების ოპერატორი ახლა vault-active Service-ს მიმართავს. ჩვეულებრივი Service არამზა მისამართებსაც აქვეყნებს, ამიტომ დალუქული პირი როტაციაში რჩებოდა და მოთხოვნების დაახლოებით მესამედი მასზე ხვდებოდა. vault-active მხოლოდ გახსნილ ლიდერს ირჩევს.
3. ალერტები რეალურ ჯაჭვზე: instance-manager ხელახლა შეიქმნა, ნოდი არ პასუხობს VM-ის გაყინვის მსგავსად, Vault-ის პოდი არ არის მზად.

instance-manager-ის liveness ტაიმაუტი შეგნებულად არ გავზარდე: მისი შეცვლა instance-manager-ებს ყველა ნოდზე ერთბაშად ქმნის ხელახლა, 15-წუთიან გაყინვას კი არანაირი ტაიმაუტი არ გადაურჩება.

უხერხული შენიშვნა

ნოდების VM ბექაპებიდან გამორიცხვა სწრაფ გამოსავლად ჩანდა, მაგრამ იმ დროს Longhorn-ს backup target არ ჰქონდა კონფიგურირებული. მავნე VM ბექაპები ერთადერთი არსებული ბექაპები იყო, ამიტომ ისინი ნორმალური ბექაპების საცავის გაჩენამდე უნდა დარჩენილიყო.

რა წავიღოთ

• გადატვირთვა და ხელახლა შექმნა სხვადასხვა სიგნალია. პოდის ახალი UID ფიქსირებულ ფანჯარაში პოდის ქვემოთ მიუთითებს.
• journald-ის პაუზების ანალიზი „დაყუჩებული“ VM-ის იაფი და გადამწყვეტი ტესტია.
• დისკი და მეხსიერება ციფრებით გამორიცხეთ, სანამ მათ დაადანაშაულებთ.
• Steal ჰოსტის თვისებაა; გაყინვები ცალკეულ VM-ზე ოპერაციებიდან მოდის, მაგალითად ბექაპებიდან.
• გრძელი ტაიმაუტები მოკლე შეფერხებების შემსუბუქებაა და არა 15-წუთიანი გაყინვის მკურნალობა.