VPN-ის გვერდით კონტეინერს სჭირდება გაშვების წესი და წარუმატებლობის წესი

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

რიგითობა მხოლოდ პირველ მოთხოვნას ზღუდავს

Kubernetes მხარს უჭერს გვერდითი კონტეინერის სასიცოცხლო ციკლს, რომელიც გადატვირთვადი init კონტეინერებითაა აწყობილი. ამ მოდელში გაშვების პრობას შეუძლია შეაჩეროს შემდეგი ინიციალიზაციის ნაბიჯი, სანამ გვირაბი მზადყოფნას არ შეატყობინებს. ეს ნამდვილი გაუმჯობესებაა და ღირს მისი განზრახ გამოყენება, შესვლის წერტილის სკრიპტში sleep-ის დამატების ნაცვლად. ჭიშკარი იმდენად კარგია, რამდენადაც კარგია ის პირობა, რომელსაც ის ამოწმებს.

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

თქვით, რას აკვირდება ჭიშკარი: არსებობს პროცესი, არსებობს ინტერფეისი, handshake დასრულდა. თითოეული მათგანი უფრო სუსტი მტკიცებაა, ვიდრე „მონაცემთა გზა იმ დანიშნულებებამდე, რომლებიც ამ pod-ს სჭირდება, მუშაობს“.

აიძულეთ მონაცემთა გზა, ნაცვლად იმისა რომ ჩათვალოთ იგი

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

ერთ pod-ში კონტეინერები იზიარებენ ამ სახელთა სივრცეს, ამიტომ აღსრულების წერტილი თავად სახელთა სივრცეა. რაც არ უნდა დაწეროთ, მან ხელმისაწვდომი უნდა დატოვოს გვირაბის საკუთარი გარე კავშირი, რადგან მისი დაბლოკვა აპლიკაციის დასაცავად წყვეტს იმ გზას, რომელიც აპლიკაციას სჭირდება.

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

გამოსცადეთ ის ტრაფიკი, რომელიც არ ახსენეთ

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

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

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

დაწერეთ განლაგების ჩანაწერი

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

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

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