Tecnología · GUÍA PRÁCTICA
¿kubectl port-forward dice “connection refused”? Audite cuatro saltos antes de reintentar
Separe el listener local, el túnel API, el Pod elegido y el proceso dentro del Pod; el primer salto fallido determina la reparación.
Una conexión rechazada no es un único fallo: puede fallar el socket local, el stream API, un Pod que reinicia o el listener del puerto remoto dentro del Pod.
Conserve el comando y el primer error y audite los cuatro saltos. --address 0.0.0.0 solo amplía el listener local, puede exponerlo y no crea un listener en el Pod.
Conserve el comando y el primer fallo
Registre contexto, namespace, target, mapping, versión y toda salida anterior al primer rechazo.
Un bind local fallido exige otro puerto; forbidden o stream error exige revisar RBAC antes del workload.
Demuestre el Pod elegido
Guarde nombre, UID, nodo, inicio, readiness, reinicios y deletion timestamp del Pod.
Un rollout puede terminarlo tras la línea Forwarding; diagnostique con un Pod Running y Ready explícito.
Resuelva el puerto remoto
Compare Service port, targetPort y configuración real del Pod. Service 80 puede apuntar a Pod 8080.
Selector y EndpointSlice explican elegibilidad, pero no prueban que exista listener.
Verifique el listener dentro del Pod
Use un método de solo lectura aprobado para ver sockets TCP, proceso, protocolo y puerto en el namespace compartido.
Si no hay listener, corrija configuración o arranque. --address local no repara el rechazo remoto.
Reintente una vez
Cree un forward nuevo al Pod explícito, haga una petición con el protocolo correcto y confirme el mismo UID.
Termine solo cuando listener local, API stream, Pod y proceso remoto estén probados a la vez.
