¿minikube no llega a una API privada? Revisa primero el controlador
El host, el nodo y el Pod tienen sus propias rutas y su propio resolver. Nombra el controlador, prueba el mismo endpoint desde los tres y corrige después el contexto que falló.
Una API privada responde desde tu portátil y un Pod en minikube no puede alcanzarla. Antes de cambiar nada en el host, nombra el controlador que hay detrás del perfil activo, porque ese único dato decide por qué red sale realmente la petición. Después prueba el mismo endpoint desde el host, desde el nodo y desde el Pod. Solo uno de esos tres es lo que falló, y equivocarse cuesta una tarde.
Paso 0: nombrar el controlador y el origen
Pregunta a minikube qué perfil está activo y cómo se ejecuta. Un controlador de contenedor pone el nodo en un contenedor de tu máquina, un controlador de VM lo pone en una máquina virtual, y un controlador remoto lo pone en otro sitio por completo.
minikube profile list
minikube status
kubectl config current-contextA partir de eso, anota de dónde nace la petición. La respuesta determina qué resolver y qué rutas importan, y no siempre es el del host. Dos perfiles en el mismo portátil pueden comportarse de forma completamente distinta para la misma 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 |
Paso 1: probar el mismo endpoint tres veces
Usa un endpoint inofensivo y mantén el mismo nombre de host, el mismo puerto y la misma familia de direcciones en las tres pruebas. Cambiar cualquiera de ellos entre ejecuciones hace que los resultados no sean 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/healthUna descarga de imagen correcta por parte del nodo no demuestra nada sobre la resolución de nombres para un host privado. Una petición pública correcta demuestra aún menos. Separa los resultados por contexto, porque un patrón en tres filas es un diagnóstico y un fallo aislado es una pista.
Si la fila del host también falla, detente. Tienes un problema de red en el host y el clúster es una distracción.
Paso 2: conservar el camino del host hacia el clúster
Hay una segunda dirección que la gente olvida: el host tiene que seguir llegando a la API y a los servicios del propio clúster. Un cliente VPN puede instalar rutas que compiten con los prefijos que minikube usa para su red de nodos, su rango de servicios y su rango de pods.
Cuando eso ocurre, el síntoma es confuso, porque el túnel funciona y kubectl deja de responder o un NodePort rechaza conexiones. Parece un fallo del clúster y es un fallo de enrutamiento del portátil.
Comprueba la tabla de rutas del host contra los rangos de minikube antes de culpar al túnel de cualquier otra cosa. El solapamiento suele verse como una ruta más específica que apunta a la interfaz del túnel para un prefijo que el clúster espera poseer.
Paso 3: resolver el solapamiento sin desactivar la VPN
El propio manual de VPN y proxy de minikube trata estos conflictos y considera sus rangos de ejemplo como algo que inspeccionar, no como una lista universal. Léelo junto al perfil que realmente tienes.
Donde existe un solapamiento real, la respuesta admitida es un rango que no se solape o una política de acceso local deliberada aprobada por quien es dueño de la VPN. Cambiar el rango de servicios no es lo mismo que cambiar el rango de pods, y ninguna de las dos cosas equivale a cambiar la red de nodos.
Desactivar el túnel corporativo para que funcione un clúster local no es un apaño; es una decisión de política que tiene que tomar otra persona. Llávasela a esa persona en lugar de hacerlo en silencio después de que todos los demás se hayan ido a casa. Si ya lo hiciste, vuelve a ponerlo antes de preguntar.
Paso 4: separar proxy, DNS y cuatro formas de fallo
Si se requiere un proxy, identifica qué contexto lo necesita. Un ajuste del navegador en el host no configura un proceso dentro del nodo, y un Pod necesita las variables de entorno o una configuración de proxy a nivel de clúster.
Luego clasifica el fallo en lugar de describirlo. Un nombre que no se resuelve es DNS. Un nombre que se resuelve y rechaza una conexión es enrutamiento o un listener. Una conexión que se establece y falla en la identidad es TLS. Una conexión correcta con un cuerpo de error es la aplicación.
Cada uno de esos cuatro pertenece a una solución distinta, y solo uno tiene que ver con la VPN. Anota cuál observaste en cada contexto, y la siguiente persona hereda pruebas en lugar de un relato.