Мы запускаем частный кластер GKE через GCP. Наши сервисы доступны в Интернете через nginx-ingress и TCP LB, внесенные в белый список в определении service.yaml.
Один из наших модулей пытается получить доступ к другому модулю через Public LB. (Я знаю, что это не лучшая практика, но давайте предположим, что приложение должно работать только таким образом, и мы не можем справиться с кластерной связью.)
Я также добавил статический IP-адрес NAT в белый список LB, и я могу видеть IP как правило брандмауэра, подключенное к узлам GKE.
Что я пытался отладить:
Создайте новый экземпляр, установите nginx и разрешите соединения только с IP-адреса NAT, добавив правила брандмауэра. Я также попытался подключить tcp LB к этому экземпляру nginx, и у меня нет проблем с доступом к странице примера nginx из модулей A и B.
Когда я пытаюсь подключиться к модулям из других источников из белого списка, у меня нет никаких проблем.
Поскольку kube-proxy не следует протоколу прокси, nginx внутри кластера никогда не узнает реальный публичный IP-адрес, который ему нужно заблокировать или разрешить.
NGINX ingress не использует службы (kube-proxy) для маршрутизации трафика к модулям. Вместо этого он использует API конечных точек. Таким образом, использование прокси-протокола должно работать, но вам также необходимо включить его с помощью ConfigMap .
Тем не менее, чтобы иметь возможность подключаться к вашим экземплярам по ssh, необходимо иметь хост-бастион. Убедитесь, что вы создали правило брандмауэра, разрешающее SSH-соединение. Убедитесь, что вы следуете инструкциям из этой документации: gke-nat.