minikube nu ajunge la un API privat? Verifică mai întâi driverul

Un API privat răspunde de pe laptop și un Pod din minikube nu îl poate atinge. Înainte să schimbi ceva pe host, numește driverul din spatele profilului activ, pentru că acest singur fapt decide din ce rețea pleacă de fapt cererea. Apoi testează același endpoint de pe host, de pe nod și din Pod. Doar unul dintre cele trei este cel care a eșuat, iar o presupunere greșită costă o după-amiază.

Pasul 0: numește driverul și originea

Întreabă minikube care profil este activ și cum rulează. Un driver de container pune nodul într-un container pe mașina ta, un driver de VM îl pune într-o mașină virtuală, iar un driver remote îl pune cu totul altundeva.

minikube profile list
minikube status
kubectl config current-context

De acolo, notează de unde provine cererea. Răspunsul determină al cui resolver și care rute contează, și nu este întotdeauna cel al hostului. Două profiluri pe același laptop se pot comporta complet diferit pentru același URL.

Pasul 1: testează același endpoint de trei ori

Folosește un endpoint inofensiv și păstrează identice numele de host, portul și familia de adrese în toate cele trei teste. Dacă schimbi oricare dintre ele între rulări, rezultatele nu mai sunt comparabile.

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

Un pull de imagine reușit de către nod nu dovedește nimic despre rezolvarea numelor pentru un host privat. O cerere publică reușită dovedește și mai puțin. Ține rezultatele separate pe contexte, pentru că un tipar pe trei rânduri este un diagnostic, iar o singură eșuare este un indiciu.

Dacă și rândul hostului eșuează, oprește-te. Ai o problemă de rețea pe host, iar clusterul este o distragere.

Pasul 2: păstrează calea hostului către cluster

Există o a doua direcție pe care oamenii o uită: hostul trebuie să continue să ajungă la API-ul și serviciile proprii ale clusterului. Un client VPN poate instala rute care concurează cu prefixele pe care minikube le folosește pentru rețeaua de noduri, intervalul de servicii și intervalul de poduri.

Când se întâmplă asta, simptomul este înșelător, pentru că tunelul funcționează și kubectl nu mai răspunde sau un NodePort refuză conexiuni. Pare o defecțiune a clusterului și este o defecțiune de rutare a laptopului.

Verifică tabelul de rutare al hostului față de intervalele minikube înainte să dai vina pe tunel pentru orice altceva. Suprapunerea se vede de obicei ca o rută mai specifică ce indică interfața tunelului pentru un prefix pe care clusterul se așteaptă să îl dețină.

Pasul 3: rezolvă suprapunerea fără a dezactiva VPN-ul

Manualul propriu de VPN și proxy al minikube discută aceste conflicte și tratează intervalele sale exemplu ca lucruri de inspectat, nu ca o listă universală. Citește-l împreună cu profilul pe care îl ai de fapt.

Acolo unde există o suprapunere reală, răspunsul acceptat este un interval care nu se suprapune sau o politică deliberată de acces local aprobată de cel care deține VPN-ul. Schimbarea intervalului de servicii nu este același lucru cu schimbarea intervalului de poduri, iar niciuna nu echivalează cu schimbarea rețelei de noduri.

Dezactivarea tunelului corporativ pentru ca un cluster local să funcționeze nu este o soluție ocolitoare; este o decizie de politică pe care trebuie să o ia altcineva. Du-o la acea persoană în loc să o faci în liniște după ce toți ceilalți au plecat acasă. Dacă ai făcut-o deja, pune-l la loc înainte să întrebi.

Pasul 4: separă proxy, DNS și patru forme de eșec

Dacă este necesar un proxy, identifică ce context are nevoie de el. O setare de browser pe host nu configurează un proces din interiorul nodului, iar un Pod are nevoie de variabilele de mediu sau de o configurație de proxy la nivel de cluster.

Apoi clasifică eșecul în loc să îl descrii. Un nume care nu se rezolvă este DNS. Un nume care se rezolvă și refuză o conexiune este rutare sau un listener. O conexiune care se stabilește și eșuează la identitate este TLS. O conexiune reușită cu un corp de eroare este aplicația.

Fiecare dintre cele patru ține de o remediere diferită, iar doar una dintre ele este despre VPN. Notează pe care ai observat-o în fiecare context, iar următoarea persoană moștenește dovezi în loc de o poveste.