HTTP-вызовы изнутри кластера, не используя назначенный внешний IP-адрес

Question

У меня есть кубернете Service со статическим External IP, назначенным Replication Controller управляющим 1 приложениям, распределенным по 2 Pods. Я могу получить доступ к приложению, используя внешний IP, эта часть работает нормально.

Теперь я хочу, чтобы приложение было в Pods с использованием того же IP-адреса при выполнении HTTP-запросов для внешних приложений (вне кластера).

Простой вызов https://api.ipify.org/ показывает, что IP-адрес этого приложения полностью отличается от внешнего IP-адреса, на который он отвечает. Как я могу использовать один и тот же IP-адрес?

Answer 1

согласно documentation Назначение Service предназначено только для входного трафика. Наряду с этим некоторая взаимосвязанная документация от OpenShift не упоминает никаких параметров проксирования исходящего трафика через определенные Endpoint. Поэтому кажется, что вы пытаетесь сделать что-то, что не работает с Kubernetes из коробки.

Answer 2

Theshort и простой ответ - вы не можете. Вашим модулям назначены IP-адреса, которые являются внутренними для вашего кластера, скорее всего, из диапазона узлов каждого конкретного сетевого пространства. Когда речь идет о внешнем мире, трафик движется от внутреннего моста/IP, и если пункт назначения не является частью кластера, он уходит с помощью определенного узла маршрута по умолчанию, заканчивающегося на SNATed на IP-адрес узла или на IP шлюза NAT, если ваш трафик проходит через такой.

Даже если вы должны были создать пользовательские правила SNAT для контейнеров с помощью некоторых мониторов k8s и т. Д. (Подобно контроллеру входа), трафик все равно будет отскакивать от loadbalancer, а затем добираться до ваших стручков.

Если вам нужен поддерживаемый IP-адрес, что вы можете сделать, передайте свой трафик через NAT-шлюз и убедитесь, что он NAT, как вы ожидаете (это не даст вам тот же IP-адрес, что и ваш сервис, просто «стабильный» «один»), или сделать трафик, как HTTP-запросы, через PROXY со стабильным IP-адресом.

В целом, хотя в какой-то степени это вряд ли стоит головной боли при настройке.