minikube პირად API-ს ვერ აღწევს? ჯერ დრაივერი შეამოწმეთ
ჰოსტს, კვანძსა და Pod-ს თითოეულს საკუთარი მარშრუტები და საკუთარი resolver აქვს. დაასახელეთ დრაივერი, შეამოწმეთ იგივე endpoint სამივედან და შემდეგ გაასწორეთ ის კონტექსტი, რომელიც ჩავარდა.
პირადი API პასუხობს თქვენი ლეპტოპიდან და minikube-ში არსებული Pod ვერ აღწევს მას. ჰოსტზე რაიმეს შეცვლამდე დაასახელეთ აქტიური პროფილის უკან მდგომი დრაივერი, რადგან ეს ერთი ფაქტი წყვეტს, რომელი ქსელიდან გადის სინამდვილეში მოთხოვნა. შემდეგ შეამოწმეთ იგივე endpoint ჰოსტიდან, კვანძიდან და Pod-იდან. მხოლოდ ერთია ამ სამიდან ის, რაც ჩავარდა, და არასწორი ვარაუდი შუადღეს ხარჯავს.
ნაბიჯი 0: დაასახელეთ დრაივერი და წყარო
ჰკითხეთ minikube-ს, რომელი პროფილია აქტიური და როგორ მუშაობს. კონტეინერის დრაივერი კვანძს თქვენს მანქანაზე არსებულ კონტეინერში ათავსებს, VM დრაივერი მას ვირტუალურ მანქანაში ათავსებს, ხოლო დისტანციური დრაივერი სრულიად სხვა ადგილას ათავსებს.
minikube profile list
minikube status
kubectl config current-contextაქედან ჩაწერეთ, საიდან მოდის მოთხოვნა. პასუხი განსაზღვრავს, რომელი resolver და რომელი მარშრუტებია მნიშვნელოვანი და ეს ყოველთვის ჰოსტისა არ არის. ერთსა და იმავე ლეპტოპზე ორი პროფილი ერთი და იმავე URL-ისთვის სრულიად განსხვავებულად შეიძლება მოიქცეს.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
ნაბიჯი 1: შეამოწმეთ იგივე endpoint სამჯერ
გამოიყენეთ ერთი უვნებელი endpoint და სამივე ტესტში იდენტურად შეინარჩუნეთ ჰოსტის სახელი, პორტი და მისამართების ოჯახი. თუ რომელიმეს შეცვლით გაშვებებს შორის, შედეგები შედარებადი აღარ იქნება.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthკვანძის მიერ image-ის წარმატებული ჩამოტვირთვა არაფერს ამტკიცებს პირადი ჰოსტისთვის სახელების გარჩევის შესახებ. წარმატებული საჯარო მოთხოვნა კიდევ ნაკლებს ამტკიცებს. შედეგები კონტექსტების მიხედვით ცალკე შეინახეთ, რადგან სამ სტრიქონში არსებული ნიმუში დიაგნოზია, ხოლო ერთეული წარუმატებლობა — მინიშნება.
თუ ჰოსტის სტრიქონიც ჩავარდა, გაჩერდით. თქვენ გაქვთ ჰოსტის ქსელის პრობლემა და კლასტერი ყურადღების გადატანაა.
ნაბიჯი 2: შეინარჩუნეთ ჰოსტის გზა კლასტერამდე
არსებობს მეორე მიმართულება, რომელსაც ადამიანები ივიწყებენ: ჰოსტმა უნდა განაგრძოს კლასტერის საკუთარ API-სა და სერვისებამდე აღწევა. VPN კლიენტს შეუძლია დააყენოს მარშრუტები, რომლებიც კონკურენციას უწევს იმ პრეფიქსებს, რომლებსაც minikube იყენებს თავისი კვანძების ქსელისთვის, სერვისების დიაპაზონისა და pod-ების დიაპაზონისთვის.
როცა ეს ხდება, სიმპტომი დამაბნეველია, რადგან გვირაბი მუშაობს და kubectl წყვეტს პასუხს ან NodePort უარყოფს კავშირებს. ეს კლასტერის გაუმართაობას ჰგავს და სინამდვილეში ლეპტოპის მარშრუტიზაციის გაუმართაობაა.
შეადარეთ ჰოსტის მარშრუტიზაციის ცხრილი minikube-ის დიაპაზონებს, სანამ გვირაბს სხვა რამეში დაადანაშაულებთ. გადაფარვა ჩვეულებრივ ჩანს როგორც უფრო კონკრეტული მარშრუტი, რომელიც მიუთითებს გვირაბის ინტერფეისზე იმ პრეფიქსისთვის, რომელსაც კლასტერი საკუთრად მიიჩნევს.
ნაბიჯი 3: გადაწყვიტეთ გადაფარვა VPN-ის გამორთვის გარეშე
minikube-ის საკუთარი VPN და proxy სახელმძღვანელო განიხილავს ამ კონფლიქტებს და მის მაგალითურ დიაპაზონებს განიხილავს როგორც შესამოწმებელ რამეს და არა როგორც უნივერსალურ სიას. წაიკითხეთ ის იმ პროფილთან ერთად, რომელიც ნამდვილად გაქვთ.
სადაც რეალური გადაფარვა არსებობს, მხარდაჭერილი პასუხია გადაუფარავი დიაპაზონი ან განზრახ ლოკალური წვდომის პოლიტიკა, დამტკიცებული VPN-ის მფლობელის მიერ. სერვისების დიაპაზონის შეცვლა არ არის იგივე, რაც pod-ების დიაპაზონის შეცვლა, და არც ერთი არ არის იგივე, რაც კვანძების ქსელის შეცვლა.
კორპორატიული გვირაბის გამორთვა, რომ ლოკალური კლასტერი იმუშაოს, გვერდის ავლა არ არის; ეს პოლიტიკური გადაწყვეტილებაა, რომელიც სხვამ უნდა მიიღოს. მიიტანეთ ის ამ ადამიანთან, ნაცვლად იმისა, რომ ეს ჩუმად გააკეთოთ მას შემდეგ, რაც ყველა სხვა სახლში წავიდა. თუ უკვე გააკეთეთ, დააბრუნეთ, სანამ იკითხავთ.
ნაბიჯი 4: გამოყავით proxy, DNS და ოთხი უკმარისობის ფორმა
თუ proxy საჭიროა, დაადგინეთ რომელ კონტექსტს სჭირდება ის. ჰოსტზე ბრაუზერის პარამეტრი არ აკონფიგურირებს პროცესს კვანძის შიგნით, ხოლო Pod-ს სჭირდება გარემოს ცვლადები ან კლასტერის დონის proxy კონფიგურაცია.
შემდეგ დააკლასიფიცირეთ უკმარისობა მისი აღწერის ნაცვლად. სახელი, რომელიც არ იხსნება, არის DNS. სახელი, რომელიც იხსნება და უარყოფს კავშირს, არის მარშრუტიზაცია ან listener. კავშირი, რომელიც მყარდება და იდენტობაზე ვარდება, არის TLS. წარმატებული კავშირი შეცდომის სხეულით არის აპლიკაცია.
ამ ოთხიდან თითოეული სხვა შესწორებას ეკუთვნის და მხოლოდ ერთი მათგანია VPN-ის შესახებ. ჩაწერეთ, რომელი დააკვირდით თითოეულ კონტექსტში, და შემდეგი ადამიანი მემკვიდრეობით მიიღებს მტკიცებულებებს და არა ისტორიას.