← ყველა სტატია

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-ის ისტორიას მთლიანს ინახავს.