რატომ ვერ აღწევენ GKE-ის pod-ები ლოკალურ ჰოსტებამდე VPN-ით

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

წაიკითხეთ მოქმედი სია, სანამ რამეს შეცვლით

GKE აწვდის აგენტს, რომელიც დანიშნულების დიაპაზონების მიხედვით წყვეტს, გადაიწერება თუ არა pod-ების ტრაფიკი გასვლისას კვანძის მისამართზე. მისი ნაგულისხმევი კონფიგურაცია სამ RFC1918 ბლოკს, 10.0.0.0/8, 172.16.0.0/12 და 192.168.0.0/16, გამონაკლის დანიშნულებებად ასახელებს. ამიტომ ყველაფერი, რასაც pod-იდან ლოკალურ 10.x ჰოსტზე გაგზავნით, კვანძს ტოვებს pod-ის საკუთარი მისამართით ჯერ კიდევ მიმაგრებული. თავად კვანძის ტრაფიკი არ გადაიწერება, და სწორედ ამიტომ მუშაობს მისი ping.

წაიკითხეთ განზრახული კონფიგურაცია და დაყენებული წესები, რადგან ისინი შეიძლება არ ემთხვეოდეს. kubectl -n kube-system get configmap ip-masq-agent -o yaml გვიჩვენებს, რა უთხრეს აგენტს, და kubectl -n kube-system get pods -l k8s-app=ip-masq-agent გვიჩვენებს, მუშაობს თუ არა რამე მის გამოსაყენებლად. კვანძზე iptables-save | grep -i masq გვიჩვენებს წესებს, რომლებიც ბირთვში რეალურად არსებობს. როცა ConfigMap ერთს ამბობს და წესები მეორეს, ეჭვმიტანილი აგენტია და არა ქსელი.

დაადასტურეთ წყაროს მისამართი ჩაწერით

გააკეთეთ ჩაწერა სანამ სიას შეცვლით. ფილტრი ერთ დანიშნულებაზე გამოსავალს წაკითხვადს ტოვებს: tcpdump -ni any host 10.20.30.40.

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

შევიწროვეთ გამონაკლისი pod-ის CIDR-მდე

მხარდაჭერილი შესწორება ავიწროებს გამონაკლისს და არ აშორებს მას: დატოვეთ pod-ის CIDR გამონაკლისად და მოიშორეთ 10.x სივრცის დარჩენილი ნაწილი. ეს სია აგენტის ConfigMap-ში nonMasqueradeCIDRs-ის ქვეშ ცხოვრობს, და მისი შეცვლა რედაქტირებაა, რასაც გაშვება მოჰყვება. შეცვალეთ ფართო ჩანაწერი კლასტერის რეალური pod-ის დიაპაზონით, დატოვეთ სხვა კერძო ბლოკები, თუ კლასტერის შიდა ტრაფიკს ჯერ კიდევ სჭირდება ისინი, და resyncInterval-ს არ შეეხოთ, თუ მიზეზი არ გაქვთ. გამოიყენეთ, დაადასტურეთ რომ აგენტის pod-ები გადაიტვირთა და დაადასტურეთ რომ ბირთვის წესები შეიცვალა.

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

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

ალტერნატივა და მისი ფასი

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

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

შეამოწმეთ და დააბრუნეთ

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

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

დაბრუნება არის წინა ConfigMap, იმავე გზით გამოყენებული, იმავე დადასტურებით რომ აგენტი გადაიტვირთა და წესები შეიცვალა. ცვლილების ჩანაწერში შეინახეთ ერთი ცნობილი მოთხოვნის წყაროს მისამართი ცვლილებამდე და შემდეგ, რადგან სწორედ ის ერთი ხაზი ამტკიცებს, რომ ცვლილებამ ის გააკეთა, რაც თქვით. GKE-ის IP masquerade აგენტის გზამკვლევი აღწერს ნაგულისხმევებს და ConfigMap-ის ველებს. თუ წყაროს მისამართი გაშვების შემდეგ უცვლელია, აგენტი ამ კვანძზე არ მუშაობს და YAML-ის არანაირი რედაქტირება ამას არ გამოასწორებს.