Как создать правило брандмауэра GPC для разрешения трафика между Кластеры GKE

Предпосылки

У меня есть проект GCP с двумя кластерами GKE: public-cluster и частный кластер . public-cluster запускает шлюз API, который выполняет централизованную аутентификацию, ведение журнала, ограничение скорости и т. Д. И перенаправляет запросы к внутренним микросервисам, работающим на частном кластере . Шлюз API построен с использованием Ocelot .

public-cluster имеет выход в Интернет и использует ingress-nginx для предоставления общедоступного внешнего IP-адреса, который принимает трафик HTTP / s на портах 80/443 .

Назначение частного кластера состоит в том, что он может принимать только трафик порта 80/443 от общедоступного кластера . Мы не хотим, чтобы этот кластер был доступен откуда-либо еще, т. Е. Никаких прямых HTTP / s-запросов к частному кластеру ни изнутри VPC, ни извне, если только трафик не из общедоступного кластера . Я показал службы, работающие в частном кластере , с использованием внутреннего балансировщика нагрузки , поэтому каждая служба имеет свой собственный внутренний IP-адрес. Шлюз API использует эти внутренние IP-адреса для перенаправления входящих запросов к внутренним микросервисам.

public-cluster и private-cluster находятся в разных подсетях в одном регионе в одном VPC.

] Предполагаемую архитектуру можно увидеть здесь:

.

Проблема

Я пытаюсь создать правила брандмауэра, которые будут блокировать весь трафик в частный кластер , если только он не исходит от public-cluster следующим образом:

• Одно правило входа с низким приоритетом, которое запрещает весь трафик в частный кластер (с использованием сетевого тега в качестве цели) и 0,0 .0.0 / 0 в качестве диапазона IP-адресов источника
• Правило входа с более высоким приоритетом, где:
  • Target = private-cluster
  • Source filter = public-cluster
  • Разрешает TCP-трафик на портах 80 и 443

Если я использую SSH на узле в public- cluster и запросы fire curl к службе в частном кластере (с использованием IP-адреса внутреннего балансировщика нагрузки службы), приведенные выше правила брандмауэра правильно разрешают трафик. Однако, если я отправляю запросы с локального компьютера на public-cluster API-шлюз, правила брандмауэра блокируют трафик. Похоже, что в этом случае сетевой тег в правиле брандмауэра игнорируется.

Я пробовал несколько вещей, чтобы правила заработали (все безуспешно), например:

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

Вопросы

Итак, мои вопросы:

1. Как правильно определить это правило брандмауэра, чтобы запросы, перенаправленные из шлюза API, запущенного на публичном кластере , разрешались через брандмауэр на private-cluster ?
2. В более общем плане, является ли это типичным архитектурным шаблоном для кластеров Kubernetes (т. Е. Наличие общедоступного кластера, на котором запущен шлюз API, который перенаправляет запросы на внутренний кластер, не обращенный к общедоступному) и, если нет, есть ли лучший способ спроектировать это? (Я понимаю, что это очень субъективный вопрос, но мне интересно услышать об альтернативных подходах)