Выставлять сервисы внутри кластера Kubernetes за NAT

Question

У меня есть кластер GKE, настроенный с Cloud NAT , поэтому трафик c из любого узла / контейнера, идущего наружу, будет иметь тот же внешний IP. (Мне это понадобилось в целях внесения в белый список при работе со сторонними сервисами).

Теперь, если я хочу развернуть прокси-сервер в этом кластере, который выполняет пересылку basi c traffi c, как мне это сделать? выставить прокси-сервер "конечная точка"? Или, в более общем смысле, как предоставить сервис, если я разверну его в этом кластере GKE?

Answer 1

Как правило, для предоставления конечной точки службы, работающей в кластере Kubernetes, необходимо использовать один из типов обслуживания , поскольку блоки имеют внутренние IP-адреса и не имеют внешней адресации.

Возможные типы услуг:

• ClusterIP: здесь также используется внутренний IP-адрес, и, следовательно, внешняя адресация невозможна.

• NodePort: этот тип открывает порт на каждом узле в вашем кластере Kubernetes и настраивает iptables для пересылки трафика c, поступающего на этот порт, в блоки, обеспечивающие фактическое обслуживание.

• LoadBalancer: этот тип открывает порт на каждом узле, как и в случае с NodePort, а также выделяет сервис Google Cloud Load Balancer и настраивает этот сервис для доступа к порту, открытому на узлах Kubernetes (фактически для балансировки нагрузки входящего трафика). c между операциями узлов Kubernetes).

• ExternalName: этот тип настраивает внутренний DNS-сервер Kubernetes для указания на th Указанный IP-адрес (для предоставления динамической c записи DNS внутри кластера для подключения к внешним службам).

Из них NodePort и LoadBalancer могут использоваться для ваши цели. В случае простой службы типа NodePort вам потребуются общедоступные IP-адреса узлов, а выделенный порт можно использовать для доступа к прокси-службе через любой узел вашего кластера. Так как любой из ваших узлов может исчезнуть в любое время, этот вид доступа к сервису хорош, только если ваши прокси-клиенты знают, как переключиться на IP-адрес другого узла. Или вы можете использовать сервис типа LoadBalancer, в этом случае вы можете использовать IP-адрес настроенного Google Cloud Load Balancer, к которому ваши клиенты будут подключаться, и ожидать, что балансировщик нагрузки перенаправит трафик c на любой из работающие узлы вашего кластера, которые затем перенаправляют трафик c одному из модулей, предоставляющих эту услугу.

Чтобы ваш прокси-сервер имел доступ к Inte rnet в качестве клиента, вам также потребуются некоторые вид публикации c IP-адрес. Либо вы предоставляете узлам Kubernetes опубликованные c IP-адреса (в этом случае, если у вас более одного узла, вы увидите несколько исходных IP-адресов, поскольку каждый узел имеет свой собственный IP-адрес), или если вы используете частный адреса для ваших узлов Kubernetes, вам нужна функциональность Source NAT, например, та, которую вы уже используете: Cloud NAT

Answer 2

Прокси-сервер, работающий за NAT?

Плохая идея, разве только для вашей кластера kubernetes рабочая нагрузка, но вы нигде не указали, что он должен быть доступным только другим Pods, работающим в том же кластере.

Как вы можете прочитать здесь :

Cloud NAT не реализует нежелательные входящие соединения из целое rnet. DNAT выполняется только для пакетов, которые поступают в качестве ответов на исходящие пакеты.

Таким образом, он не предназначен для того, чтобы быть доступным извне.

Если вы хотите представить какое-либо приложение в вашем кластере , делая его доступным для других Pods, используйте простой ClusterIP Сервис , который является типом по умолчанию, и он будет создан как таковой, даже если вы вообще не указываете его тип.