დაითვალეთ პროქსის გასასვლელები რეპლიკებისგან ცალკე

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

client → published service → proxy replica → egress/NAT → destination

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

Docker Swarm-ის მარშრუტიზაციის ქსელი იღებს ტრაფიკს გამოქვეყნებულ სერვისის პორტზე და აგზავნის აქტიურ ამოცანაზე. ეს მხარს უჭერს შესვლის განაწილებას და ამოცანების განლაგების ცვლილებებს; ის არ ანიჭებს ცალკე საჯარო გასასვლელს თითოეულ რეპლიკას.

თუ ცალკე გასასვლელებია საჭირო, დააპროექტეთ მათი რეალური მარშრუტები და მისამართები, მაგალითად ცალკე მარშრუტიზებული ჰოსტები ან მინიჭებული გასასვლელი კარიბჭეები, შემდეგ კი დაითვალეთ დაკვირვებული გარეგანი იდენტობები.

რეპლიკის ჩანაცვლება ჩაანაცვლებს მის ცოცხალ ნაკადებსაც

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

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