Как назначить один статический IP-адрес источника для всех модулей службы или развертывания в kubernetes? - PullRequest
Новая
       4

Как назначить один статический IP-адрес источника для всех модулей службы или развертывания в kubernetes?

2 голосов
/ 13 февраля 2020

Рассмотрим микросервис X, который упакован в контейнер и развернут в кластере kubernetes. X связывается с платежным шлюзом PG. Однако платежному шлюзу требуется статический c IP для служб, с которыми он связывается, поскольку он поддерживает белый список IP-адресов, которым разрешен доступ к платежному шлюзу. X может связаться с PG через сторонний прокси-сервер, такой как QuotaGuard, который предоставит статический c IP-адрес для услуги X, который может быть внесен в белый список Платежным шлюзом. Однако существует ли в kubernetes встроенный механизм, который позволяет службе, развернутой в кластере kube, получать статический c IP-адрес?

Ответы [ 2 ]

2 голосов
/ 13 февраля 2020

в Кубернетесе пока нет механизма для этого.

другие возможные решения:

  • если узлы кластера находятся в частной сети за NAT, тогда просто добавьте шлюз по умолчанию вашей сети в белый список PG.

  • , если белый список может принимать cidr, кроме отдельных IP-адресов (например, 86.34.0.0/24), затем добавьте сетевой cidr вашего кластера в белый список

Если у каждого узла кластера есть публичный c IP, и вы не можете добавить cidr в белый список, тогда это становится более сложным:

  • Наивным способом было бы добавить IP-адрес любого узла в белый список, но он не масштабируется выше крошечных кластеров, всего несколько узлов.

  • , если у вас есть доступ к администрированию вашей сети тогда даже если узлы имеют публичные c IP-адреса, вы можете в любом случае настроить NAT для сети, которая нацеливается только на пакеты с IP-адресом PG в качестве пункта назначения.

  • , если у вас нет административный доступ к сети, т Другой способ - выделить где-нибудь машину со статическим IP-адресом c и заставить ее выступать в качестве прокси-сервера, используя iptables NAT, как описано выше. Это вводит единственную точку отказа все же. Для обеспечения высокой доступности вы можете снова развернуть его в кластере kubernetes с несколькими (2-3) репликами (это может быть тот же кластер, где работает X: см. Ниже). Реплики вместо того, чтобы использовать IP своего узла для связи с PG, делят VIP, используя keepalived , который будет добавлен в белый список PG. (вы можете взглянуть на easy-keepalived и либо попытаться использовать его напрямую, либо узнать, как он работает). Это требует высоких привилегий для кластера: вам нужно иметь возможность предоставлять модулям прокси NET_ADMIN и NET_RAW возможности, чтобы они могли добавлять правила iptables и настраивать VIP.

обновление:

В ожидании сборок и развертываний в течение последних нескольких дней я полировал свои старые сценарии VIP-iptables, которые я использовал для замены внешних балансировщики нагрузки на кластерах из чистого металла, так что теперь они могут также использоваться для обеспечения выходного VIP, как описано в последнем пункте моего первоначального ответа. Вы можете дать им попытку: https://github.com/morgwai/kevip

0 голосов
/ 13 февраля 2020

Есть два ответа на этот вопрос: для самого IP-адреса модуля он зависит от вашего плагина CNI. Некоторые позволяют это со специальными аннотациями под. Однако большинство плагинов CNI также включают в себя NAT при разговоре с inte rnet, поэтому IP-адрес модуля во внутренней сети является спорным, что вас беспокоит, так это IP-адрес c, соединение заканчивается от. Таким образом, второй ответ - «это зависит от того, как настроены сеть вашего узла и NAT». Обычно это зависит от инструмента, который вы использовали для развертывания Kubernetes (или, я полагаю, OpenShift в вашем случае). С Kops довольно легко настроить таблицу маршрутизации VP C.

...