Helm წერს „another operation is in progress“, თუმცა არაფერი მიმდინარეობს
გაუქმებულმა CI ჯობმა ორი Helm რელიზი pending-upgrade-ში დატოვა და ყველა დეპლოი დაბლოკა. როგორ ვიპოვოთ lock, უსაფრთხოდ მოვხსნათ და მთელი namespace ერთბაშად შევამოწმოთ.
ერთ დილას Gambchamp-ში ორი ბექენდ-სერვისის დეპლოის ჯობი ერთდროულად გაწითლდა. ორივე ერთი და იგივე ხაზით ჩავარდა:
Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress
ამ დროს არავინ არაფერს აყენებდა. არც ერთი პაიპლაინი არ მუშაობდა და არავის ჰქონდა ამ namespace-თან ტერმინალი გახსნილი. Helm კი ამტკიცებდა, რომ რაღაც ოპერაცია მიმდინარეობდა.
პირველი ვარაუდი და რატომ იყო მცდარი
როცა ორი სერვისი ერთად ვარდება, ჩვეულებრივ საერთო დამოკიდებულებაზე ეჭვობ: იმიჯების რეესტრზე, კლასტერის API-ზე, რანერზე. ჯერ სწორედ ისინი შევამოწმეთ. API პასუხობდა, იმიჯები იტვირთებოდა, სხვა namespace-ებში სხვა რელიზები ნორმალურად ყენდებოდა. პრობლემა მხოლოდ ამ ორ რელიზს ეხებოდა, და მათ ერთი რამ აერთიანებდა: ორივეს ერთი და იგივე პაიპლაინების ჯგუფი ერთსა და იმავე namespace-ში აყენებს.
რას იმახსოვრებს Helm სინამდვილეში
Helm რელიზის ყოველი რევიზიის მდგომარეობას Secret-ად ინახავს რელიზის namespace-ში. სტატუსი ლეიბლშია: deployed, superseded, failed — ან pending-install, pending-upgrade, pending-rollback. pending-* რევიზია სწორედ Helm-ის lock-ია. სანამ ის არსებობს, ამ რელიზისთვის ნებისმიერი ახალი helm upgrade უარს ამბობს დაწყებაზე.
helm history-მ ზუსტად ეს აჩვენა: ორივე რელიზის ბოლო რევიზია pending-upgrade-ში იყო და ორივე ერთსა და იმავე წუთში შეიქმნა.
ამ დროის ნიშნულმა ყველაფერი ახსნა. წინა დეპლოი helm upgrade --atomic-ის შუაში გააუქმეს (ან ტაიმაუტში ჩავარდა). --atomic შეცდომისას ავტომატურ დაბრუნებას გპირდება, მაგრამ მხოლოდ მაშინ, თუ Helm-ის პროცესი ამ დაბრუნებამდე იცოცხლებს. ჯობი შუა გზაზე მოკალი — და დაბრუნება არ მოხდება. Lock რჩება და ყოველი შემდეგი დეპლოი მას ეჯახება.
გამოსავალი
Lock იხსნება ბოლო რევიზიაზე დაბრუნებით, რომელიც მართლაც წარმატებით დასრულდა:
helm history <release> -n <ns> # ბოლო "deployed" რევიზიის პოვნა
helm rollback <release> <rev> -n <ns> # მასზე დაბრუნება pending-lock-ს ხსნის
დაბრუნების შემდეგ CI ჯობის გამეორებამ ნორმალურად გაიარა. რადგან ორი რელიზი ერთ წუთში გაიყინა, მათი სათითაოდ შეკეთება და მესამის გამოტოვება არ გვინდოდა. ერთი მოთხოვნა namespace-ში ყველა გაჭედილ რელიზს აჩვენებს:
kubectl -n <ns> get secret -l owner=helm -o json \
| jq -r '.items[] | select(.metadata.labels.status | test("pending"))
| "\(.metadata.labels.name) rev=\(.metadata.labels.version) status=\(.metadata.labels.status)"'
დასკვნები
another operation is in progressთითქმის ყოველთვისpending-*რევიზიას ნიშნავს. დაიწყეთhelm history-ით და არა ქსელით.--atomicგარანტია არ არის. ის მხოლოდ მაშინ აბრუნებს, თუ Helm ბოლომდე მუშაობს; გაუქმებული ჯობი lock-ს ტოვებს.- ერთი და იმავე დროის ნიშნულით გაჭედილი რამდენიმე რელიზი ერთი ინციდენტია: შეწყვეტილი პაკეტური დეპლოი ან მკვდარი რანერი. შეამოწმეთ მთელი namespace და ნუ შეაკეთებთ რელიზებს სათითაოდ.
- დაბრუნდით ბოლო
deployedრევიზიაზე და ნუ წაშლით რელიზის Secret-ებს ხელით: ეს შექცევადია და Helm-ის ისტორიას მთლიანს ინახავს.