Pod IP, ClusterIP ან შიდა დატვირთვის ბალანსერი VPN მომხმარებლებისთვის
Pod IP მარშრუტიზებადია VPN-ის გავლით მანამ, სანამ Pod შეიცვლება. შეადარეთ პირდაპირი წვდომა Pod-ზე, ClusterIP და შიდა ბალანსერი, და რა ღირს თითოეული მათგანი.
VPC CNI-ით Pod-ს შეუძლია მიიღოს მისამართი VPC-დან, და სწორი მარშრუტის მქონე VPN მომხმარებელს შეუძლია პირდაპირ მიაღწიოს მას. ამიტომ Pod-ზე პირდაპირი წვდომა უმარტივეს ვარიანტად გვეჩვენება, და ასეც არის, სანამ Pod შეიცვლება. მისამართი, რომელიც მომხმარებელს ახსოვს, უნდა ეკუთვნოდეს აპლიკაციას და არა რეპლიკას. სამი შესასვლელის შედარება იმაზე მოდის, რომელი ობიექტი ფლობს მისამართს და რა უნდა განაგრძოს მუშაობა, როცა დატვირთვა გადაადგილდება.
აირჩიეთ ჯერ სასიცოცხლო ციკლის მიხედვით, შემდეგ იმის მიხედვით, თუ რა უნდა გააკეთოს ქსელმა შესასვლელის ხელმისაწვდომობისთვის.
სამი შესასვლელი, სამი სასიცოცხლო ციკლი
Pod IP ეკუთვნის Pod-ს: გამოიყოფა მასთან ერთად და გაათავისუფლება მის დასრულებისას. ClusterIP ეკუთვნის Service-ს და ვირტუალურია, მას აზრი მხოლოდ იქ აქვს, სადაც კლასტერის სერვისების მარშრუტიზაცია არსებობს. შიდა ბალანსერს ფლობს ღრუბლოვანი რესურსი, რომელსაც კლასტერის კონტროლერი ბექენდებით აპროგრამებს. ეს მფლობელობის მოდელები წინასწარ გვიმხელს იმ ხარვეზს, რომელსაც მიიღებთ: მოძველებული მისამართი, მიუწვდომელი სახელი ან მოძველებული ბექენდების ნაკრები.
ჩაწერეთ შედარება არჩევამდე. როცა მფლობელი და ხარვეზი დასახელებულია, არჩევანი ჩვეულებრივ თავისით კეთდება.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
პირდაპირი წვდომა Pod-ზე: სასარგებლო, დროებითი
პირდაპირი წვდომა მართლაც სასარგებლოა კონტროლირებადი შემოწმებისთვის: ერთი ადმინისტრატორი, ერთი მოკლე სესია, ერთი კონკრეტული პორტი. მაგრამ მომხმარებლებისთვის ეს ცუდი ხელშეკრულებაა, რადგან მისამართი იმპლემენტაციის დეტალია, რომელიც ყოველ გაშვებაზე იცვლება. ხოლო მისი ვიკიში ჩაწერა იმ გზას წარმოადგენს, რომლითაც მომუშავე სერვისი ჭორად იქცევა.
ის ფართო წესებსაც იწვევს. ერთი ადმინისტრატორის ნებართვა ერთ Pod-ზე წვდომისთვის არ არის ნებართვა კვანძის ქვექსელის ყველა მისამართზე, და ჩვეულებრივ სწორედ მეორე იწერება.
ClusterIP: დიზაინით კლასტერით შემოფარგლული
ClusterIP მუშაობს, რადგან კლასტერის მონაცემთა სიბრტყე მისთვის მარშრუტიზაციას კლასტერის შიგნით აპროგრამებს. VPN-ზე მყოფი ლეპტოპიდან მისამართი არაფერს ნიშნავს, თუ რაღაც მას განზრახ არ ამხელს. სახელი, რომელიც svc.cluster.local-ით მთავრდება, კლასტერის DNS-ს ეკუთვნის, ამიტომ მისი სხვა გადამწყვეტის მქონე კლიენტზე კოპირება მარშრუტიზაციის შეცდომის ნაცვლად არარსებულ სახელს წარმოქმნის.
ClusterIP რჩება სწორ შესასვლელად კლასტერის შიგნით მოწვევებისთვის, სხვა დატვირთვების ჩათვლით. ის უბრალოდ არ არის გამოქვეყნების მექანიზმი კლასტერის მარშრუტიზაციის დომენის გარეთ მყოფი მომხმარებლებისთვის.
შიდა ბალანსერი: გამოქვეყნებული გზა
შიდა ბალანსერი გაძლევთ სტაბილურ კერძო მისამართს და სახელს, რომელზეც თქვენი ზონა მიუთითებს, ხოლო კონტროლერი ბექენდების ნაკრებს აქტუალურად ინახავს, როგორც აღწერს EKS-ის დატვირთვის ბალანსირების გზამკვლევი. ეს არის შესასვლელი, რომელიც გადაურჩება ჩვეულებრივ Pod-ის შეცვლას ისე, რომ ვინმემ დოკუმენტი არ შეასწოროს. მისი ფასია ღრუბლოვანი რესურსი, კონტროლერის კონფიგურაცია და მარშრუტი VPN-დან, და სწორედ ეს ნაწილები არ აფასებენ ადამიანები სათანადოდ.
გამოიყენეთ ის კონტროლერის მოდელი, რომელსაც კლასტერი რეალურად აწარმოებს. ერთი ინტეგრაციისთვის დაწერილი ანოტაციები მეორეზე არ ვრცელდება.
ვინ არის წყაროს მისამართი
უსაფრთხოების ჯგუფები ხედავენ იმ წყაროს, რომელიც მათ საზღვარზე მოდის, და ეს შეიძლება იყოს დაკავშირებული კლიენტი ან თარგმნილი მისამართი VPN-ისა და ბალანსირების გზის მიხედვით. EC2-ზე დაფუძნებულ კვანძებზე ჩვეულებრივი VPC CNI Pod-ები ნაგულისხმევად კვანძის ENI ჯგუფებს მემკვიდრეობით იღებენ, ხოლო მხარდაჭერილი კონფიგურაციები Pod-ისთვის სპეციფიკურ ჯგუფებს ამატებენ. წესები დაწერეთ დოკუმენტირებული გზისთვის და არა სავარაუდო ლეპტოპის მისამართისთვის.
შეინარჩუნეთ აპლიკაციის საკუთარი მსმენელი და ავთენტიფიკაცია ცალკე კონტროლებად. ქსელური წესი, რომელიც ნაკადს უშვებს, ავტორიზაციის გადაწყვეტილება არ არის და ასეც არ უნდა განიხილებოდეს.
რა მივცეთ მომხმარებლებს
მიეცით მომხმარებლებს სერვისის სახელი და არა მისამართი. გამოაქვეყნეთ სახელი კერძო ზონაში, მიუთითეთ ის შიდა შესასვლელზე, შემდეგ შეამოწმეთ ბექენდ Pod-ის შეცვლით, სანამ კლიენტი იმავე სახელს ღიად ინახავს. ეს ვარჯიში ამოწმებს იმ თვისებას, რაც მნიშვნელოვანია: იმავე აპლიკაციამდე მისვლა ჩვეულებრივი განთავსების შემდეგ.
შეინარჩუნეთ Pod-ზე პირდაპირი წვდომა როგორც საკუთარი არეალის მქონე დოკუმენტირებული ოპერაციული გამონაკლისი, მომხმარებლის ინსტრუქციებისგან მოშორებით.