маршрутизация трафика с внешнего балансировщика нагрузки на внутренний балансировщик нагрузки на gcp
Предположим, мы работаем в соответствии со следующими требованиями:
- Мы хотели бы запустить наш код на gcp и хотим сделать это на kubernetes, а не на любом из управляемых решений (движок приложения, запуск в облаке...).
- Наши услуги должны быть доступны в Интернете
- Мы хотели бы сохранить клиентские ips (сервис должен уметь их читать)
- Мы также хотели бы развернуть разные версии наших сервисов и разделить трафик между ними на основе весов.
Все вышеперечисленное, за исключением разделения трафика, может быть достигнуто с помощью традиционного входящего ресурса, который на gcp реализуется с помощью глобального внешнего балансировщика нагрузки HTTP(S) (классический). По этой причине я был вне себя от радости, когда заметил, что gcp реализует новый шлюз kubernetes и ресурсы маршрутизации. Как объясняется здесь, они в сочетании способны делать все то же, что и входной ресурс, и, в частности, взвешенное распределение трафика.
Однако, к сожалению, как только я начал реализовывать это на тестовом кластере, я обнаружил, что ресурс шлюза реализуется четырьмя разными классами, каждый из которых поддерживается одними и теми же двумя балансировщиками нагрузки, уже поддерживающими существующий входной ресурс. И только два внутренних класса шлюза, поддерживаемые внутренним балансировщиком нагрузки HTTP(S) gcp, поддерживают разделение трафика. См. следующие два изображения:
и
Таким образом, если мы хотим предоставить доступ к нашим услугам в Интернете, мы не можем разделить трафик, а если мы хотим разделить трафик, мы можем сделать это только внутри компании. Я не был встревожен этим, это действительно имеет смысл. Я имею в виду, что в идеале gke-l7-gxlb (поддерживаемый глобальным внешним балансировщиком нагрузки https (классический)) будет поддерживать разделение трафика, но я уже сталкивался с такой архитектурой в организациях. У вас есть внешний балансировщик нагрузки, который выполняет терминацию ssl, а затем отправляет трафик на внутренние балансировщики нагрузки, которые разделяют трафик на основе различных правил. На различных обучающих страницах gcp есть даже изображения таких диаграмм с использованием нескольких балансировщиков нагрузки. Однако, чтобы, наконец, вернуться к заголовку, я не могу убедить внешний балансировщик нагрузки gcp направить трафик на внутренний.. Кажется, что он очень ограничен в своих определениях бэкэнда. И просто выбор IP-адреса (предоставленного нам при создании ресурса шлюза, то есть внутреннего балансировщика нагрузки) не представляется возможным.
Это возможно? Я здесь совсем не в теме? должен ли я решать это совершенно по-другому? Есть ли более простой способ установить 4 вышеуказанных флажка? Я чувствую, что внешний балансировщик нагрузки, отправляющий трафик на IP-адрес в моей сети vpc, должен быть одной из его основных функций, но, может быть, есть причина, по которой он не позволяет мне это сделать?