Комментарии 5
А можно просто Service и Metallb (если не облачный кубер). А если облачный, то скорее всего просто Service.
Service Вам обеспечит доступ внутри кластера, вместе с Metallb Вы сможете конечно выдать IP из какого-нибудь локального пула адресов, но мы решали задачку, когда доступ нужно получить из глобальной сети Интернет к нескольким СУБД по одному и тому-же белому IP адресу.
Service Вам обеспечит доступ внутри кластера
Вам бы матчасть подтянуть...
вместе с Metallb Вы сможете конечно выдать IP из какого-нибудь локального пула адресов
А можно не из локального, BGP'шного. Так, кстати, внешний адрес трушно балансируется по нодам.
мы решали задачку, когда доступ нужно получить из глобальной сети Интернет к нескольким СУБД по одному и тому-же белому IP адресу.
Если прям нужно один адрес, то можно использовать аннотацию:
metallb.universe.tf/allow-shared-ip: "true"С другой стороны, вы же как-то уже на прокси разные балансите трафик. Тут либо nodeport, либо Klipper, либо что-то вроде metallb. Ну либо calico в одной сети с NAT-маршрутизатором.
Просто для такой простой задачи разные прокси просто избыточны и часто добавляют только задержку. Если уж брать, то лучше haproxy хотя бы.
Вы кажется, не до конца разобрались в том, какую задачу мы решали. Нам нужно обеспечить одновременно доступ к нескольким СУБД из внешней сети, имея только один белый IP. Обычный nginx ингресс выбирает куда проксировать трафик на основе хоста в HTTP заголовке, к которому идет обращение. В том варианте, который Вы предлагаете, за счет чего будет производиться выбор, куда проксировать трафик? На основе порта? Не все будут рады, что у них postgres висит на 9090 порту например.
Вы не просто один адрес хотите использовать, но и один порт тогда уж.
Даже с учётом что вы себе сами этим геморрой придумали на ровном месте, возьмите haproxy. Там где traefik захлебнется на 100 соединений в 4 vCPU, haproxy легко прожуёт это всё на одном ядре в десятикратном размере с меньшими задержками.
Traefik очень удобный, когда у вас дофигаллион разных источников для сервисов (не самих сервисов), например, кубер+docker swarm+какая-то кастомная БД+ещё какой-то HTTP-сервис. И вам нужно централизовано управлять не только подключениями, но и сертификатами, middleware и т.п.
В вашем примере с таким же успехом можно было Istio использовать. Но зачем?
Поэтому с учётом придуманной проблемы с портами (безопасники, будь у вас наоборот всё на разных нестандартных портах, обрадовались бы), хотя бы посмотрите в сторону более адекватных инструментов для маршрутизации типа haproxy.
Ну и не забудьте протюнить ядро по сетевому стеку, буферам и файловым дескрипторам, чтоб не удивиться потом. Но рано или поздно всё равно в сеть упрётесь.
Доступ к нескольким подам Kubernetes по протоколу TCP и единственному внешнему IP