Dado que hay un pod (p. ej., postgres) que se ejecuta en kubernetes, kubectl port-forward pod 15432:5432 se usa para exponer el pod al host.
normalmente, se puede acceder a él en el host ejecutando el cliente de postgres: psql -h 127.0.0.1 -p 15432 , O accediendo a http://127.0.0.1:15432 , O estableciendo una conexión TCP directamente: echo > /dev/tcp/127.0.0.1/15432 && echo yes . Si la conexión se establece correctamente, kubectl mostrará un mensaje Handling connection for 15432 para verificación.
Sin embargo, no es posible acceder al pod con reenvío de puertos usando 127.0.0.1 dentro del contenedor, a pesar de que se use o no la marca 172.17.0.1 --network=host . Solo se puede acceder a través host.docker.internal
Esto podría ser un problema que le ocurre exclusivamente a docker para mac. Todavía no he verificado en Linux.
Aquí están los registros cuando ejecuto la prueba de conexión dentro de la ventana acoplable. Muestra claramente que no se puede establecer la conexión TCP.
$ docker run --network=host -it --rm postgres:12.4 /bin/bash # inside container # unsuccessful for establishing TCP connection to 127.0.0.1:15432 root@docker-desktop:/# echo > /dev/tcp/127.0.0.1/15432 && echo yes bash: connect: Connection refused bash: /dev/tcp/127.0.0.1/15432: Connection refused # unsuccessful for establishing TCP connection to 172.17.0.1:15432 [root@docker-desktop /]# echo > /dev/tcp/172.17.0.1/15432 && echo yes bash: connect: Connection refused bash: /dev/tcp/172.17.0.1/15432: Connection refused # no surprise: unsuccessful for psql 127.0.0.1 root@docker-desktop:/# psql -h 127.0.0.1 -p 15432 psql: error: could not connect to server: could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 15432? # successful for host.docker.internal root@docker-desktop:/# psql -h host.docker.internal -p 15432 Password for user root:Aquí hay algunos registros de nslookup/ifconfig que podrían ser útiles:
Server: 192.168.65.1 Address: 192.168.65.1#53 Non-authoritative answer: Name: host.docker.internal Address: 192.168.65.2 bash-5.0# ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:984 (984.0 B) TX bytes:202 (202.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:29 (29.0 B) TX bytes:29 (29.0 B)¿Por qué hay una diferencia en la conectividad entre el contenedor docker y el host? ¿Cómo soluciona host.docker.internal el problema oculto? ¿Hay alguna otra forma de resolver el problema proporcionando indicadores de ejecución de la ventana acoplable?
Cuando se usa Docker para Mac o Windows, se usa una máquina virtual para ejecutar sus contenedores. Incluso con --net=host , el contenedor no se ejecutará directamente en su escritorio, sino en la máquina virtual. Por lo tanto, 127.0.0.1 es la IP de la VM, no la IP del host. Puede usar, como indicó, host.docker.internal en Mac / Windows para obtener la IP de la máquina real. En Linux, los contenedores se ejecutan sin una VM y, por lo tanto, directamente en el host real.
Es posible que desee investigar si la telepresencia podría resolver su caso de uso de una manera más general y sólida: https://www.telepresence.io/