GKE-ის კერძო კვანძები არ განსაზღვრავენ, რომელ API-ს იყენებს kubectl

კვანძები კერძოა, VPN აღწევს მათში, და მაინც kubectl ვერ ელაპარაკება კლასტერს. ეს ორი ფაქტი ერთმანეთთან არ არის დაკავშირებული. მისამართი, რომელსაც kubectl იყენებს, მოდის kubeconfig-ში შენახული სერვერის URL-იდან, რომელიც სერტიფიკატების მიღებისას ჩაიწერა, და თქვენ მიერ დამატებული არც ერთი მარშრუტი მას არ ცვლის. იმავდროულად, კვანძები სულაც არ არის ის, რისკენაც kubectl ცდილობს მიღწევას.

ხუთი შემოწმება, დაწყებული ერთადერთი მნიშვნელოვანი მნიშვნელობით.

შემოწმება 1: წაიკითხეთ სერვერის URL kubeconfig-ში

დაბეჭდეთ საბოლოო წერტილი სერტიფიკატების გამოფრქვევის გარეშე: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". ეს ერთი სტრიქონი გეუბნებათ, მიუთითებს კლიენტი IP მისამართზე, DNS სახელზე თუ გარე მისამართზე, რომელიც არ გიგულისხმიათ. ამ გამოძიებაში ყველაფერი სხვა აქედან გამომდინარეობს.

თუ URL არ არის ის საბოლოო წერტილი, რომლის კონფიგურირებასაც ფიქრობდით, დიაგნოზის დარჩენილი ნაწილი ყურადღების გადატანაა.

შემოწმება 2: შეუსაბამეთ URL საბოლოო წერტილის ტიპს

მიმდინარე GKE მხარს უჭერს მართვის სიბრტყეზე წვდომას როგორც IP-ზე, ისე DNS-ზე დაფუძნებულად, და მიღებული სერტიფიკატები ერთ-ერთს ირჩევს. gcloud container clusters get-credentials NAME --location REGION --internal-ip წერს შიდა IP-ის საბოლოო წერტილს, ხოლო --dns-endpoint ირჩევს DNS-ზე დაფუძნებულ წვდომას. არც ერთი დროშა არ უზრუნველყოფს ქსელურ მარშრუტს, რაც აკვირვებს მათ, ვინც ელოდება, რომ სერტიფიკატების მიღება დააფიქსირებს კავშირს. გაიმეორეთ მიღება განზრახ და შემდეგ კვლავ წაიკითხეთ URL.

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

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

შემოწმება 3: დაამტკიცეთ გზა ამ საბოლოო წერტილამდე

თუ URL შიდა IP-ა, შეამოწმეთ მარშრუტი იმ ქსელიდან, სადაც კლიენტი რეალურად ზის, დაშვებული წყაროს დიაპაზონი და კლასტერის რეგიონალური ან გლობალური წვდომის პარამეტრი. მართვის სიბრტყის დიაპაზონი და კვანძების ქვექსელი ერთი და იგივე დანიშნულება არ არის, ამიტომ კვანძებამდე მოქმედი მარშრუტი საბოლოო წერტილზე არაფერს ამტკიცებს. DNS-ზე დაფუძნებული წვდომისთვის გზა არის Google API-სთან კავშირი მისი დოკუმენტირებული Private Google Access განლაგებით, და არა მარშრუტი მუშაკთა ქვექსელამდე. შეამოწმეთ საბოლოო წერტილი ჩვეულებრივი TCP კავშირით, სანამ kubectl-ს დაადანაშაულებთ.

დროის ამოწურვა გზის პრობლემაა. 403 პოლიტიკის პრობლემაა. მათ საერთო გამოსავალი არ აქვთ.

შემოწმება 4: გამოყავით ლოგები და exec API გამოძახებებისგან

თუ ჩვეულებრივი API მოთხოვნები წარმატებით სრულდება და kubectl logs ან kubectl exec ვერ ხერხდება, თქვენ უკვე გაიარეთ საბოლოო წერტილის არჩევა. ამ ოპერაციებს სჭირდება შესაბამისი Kubernetes ნებართვები და დამოკიდებულია მართვის სიბრტყის კომუნიკაციაზე კვანძებთან, ხოლო წარუმატებლობა შეიძლება იყოს Forbidden პასუხი და არა დროის ამოწურვა. კვანძზე SSH წვდომა სრულიად სხვა სერვისს ამოწმებს და მათ არ ამკვიდრებს.

წაიკითხეთ შეცდომის კლასი, სანამ VPN-ის ბილეთს ხელახლა გახსნით, რადგან ეს ორი კლასი სხვადასხვა ადგილას ცხოვრობს.

შემოწმება 5: შემდეგი ადამიანისთვის სამი დაკვირვება შეინახეთ

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

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