Vault Secrets Operator seal-ის შემდეგ გაჩუმდა — და გადატვირთვამ ვერ გააღვიძა
43-დან 38 VaultStaticSecret ორი დღე გაყინული შეცდომით იდგა. Vault-ის unseal-მა და ოპერატორის გადატვირთვამ არაფერი მისცა; spec-ის ერთი ველის შეცვლამ უშველა.
Optimacros-ში bare-metal Kubernetes კლასტერი აპლიკაციების საიდუმლოებებს Vault-იდან Vault Secrets Operator-ის (VSO) გავლით იღებს. ერთ დღეს შევნიშნე, რომ 43-დან 38 VaultStaticSecret ობიექტი დაახლოებით ორი დღეა SecretSynced=False-ს აჩვენებს.
გაყინული შეცდომა არ არის განმეორებადი შეცდომა
პირობაში ეწერა 503 Vault is sealed და back-off horizon 4,939 წამი. რამდენჯერმე გამოვკითხე. Horizon ყოველ ჯერზე ნანოწამამდე ერთნაირი იყო. კონტროლერი, რომელიც მართლა იმეორებს მცდელობებს, ამ მნიშვნელობას ყოველ ჯერზე თავიდან ითვლის. ეს საერთოდ არ იმეორებდა.
ოპერატორის ლოგებიც ამას ადასტურებდა: seal-ის შემდეგ არც ერთი სტრიქონი. პოდი ცოცხალი იყო, leader lease-ს აგრძელებდა და CPU-ს რამდენიმე მილიკორს მოიხმარდა, მაგრამ არაფერს არ არეკონსილირებდა.
პირველი ფენა: ერთი დალუქული კვანძი Service-ის უკან
თავად 503-ს მარტივი მიზეზი ჰქონდა. Vault სამკვანძიან Raft კლასტერად მუშაობს და ერთი კვანძი დალუქული იყო. Service vault ყველა პოდზე ანაწილებს, ამიტომ VSO-ს წაკითხვების დაახლოებით მესამედი დალუქულ კვანძზე ხვდებოდა. ეს უცნაურ ნარევსაც ხსნიდა: ზოგი საიდუმლოება სინქრონდებოდა, ზოგი არა, უბრალოდ round-robin-ის იღბლით.
კვანძი გავხსენი და Vault-ის სამივე პოდი ready გახდა. VaultStaticSecret ობიექტები False დარჩნენ.
მეორე ფენა: რეკონსილაციის ციკლი მოკვდა
შემდეგ ორი ოფიციალური საშუალება ვცადე: ოპერატორის rollout restart და force-sync ანოტაცია გაჭედილ ობიექტებზე. არც ერთმა არაფერი შეცვალა.
აღმოჩნდა, რომ ეს VSO-ს ცნობილი ხარვეზია, hashicorp/vault-secrets-operator#840. seal-ისა და unseal-ის შემდეგ ცალკეული საიდუმლოებების lifetime watcher-ები კვდებიან და არც პერიოდული refreshAfter ტაიმერი, არც force-sync ობიექტებს რიგში არ აბრუნებს. Informer ცოცხალია, მაგრამ არაფერი არაფერს არ აყენებს რიგში თავიდან.
მაღვიძარა: spec-ის შეცვლა
Informer კვლავ რეაგირებს spec-ის ცვლილებებზე. ამიტომ თითოეულ გაჭედილ ობიექტზე spec.refreshAfter შევცვალე. ეს watch მოვლენას იწვევს, რეკონსილაცია ეშვება და ობიექტი True-ში გადადის. VSO წარმატებულ სინქრონიზაციებს info დონეზე არ წერს, ამიტომ ლოგები მაშინაც დუმდა, როცა ყველაფერი გამოვიდა; ერთადერთი სიგნალი პირობები იყო. როცა ყველაფერი დასინქრონდა, თავდაპირველი refreshAfter მეორე პატჩით დავაბრუნე.
ეს უსაფრთხო იყო, რადგან საიდუმლოებებს overwrite: false ჰქონდათ: მაღვიძარამ სტატუსი შეაკეთა და არსებული მონაცემები არ გადაწერა.
ნამდვილი გამოსწორება სხვაგანაა
spec-ის შეცვლა შემოვლითი გზაა. ამ კლასტერში Vault Shamir-ით იხსნებოდა auto-unseal-ის გარეშე, ამიტომ Vault-ის პოდის ყოველი გადატვირთვა კვანძს ლუქავდა და ყოველი seal VSO-ს კვლავ გააჩერებდა. ნამდვილი წამლები: VSO-ს განახლება ხარვეზის გამოსწორების მქონე ვერსიამდე და Vault-ის auto-unseal-ზე გადაყვანა, რომ seal საერთოდ აღარ მოხდეს.
რა უნდა დავიმახსოვროთ
- პირობის შეტყობინება, რომელიც გამოკითხვებს შორის არ იცვლება back-off-ის დროებამდე, მკვდარი რიგის ანაბეჭდია და არა ნელი განმეორების.
- Raft კლასტერის წინ მდგომი Service ტრაფიკს დალუქულ კვანძებზეც აგზავნის. ერთნაირ ობიექტებზე შერეული წარმატება ხშირად ნიშნავს, რომ ბექენდების ნაწილი ცუდადაა.
- თუ გადატვირთვები და force-sync ანოტაციები არ შველის, spec-ის უწყინარი ცვლილება informer-ში გადის და ობიექტს რიგში აბრუნებს.
- წყარო გამოასწორე: auto-unseal seal-ს აქრობს, განახლება კი გაჭედვას.