Pod VPN Kubernetes-ში ან გასასვლელი კარიბჭე: ვის ეკუთვნის გვირაბი?
Pod საკუთარი ქსელური სახელთა სივრცეა, ამიტომ ნამდვილი არჩევანია, რომელი ფენა ფლობს გვირაბს: იდენტობა თითოეული დატვირთვისთვის თუ CNI-მართული გასასვლელი ერთი საერთო წყაროთი.
თქვენ ათავსებთ Pod-ს სახელად vpn-gateway, მიმართავთ სატესტო კლიენტს მის მისამართზე და ხედავთ, რომ პაკეტები ქრება. მანიფესტში არაფერია არასწორი და kubelet-ს საჩივარი არ აქვს. მიზეზი სტრუქტურულია და არა კონფიგურაციული: Kubernetes ყოველ Pod-ს აძლევს საკუთარ ქსელურ სახელთა სივრცეს, ამიტომ სახელი, ჭდე ან საერთო API სახელთა სივრცე ვერაფერს ცვლის იმაში, სად მიდიან პაკეტები. ამიტომ VPN ტრაფიკის კლასტერიდან გასვლის გადაწყვეტილება იწყება საკუთრების კითხვით და არა კონტეინერის იმიჯებით.
ორი მექანიზმი ფარავს რეალური განლაგებების უმეტესობას და ისინი ურთიერთშემცვლელი არ არის. ერთი გვირაბს დატვირთვის საკუთარ ქსელურ სახელთა სივრცეში ათავსებს. მეორე CNI-ს სთხოვს შერჩეული ტრაფიკი დანიშნული კარიბჭის კვანძის გავლით გაატაროს. ისინი სხვადასხვანაირად ფარდებიან, სხვადასხვანაირად სკალირდებიან და სხვადასხვა გუნდს ექვემდებარებიან, ამიტომ კონტეინერის კითხვა ჩვეულებრივ წარმოქმნის კამათს, რომელიც არასოდეს სრულდება.
Pod-ის საზღვარი სახელთა სივრცეა და არა ნახტომის ჰოსტი
Linux ქსელური სახელთა სივრცე ფლობს თავის ინტერფეისებს, მისამართებს, მარშრუტებსა და firewall-ის წესებს და ყოველი Pod იღებს ერთს. ამ Pod-ის შიგნით კონტეინერები მას უერთდებიან და სწორედ ამიტომ შეუძლია დამხმარე კონტეინერს გადაწეროს მარშრუტები, რომლებსაც შემდეგ აპლიკაცია მიჰყვება. მეზობელ Pod-ს აქვს იდენტურად გარეგნული, მაგრამ სრულიად ცალკე სტეკი. არ არსებობს საერთო ცხრილი, რომელსაც კარიბჭის Pod მემკვიდრეობით მიიღებს და არ არსებობს ტრაფიკის იმპლიციტური გადაცემა ერთი სახელთა სივრციდან მეორეში.
ამიტომაც კარიბჭის Pod-ის ნიმუში მუშაობს მხოლოდ მაშინ, როცა ზემოთ რაღაც ნამდვილად უგზავნის პაკეტებს: Service, კვანძზე სტატიკური მარშრუტი ან CNI-ში მართვის პოლიტიკა. მხოლოდ მისამართი არაფერს იზიდავს.
რას ყიდულობს გვირაბი თითო Pod-ზე და რა ღირს
დატვირთვის სახელთა სივრცეში მომუშავე გვირაბი ამ დატვირთვას აძლევს საკუთარ კლიენტის იდენტობას, რომელსაც ბევრი დისტანციური წვდომის სერვისი ითხოვს სესიის ავტორიზაციამდე ან აღრიცხვამდე. დაზიანების რადიუსიც ლოკალური რჩება: გატეხილი გვირაბი გამორთავს ერთ Deployment-ს და არა საერთო გზას, რომელსაც ყველაფერი იყენებს. როგორ მუშაობს, დამოკიდებულია იმპლემენტაციაზე და სწორედ აქ ცდებიან ადამიანები.
კონფიგურაცია, რომელსაც მხოლოდ ბირთვის მდგომარეობა სჭირდება, შეიძლება init კონტეინერში დასრულდეს და გავიდეს. მომხმარებლის სივრცის დემონს, რომელიც Pod-ის მთელი სიცოცხლის განმავლობაში უნდა ცოცხალი დარჩეს, სჭირდება გადატვირთვადი init კონტეინერის ფორმა, რომელიც Kubernetes 1.29-ში ნატიურ sidecar-ად დაინერგა, და ეს განსხვავება გვირაბის იმპლემენტაციიდან მოდის და არა გემოვნებიდან. ამ მოდელის ფასი დუბლირებაა: ყოველი რეპლიკა ავტორიზდება, იღებს საკუთარ გვირაბის მისამართს და იკავებს დისტანციური სესიის ადგილს, ამიტომ ავტოსკალირების მოვლენა კავშირის მეორე მხარეს ტევადობის მოვლენად იქცევა. ერთი სერტიფიკატის ყველა რეპლიკაში კოპირება ამ ფასს არ აქრობს, ის აუდიტის კვალს აქრობს. უფლებები იმავე განხილვას იმსახურებს, რადგან გვირაბს, რომელსაც საკუთარ სახელთა სივრცეში NET_ADMIN სურს, არ აქვს მიზეზი მემკვიდრეობით მიიღოს მთელი ჰოსტის ძალაუფლება privileged: true მაგალითიდან.
როცა CNI ფლობს გასასვლელს
თუ CNI ამას მხარს უჭერს, გასასვლელი კარიბჭე ტრაფიკს ირჩევს დატვირთვისა და დანიშნულების დიაპაზონის მიხედვით, შემდეგ აგზავნის მას შერჩეული კვანძებით ერთი პროგნოზირებადი წყაროს მისამართის ქვეშ. Cilium-ის ვერსია ჩვეულებრივი ცნობარია და მისი დოკუმენტაცია ცხადად ამბობს, რომ ფუნქციას სჭირდება კონკრეტული Cilium კონფიგურაცია და სწორი ინტერფეისებითა და მისამართებით აღჭურვილი კარიბჭის კვანძები. ის ასევე აღნიშნავს Pod-ის შექმნის შემდეგ საწყის პერიოდს, როცა მართვა ჯერ არ აღსრულდება, რაც დიზაინის შეტანაა და არა სქოლიო.
წაიკითხეთ ეს შეყოვნება თქვენივე დაპირების წინააღმდეგ. თუ წესია, რომ ვერც ერთი ტრაფიკი ვერ გავა სხვა გზით, უფსკრულის დროს გამავალი ახალი Pod უკვე დაარღვია ის, ამიტომ გაშვების თანმიმდევრობას საკუთარი პასუხი სჭირდება: შეაჩერეთ აპლიკაცია, სანამ პოლიტიკა ძალაში შევა, ან მიიღეთ ფანჯარა და დაამტკიცეთ.
შეინარჩუნეთ მტკიცება ვიწროდ. გასასვლელი კარიბჭე ირჩევს და თარგმნის გზას. ის არ ამთავრებს VPN-ს და კლასტერს თქვენი დისტანციური ქსელის კლიენტად არ აქცევს მის უკან მხარდაჭერილი კავშირის გარეშე.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
თარგმანი ჩუმად ცვლის იმას, რასაც დისტანციური მხარე ხედავს
როგორც კი კარიბჭე წყაროს გადაწერს, თითო Pod-ის მისამართები ქრება, ამიტომ იდენტობაზე დაფუძნებული ნებადართული სია ერთ საერთო მისამართზე დაფუძნებულ სიად იქცევა. ეს გაცვლაა და არა ხარვეზი: ნაკლები წესი მოსავლელად, უფრო უხეში მიკუთვნება, როცა რაღაც ცუდად იქცევა.
აპლიკაციის დონის ავტორიზაციამ და მოთხოვნების ლოგირებამ უნდა ატაროს ის, რასაც ქსელი აღარ აცნობებს. განიხილეთ კარიბჭის ტევადობა და ჩანაცვლება საერთო ინფრასტრუქტურად, რადგან ერთი კვანძის გადატვირთვა ახლა წყვეტს მის უკან ყოველ დატვირთვას, და ადრევე შეამოწმეთ დაბრუნების გზა: დისტანციურმა მხარემ უნდა იცოდეს, როგორ მიაღწიოს თარგმნილ მისამართს, ჩვეულებრივ მარშრუტით ან NAT-ით, რომელიც ადამიანმა და არა მანიფესტმა უნდა ფლობდეს. მისამართების დაგეგმვაც აქ ეკუთვნის, რადგან გადამკვეთი კლასტერისა და დისტანციური დიაპაზონები ორივე მოდელს ამსხვრევს და IPv6-ის მიღება წინააღმდეგობრივი გეგმის გამართლება არ არის.
გადაწყვიტეთ საკუთრებით, შემდეგ გამოსცადეთ დაპირებული ჩავარდნა
აირჩიეთ გვირაბი თითო Pod-ზე, როცა დისტანციური სერვისი ცალკეულ დატვირთვებს ავტორიზებს, როცა კავშირი მხოლოდ რამდენიმე Deployment-ს სჭირდება და როცა ჩავარდნა ლოკალური უნდა დარჩეს. აირჩიეთ კარიბჭე, როცა ქსელის გუნდი უკვე ფლობს გზას, როცა ბევრი დატვირთვა იზიარებს ერთ დანიშნულებას და როცა სტაბილური წყაროს მისამართი მთელი სავარჯიშოს აზრია.
ნებისმიერ შემთხვევაში, გადაამოწმეთ გაყიდული თვისება და არა სტაბილური მდგომარეობა. შექმენით Pod, მისცით მას დაუყოვნებლივ გაგზავნის საშუალება და დააკვირდით პირველ წამებს, თუ დაპირება იყო, რომ გვირაბიდან არაფერი გაურბის. ასწიეთ ხუთ რეპლიკამდე და დათვალეთ სესიები, რომლებზეც დისტანციური მხარე იტყობინება, თუ დაპირება თითო დატვირთვის იდენტობა იყო. ეს ორი შემოწმება გაცილებით სწრაფად ამჟღავნებს მექანიზმის საზღვრებს, ვიდრე მანიფესტის გადახედვა, და გეუბნებათ, რომელი გუნდი ფლობს შემდეგ ინციდენტს.