StatefulSet-ის უცვლელი ველის შეცვლა ერთი პოდის გადატვირთვის გარეშე

Optimacros-ში GitOps რეპოზიტორია MySQL InnoDB Cluster-ს 20 GiB-იანი მონაცემთა ტომის შაბლონით და მორგებული MySQL კონფიგით აცხადებდა. ცოცხალი StatefulSet კი 6 GiB-იანი შაბლონებით და binlog-ის ნაგულისხმევი პარამეტრებით მუშაობდა, 30-დღიანი შენახვის ჩათვლით. Argo CD მთელი ამ დროის განმავლობაში Synced-ს და Healthy-ს აჩვენებდა.

რატომ იყო დრეიფი უხილავი

ორივე ველი მხოლოდ StatefulSet-ის აწყობის მომენტში მოქმედებს.

• StatefulSet-ის spec.volumeClaimTemplates უცვლელია. მისი დაპატჩვა შეუძლებელია.
• ოპერატორი MySQL-ის კონფიგს პოდების კონფიგურაციაში StatefulSet-ის შექმნისას წერს. შემდგომი sync მას თავიდან არ ხატავს.

selfHeal ცრუ თავდაჯერებულობას იძლეოდა. ის რესურსს ათანხმებდა — რესურსში კი მართლაც 20 GiB ეწერა. მაგრამ ოპერატორი არსებული StatefulSet-ის შაბლონს არ ცვლის (და ვერც შეცვლის) და მას თავად ხელახლა არ ქმნის. არსებული PVC-ებიც თავის ზომას ინარჩუნებენ. ასე რომ, მოძველებული იყო როგორც შაბლონი, ისე ცოცხალი ტომები, GitOps-ის ყველა ინდიკატორი კი იდეალურად გამოიყურებოდა.

ორი სხვადასხვა ამოცანა

დამეხმარა ამის ორ ნაწილად დაყოფა: მათ სხვადასხვა გამოსავალი აქვთ.

არსებული PVC-ები. მათი ცოცხლად გაფართოება შეიძლება. storage: 20Gi-ზე პატჩმა და Longhorn-ის ონლაინ გაფართოებამ დანარჩენი გააკეთა (ერთ-ერთს მეტი შრომა დასჭირდა, მაგრამ ეს ცალკე ამბავია).

StatefulSet-ის შაბლონი. აქ StatefulSet ხელახლა უნდა შეიქმნას, რომ რესურსიდან თავიდან აეწყოს. კითხვა ის იყო, როგორ გაკეთებულიყო ეს მომუშავე ბაზაზე გადატვირთვის გარეშე.

Orphan, ხელახალი შექმნა, adoption

kubectl delete sts <name> --cascade=orphan StatefulSet-ის ობიექტს შლის, მაგრამ მის პოდებს მუშაობას უტოვებს. იმავე სელექტორით ახალი StatefulSet მათ შემდეგ იღებს.

დაუნთაიმის გარეშე მუშაობის გასაღები განახლების სტრატეგია აღმოჩნდა. updateStrategy: OnDelete-ის დროს აყვანილი პოდი მხოლოდ შაბლონის შეცვლის გამო არ გადაიტვირთება: პოდები მხოლოდ მაშინ ახლდება, როცა ვინმე მათ წაშლის. RollingUpdate-ის დროს adoption შაბლონის ჰეშში სხვაობას დაინახავს და ყველა წევრს გადაატრიალებს — ასეთ რამეს მომსახურების ფანჯარაში აკეთებენ და არა სამშაბათს სადილის შემდეგ.

თანმიმდევრობა:

1. StatefulSet-ის სპეციფიკაციის ბექაპი და იმის შემოწმება, რომ updateStrategy არის OnDelete. თითოეული პოდის controller-revision-hash-ისა და ასაკის ჩაწერა.
2. StatefulSet-ის წაშლა --cascade=orphan-ით. პოდები მოთხოვნების მომსახურებას აგრძელებენ.
3. ოპერატორმა StatefulSet ხელახლა არ შექმნა, ამიტომ ბექაპიდან თავად გამოვიყენე: ზომა 20 GiB-მდე გაზრდილი, მომსახურე ველები ამოშლილი (status, uid, resourceVersion, managedFields და მსგავსი).
4. შემოწმება: შაბლონში 20 GiB, ready 3/3, თითოეულ პოდს ძველი რევიზიის ჰეში და შექმნის დრო აქვს — არაფერი გადატვირთულა.

ამის შემდეგ იგივე ცვლილება Git-ში დავაკომიტე, რომ ოპერატორის შემდეგი გადაწყობა ისევ არ დაშორებოდა.

სარისკო ფანჯარა

orphan წაშლასა და ხელახლა შექმნას შორის პოდებს არაფერი მართავს. თუ ამ ფანჯარაში რომელიმე მოკვდება, მას არავინ აწევს. ფანჯარა მოკლე დაიჭირეთ, მანიფესტი კი რაიმეს წაშლამდე მოამზადეთ.

დასკვნები

• Synced ნიშნავს, რომ Git ემთხვევა Argo CD-ის მიერ მართულ ობიექტებს. ველებზე, რომლებიც მხოლოდ შექმნისას გამოიყენება, ის არაფერს ამბობს.
• უცვლელი ან ერთხელ დახატული ველები შეიძლება უსასრულოდ ჩუმად დრეიფობდნენ. იცოდეთ ისინი ყოველი ოპერატორისთვის, რომელიც გაქვთ.
• --cascade=orphan updateStrategy: OnDelete-თან ერთად StatefulSet-ის შაბლონის გადაწყობის საშუალებას იძლევა data plane-ის შეხების გარეშე.
• RollingUpdate-ის დროს იგივე ხერხი ყველა წევრს გადატვირთავს. სტრატეგია დაწყებამდე შეამოწმეთ და არა შემდეგ.