minikube non chega a unha API privada? Comproba primeiro o controlador

Unha API privada responde desde o teu portátil e un Pod en minikube non pode alcanzala. Antes de cambiar nada no host, nomea o controlador detrás do perfil activo, porque ese único feito decide de que rede sae realmente a petición. Despois proba o mesmo endpoint desde o host, desde o nodo e desde o Pod. Só un deses tres é o que fallou, e unha suposición errónea custa unha tarde.

Paso 0: nomea o controlador e a orixe

Pregunta a minikube que perfil está activo e como se executa. Un controlador de contedor pon o nodo nun contedor na túa máquina, un controlador de VM pono nunha máquina virtual, e un controlador remoto pono noutro lugar completamente.

minikube profile list
minikube status
kubectl config current-context

A partir diso, anota de onde nace a petición. A resposta determina que resolver e que rutas importan, e non sempre é a do host. Dous perfís no mesmo portátil poden comportarse de forma completamente distinta para o mesmo URL.

Paso 1: proba o mesmo endpoint tres veces

Usa un endpoint inofensivo e mantén o mesmo nome de host, o mesmo porto e a mesma familia de enderezos nas tres probas. Cambiar calquera deles entre execucións fai que os resultados non sexan comparables.

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

Unha descarga de imaxe correcta por parte do nodo non demostra nada sobre a resolución de nomes para un host privado. Unha petición pública correcta demostra aínda menos. Separa os resultados por contexto, porque un patrón en tres filas é un diagnóstico e un fallo illado é unha pista.

Se a fila do host tamén falla, detente. Tes un problema de rede no host e o clúster é unha distracción.

Paso 2: conserva o camiño do host cara ao clúster

Hai unha segunda dirección que a xente esquece: o host ten que seguir chegando á API e aos servizos do propio clúster. Un cliente VPN pode instalar rutas que compiten cos prefixos que minikube usa para a súa rede de nodos, o seu rango de servizos e o seu rango de pods.

Cando iso ocorre, o síntoma é confuso, porque o túnel funciona e kubectl deixa de responder ou un NodePort rexeita conexións. Parece un fallo do clúster e é un fallo de enrutamento do portátil.

Comproba a táboa de rutas do host contra os rangos de minikube antes de culpar o túnel de calquera outra cousa. O solapamento adoita verse como unha ruta máis específica que apunta á interface do túnel para un prefixo que o clúster espera posuír.

Paso 3: resolve o solapamento sen desactivar a VPN

O propio manual de VPN e proxy de minikube trata estes conflitos e considera os seus rangos de exemplo como algo que inspeccionar, non como unha lista universal. Léoo xunto co perfil que realmente tes.

Onde existe un solapamento real, a resposta admitida é un rango que non se solape ou unha política de acceso local deliberada aprobada por quen é dono da VPN. Cambiar o rango de servizos non é o mesmo que cambiar o rango de pods, e ningunha das dúas cousas equivale a cambiar a rede de nodos.

Desactivar o túnel corporativo para que funcione un clúster local non é unha solución improvisada; é unha decisión de política que ten que tomar outra persoa. Llévaa a esa persoa en lugar de facelo en silencio despois de que todos os demais fosen para casa. Se xa o fixeches, volve poñelo antes de preguntar.

Paso 4: separa proxy, DNS e catro formas de fallo

Se se require un proxy, identifica que contexto o necesita. Un axuste do navegador no host non configura un proceso dentro do nodo, e un Pod necesita as variables de contorno ou unha configuración de proxy a nivel de clúster.

Despois clasifica o fallo en lugar de describilo. Un nome que non se resolve é DNS. Un nome que se resolve e rexeita unha conexión é enrutamento ou un listener. Unha conexión que se establece e falla na identidade é TLS. Unha conexión correcta cun corpo de erro é a aplicación.

Cada un deses catro pertence a unha corrección distinta, e só un ten que ver coa VPN. Anota cal observaches en cada contexto, e a seguinte persoa herda probas en lugar dun relato.