Pod, კვანძი თუ კლასტერი: რას ცვლის სინამდვილეში VPN sidecar

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

საერთო სახელთა სივრცე, საერთო შედეგები

ორი კონტეინერი Pod-ში loopback-ით საუბრობს და ერთსა და იმავე ინტერფეისებს ხედავს, და სწორედ ამიტომ მუშაობს sidecar-ის ნიმუში: აპლიკაციას არ სჭირდება იცოდეს, რომ გვირაბი არსებობს, რადგან მარშრუტი, რომელზეც ის მიდის, დაყენებულია იმ სახელთა სივრცეში, რომელსაც ის იყენებს. იგივე თვისება ნიშნავს, რომ sidecar-ის შეცდომები აპლიკაციის შეცდომებია. ზედმეტად ბევრის დამჭერი მარშრუტი, ან DNS-ის ცვლილება, რომელიც გვირაბის შიგნით არსებულ გადამწყვეტზე მიუთითებს, დაუყოვნებლივ ვრცელდება ამ Pod-ის ყველა პროცესზე. საერთო სახელთა სივრცეში კონტეინერის მიხედვით მარშრუტიზაცია არ არსებობს, ამიტომ sidecar-ის ერთ პროცესზე შეზღუდვა შეუძლებელია.

ეს არის ის მექანიზმი, რომელიც განხილვისას უნდა გვახსოვდეს: ზემოქმედების რადიუსი Pod-ია, არა კვანძი და არა კლასტერი.

სადაც sidecar არ აღწევს

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

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

მარშრუტის გეგმა: Pod-ის, სერვისის, კვანძისა და VPN-ის დიაპაზონები

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

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

გაშვება და მარცხი ცხადი მდგომარეობებია

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

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

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

შესაძლებლობები, პოლიტიკა და ტესტირება აპლიკაციის კონტეინერიდან

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

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

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