У меня есть кластер Kubernetes AKS, работающий в подсети, подключенной к Site-2-Site. Kubernetes может автоматически создавать внешнюю LB для сервиса. В итоге получается такая конфигурация:
52.123.123.12TCP, Порт: 30231, Интервал: 5, Порог нездоровья: 2 (Заметка: 30231 порт, через который HTTPS доступен на каждом узле)TCP, Порт: 32525, Интервал: 5, Порог нездоровья: 2 (Заметка: 32525 порт, по которому HTTP доступен на каждом узле)52.123.123.12, Порт: 443, Backend порт: 443, Бэкэнд-пул: kubernetes (2 virtual machines), Зонд здоровья: the one for 3023152.123.123.12, Порт: 80, Backend порт: 80, Бэкэнд-пул: kubernetes (2 virtual machines), Зонд здоровья: the one for 32525Внешний LB отлично все маршрутизирует
Теперь я пытаюсь вручную создать такой же LB, за исключением внутренний. Я создал ILB и добавил бэкэнд-пул, зонды работоспособности и правила LB с той же конфигурацией, что и внешний LB выше (за исключением IP).
Внутренний LB находится на IP 10.240.140.5, которая является той же подсетью, что и сами узлы 10.240.140.0/24. Я могу добраться до обоих портов 30231,32525 на обоих узлах 10.240.140.1,10.240.140.2 напрямую, но если я попытаюсь достичь ILB (10.240.140.5:80 или 10.240.140.5:443) соединение просто разрывается. Хотя такая же точная конфигурация пула + зондов + правил отлично работала на внешнем LB.
Любые идеи?
Внешний LB использует общедоступные виртуальные IP-адреса с облачной службой, в которой размещены виртуальные машины. Внутренний LB находится на IP 10.240.140.5, который является частным IP-адресом, который мы не можем использовать для прямого подключения к LB или виртуальной машине публично.
Если вы хотите получить доступ к внутренней виртуальной машине из локальной сети, вы можете использовать P2S VPN-шлюз на портале Azure для маршрутизации трафика в виртуальную сеть из локальной сети.