Невозможно получить доступ к приложению, запущенному на хосте, из модуля в kubernetes, запущенного с использованием minikube

Question

У меня возникла проблема, из-за которой я не могу получить доступ к приложению, запущенному на хост-компьютере, из приложения, запущенного на Pod Kubernetes в Minikube.

В данном случае приложение, запущенное на хост-компьютере, является базой данных Postgre, а приложение, запущенное в модуле psql, на самом деле это приложение ядра Dotnet, разработанное мной, но я использую здесь psql для целей моделирования. .

Operating System   : Windows 10 Pro
Minikube version   : 0.30.0
Kubernetes version : 1.11.0
VM driver          : HyperV

Моя хост-сеть выглядит так:

Ethernet adapter vEthernet (DockerNAT):
   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::7970:dbd6:f9ab:b9b0%18
   IPv4 Address. . . . . . . . . . . : 10.0.75.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (Primary Virtual Switch):
   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.100.33
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.100.1

Ethernet adapter vEthernet (Default Switch):
   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::241f:1091:ab14:ff1c%24
   IPv4 Address. . . . . . . . . . . : 172.24.251.177
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Default Gateway . . . . . . . . . :

Я выбрал Default Switch в качестве Virtual Switch для виртуальной машины minikube в настройках HyperV. Я пытался использовать Primary Virtual Switch, но он также не работает.

Default Switch - тип подключения к внутренней сети.

Primary Virtual Switch - тип подключения к внешней сети.

Сеть Minikube выглядит следующим образом:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul                                                                                                                                                             t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa                                                                                                                                                             ult qlen 1000
    link/ether 00:15:5d:fb:b1:29 brd ff:ff:ff:ff:ff:ff
    inet 172.24.251.182/28 brd 172.24.251.191 scope global dynamic eth0
       valid_lft 86321sec preferred_lft 86321sec
    inet6 fe80::215:5dff:fefb:b129/64 scope link
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gr                                                                                                                                                             oup default
    link/ether 02:42:e7:f1:e1:ad brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e7ff:fef1:e1ad/64 scope link
       valid_lft forever preferred_lft forever
6: veth61a3792@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue mas                                                                                                                                                             ter docker0 state UP group default
    link/ether 52:fb:43:92:d0:f1 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::50fb:43ff:fe92:d0f1/64 scope link
       valid_lft forever preferred_lft forever

<I omitted the remaining veth interfaces>

Я уверен, что БД Postgre доступна из любого места, потому что когда я пытался получить к нему доступ из приложения, запущенного в контейнере Docker, развернутого в Docker Swarm, он мог успешно подключиться, а также я установил pg_hba. конфиг на это:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

host    all             all             127.0.0.1/32            md5
host    all             all             0.0.0.0/0               md5
host    all             all             ::1/128                 md5
host    replication     all             127.0.0.1/32            md5
host    replication     all             ::1/128                 md5

Некоторые другие вещи, которые я пытался найти причину проблемы

kubectl run -i --tty myalpine --image=alpine -- sh

/ # ping 172.24.251.177
PING 172.24.251.177 (172.24.251.177): 56 data bytes
64 bytes from 172.24.251.177: seq=0 ttl=127 time=0.351 ms
64 bytes from 172.24.251.177: seq=1 ttl=127 time=0.961 ms

/ # traceroute 172.24.251.177
traceroute to 172.24.251.177 (172.24.251.177), 30 hops max, 46 byte packets
 1  172.17.0.1 (172.17.0.1)  0.006 ms  0.006 ms  0.003 ms
 2  *  *  *
 3  *  *  *

/ # psql -h 172.24.251.177 -U myuser -d mydb
psql: could not connect to server: Operation timed out
        Is the server running on host "172.24.251.177" and accepting
        TCP/IP connections on port 5432?

Есть ли шанс, что некоторые из вас, ребята, тоже столкнулись с этой проблемой? или я что-то здесь упускаю?

Спасибо.