ოთხი შემოწმება, რომელიც ტყუოდა, სანამ სისტემა ჯანსაღი იყო

სახლის ლაბორატორიაში პლატფორმის მიგრაციების ერთ სამუშაო დღეში ოთხი სხვადასხვა შემოწმება აცხადებდა შეცდომას ან ობიექტის არარსებობას, თუმცა შესამოწმებელი მთელი ამ დროის განმავლობაში ჯანსაღი იყო. თითოეული ნამდვილ დეფექტს ჰგავდა. თითოეულმა რამდენიმე წუთიდან ერთ საათამდე არასწორი მიმართულებით სამუშაო დამიჯდა.

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

1. ველი, რომელიც ამ ვერსიაში არ არსებობს

ოთხი წუთი ველოდი VaultStaticSecret-ის .status.valid-ს. ოპერატორის ეს ვერსია ამის ნაცვლად SecretSynced, Healthy და Ready პირობებს აბრუნებს. jsonpath არარსებულ ველზე ცარიელ სტრიქონს აბრუნებს, რაც „ჯერ არ არის მზად“-ისგან არ განსხვავდება.

2. ლეიბლების სელექტორი, რომელიც ვერაფერს პოულობდა

ხუთი წუთი პლაგინის პოდს app.kubernetes.io/name-ით ვამოწმებდი, თუმცა პოდი Running-ში იყო სხვა ლეიბლებით. ცარიელი სია „ჯერ არ შექმნილა“-დ იკითხება და ტაიმაუტით შეცდომად არასოდეს იქცევა.

3. ორაზროვანი მოკლე სახელი

როცა Longhorn დაყენებულია, kubectl get backup იხსნება როგორც backups.longhorn.io და არა როგორც ჩემთვის საჭირო backups.postgresql.cnpg.io CloudNativePG-დან. ბაზის დასრულებული ბექაპი ყოველ შემოწმებაზე სტატუსის გარეშე ჩანდა, delete კი backups.longhorn.io ... not found-ით ეცემოდა.

4. apply-ის არასწორი სემანტიკა

kubectl apply --dry-run=server-მა სწორი მანიფესტი უარყო. კლიენტის მხარის სამმხრივი merge ვერ გაიგებს, რომ ფაილში არარსებული ველი უნდა წაიშალოს, თუ ცოცხალ ობიექტს last-applied-configuration ანოტაცია არ აქვს. ეს ობიექტი კი Argo CD-მ შექმნა server-side apply-ით. შემოწმებამ --server-side --field-manager=argocd-controller-ით ის მაშინვე მიიღო.

იგივე ოჯახი, საპირისპირო მიმართულებით

იმავე კვირაში კიდევ ორი შემოწმება საპირისპირო მიმართულებით ტყუოდა:

• curl -w '%{http_code}' ტრანსპორტის ნებისმიერ შეცდომაზე 000-ს აბრუნებს. ნამდვილი პასუხი გამოსვლის კოდში იყო — 35, TLS შეცდომა, ანუ კავშირი სინამდვილეში დამყარდა. 000-ის „კავშირი არ არის“-დ წაკითხვამ ქსელის დონეზე გამიშვა SNI-ის ნაცვლად.
• წარუმატებელმა პაჩმა კონტეინერს readiness პრობა წაუშალა და პოდი სამუდამოდ Ready გახდა: პრობის გარეშე კონტეინერი „განმარტებით“ მზადაა. ამას DNS-ის ორსაათიანი გათიშვა მოჰყვა.

მეორე მიმართულება უფრო საშიშია. შემოწმება, რომელიც ცრუ შეცდომას აცხადებს, დრო ჯდება. შემოწმება, რომელიც ცრუ წარმატებას აცხადებს, ავარიას მალავს და არაფერი გაიძულებს მასთან დაბრუნებას.

ჩვევა, რომელიც ყველა შემთხვევას წყვეტს

• როცა დანარჩენი ყველაფერი მწვანეა, პირველ რიგში შემოწმებას ეჭვობდეთ. თუ ნოდები, პოდები, კონტროლერები და ტრაფიკი ჯანსაღია და მხოლოდ ერთი პრობა არ ეთანხმება, სწორედ ის არის მთავარი ეჭვმიტანილი.
• ყოველ შემოწმებას — კონტროლი. დადებითი შედეგი არაფერს ნიშნავს ცნობილად კარგი შედარების გარეშე, უარყოფითი — ცნობილად ცუდის გარეშე.
• პროტოკოლის პასუხი გარსის შეჯამებაზე მნიშვნელოვანია. pg_stat_archiver ContinuousArchiving პირობის ნაცვლად, ნამდვილი ლოგინი „Secret არსებობს“-ის ნაცვლად.
• შეამოწმეთ თავად პრობის ლექსიკონი. არსებობს თუ არა ველი ამ ვერსიაში, ემთხვევა თუ არა სელექტორი, ცალსახაა თუ არა რესურსის სახელი, იგივე apply მექანიზმია თუ არა, რასაც ნამდვილი შემსრულებელი იყენებს?

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

Grafana-ს ნამდვილ ანგარიშზე არასწორი პაროლის ხუთმა მცდელობამ გადარჩევისგან დაცვა ჩართო, რომელიც ხუთი წუთის განმავლობაში სწორ პაროლსაც უარყოფდა. ჩემი გამავალი შემოწმება ჩავარდნილად იქცა და არარსებული ბაგი გამოიგონა. უარყოფითი კონტროლები არარსებული ანგარიშის წინააღმდეგ გაუშვით და დაბლოკილ ანგარიშს შემოწმებას ნუ გააგრძელებთ: ყოველი მცდელობა ბლოკს ახანგრძლივებს.

რა წავიღოთ

• ერთი წითელი სიგნალი ბევრ მწვანეს შორის ყველაზე სავარაუდოდ გატეხილ სიგნალს ნიშნავს.
• ცარიელი გამოტანა წარმატება არ არის. პრობა უნდა განასხვავებდეს „ჯერ არა“-ს და „ვერ ვპასუხობ“-ს.
• გამოიყენეთ რესურსების სრული სახელები, როცა ორ CRD-ს ერთნაირი kind აქვს.
• შეამოწმეთ იგივე apply მექანიზმით, რასაც ნამდვილი კონტროლერი იყენებს.
• მწვანეს ისეთივე ეჭვით მოეკიდეთ, როგორც წითელს.