Настройка Cloud NAT для общедоступных кластеров GKE

Question

Я бы хотел настроить шлюз NAT, используя Cloud NAT , чтобы виртуальные машины / модули в общедоступном кластере GKE использовали статические IP-адреса.

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

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

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

Согласно документу:

Если вы настроите внешний IP на интерфейсе виртуальной машины, [...] NAT не будет выполняться с такими пакетами. Однако диапазоны IP-адресов псевдонимов, назначенные интерфейсу, могут по-прежнему использовать NAT, поскольку они не могут использовать внешний IP-адрес для доступа в Интернет.

И

С этой конфигурацией вы можете напрямую подключаться к виртуальной машине GKE через SSH, и при этом модули / контейнеры GKE используют Cloud NAT для доступа в Интернет.

Это то, что я хочу, но я не вижу, что именно настроить здесь.

Что подразумевается под alias IP ranges assigned to the interface can still use NAT и как это настроить?

Answer 1

"К сожалению, в настоящее время это не так. В то время как Cloud NAT все еще находится в бета-версии, некоторые настройки не полностью установлены, и поэтому модули по-прежнему используют SNAT даже с псевдонимами IP. Из-за SNAT дляIP-адрес узла, модули не будут использовать Cloud NAT. "

Действительно, как говорит Патрик В. выше, в настоящее время он работает не так, как задокументировано.Я тоже попробовал и поговорил с ребятами из группы GCP Slack на канале Kubernetes Engine.В ходе тестирования они также подтвердили, что он работает только с частным кластером GKE.Мы еще не начали играть с частными кластерами.Я не могу найти надежную документацию по этому простому вопросу: если я создаю частный кластер, могу ли я по-прежнему иметь общедоступные службы K8S (так называемые балансировщики нагрузки) в этом кластере?Все документы о частных кластерах GKE указывают на то, что вам не нужен входящий внешний трафик, но на наших кластерах GKE мы запускаем производственные сервисы с выходом в Интернет.

Я подал заявку с поддержкой GCP оПроблема Cloud NAT, и вот что они сказали:

«Я проверял вашу конфигурацию, и причина, по которой Cloud NAT не работает, заключается в том, что ваш кластер не является частным. Чтобы использовать Cloud NAT с GKE, вынеобходимо создать частный кластер. В не приватном кластере публичные IP-адреса кластера используются для связи между мастером и узлами. Поэтому GKE не учитывает конфигурацию Cloud NAT, которая у вас есть. Создание частного кластерапозволит вам объединить Cloud NAT и GKE.

Я понимаю, что это не очень ясно из нашей документации, и я сообщил об этом, чтобы прояснить и объяснить, как именно это должно работать. "

Я ответил, попросив их, пожалуйста, заставить его работатьдокументированы, а не изменяют свою документацию.Жду обновления от них ...

Answer 2

Идея в том, что если вы используете собственный кластер VPC (псевдоним Ip) для кластера, ваши модули не будут использовать SNAT при маршрутизации из кластера .Без SNAT модули не будут использовать внешний IP-адрес узла и, следовательно, должны использовать Cloud NAT.

К сожалению, в настоящее время это не так.В то время как Cloud NAT все еще находится в бета-версии, некоторые настройки не полностью установлены, и поэтому модули по-прежнему используют SNAT даже с использованием псевдонимов IP.Из-за SNAT к IP-адресу узла модули не будут использовать Cloud NAT.

При этом почему бы не использовать частный кластер?Это более безопасно и будет работать с Cloud NAT.Вы не можете напрямую подключиться к узлу SSH, но А) вы можете создать в своем проекте бастионный экземпляр виртуальной машины, который может SSH, используя внутренний IP-флаг и B) вам обычно не нужно подключать SSH к узлу.в большинстве случаев.