Могу ли я использовать балансировщик нагрузки GCP HTTPS для маршрутизации между бэкэндом корзины и службой Kubernetes?

Question

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

Дополнительная информация:

• У меня есть доменное имя, зарегистрированное за пределами доменов Google
• Я хочу обслуживать весь контент через https
• Я не начинаю с чего-то большого.Просто начните с более или менее хобби-проекта, который в ближайшем будущем привлечет очень мало трафика.
• Я не против обслуживать мой реагирующий интерфейс, экспресс-бэкэнд из движка приложения, если это как-то упрощает эту задачу.Тем не менее, в таком случае я хотел бы понять, если я все еще хочу что-то на kubernetes, смогу ли я общаться между механизмом приложения и kubernetes без суеты, используя внутренние IP-адреса.И как бы я сбалансировал этот трафик !!

Любой сетевой проект в открытом доступе, который поможет мне, будет полезен.

Я довольно много читал о NodePort / LoadBalancer / Ingress, что привело меня в замешательство.насколько я понимаю, LoadBalancer не работает с трафиком HTTP (S), работает больше на уровне TCP L4, поэтому, вероятно, не подходит для моего случая использования.

Ingress предоставляет собственный собственный балансировщик нагрузки, на котором яя не могу поместить свои собственные маршруты в бэкэнд-бак и т. д., что означает, что мне может понадобиться минимум два балансировщика нагрузки?а два IP?

NodePort предоставляет порт на всех узлах, что означает, что мне нужно самому управлять балансировкой нагрузки, даже если моя маршрутизация балансировки нагрузки HTTPS может как-то помочь.

Будем очень благодарны за любые указания / указатели!

РЕДАКТИРОВАТЬ: Во время исследования нашел некоторую информацию о группах конечных точек сети (NEG).Выглядит многообещающе.будем расследовать.Есть мысли по поводу этого маршрута?https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg

Answer 1

Чтобы решить ваши проблемы, пожалуйста, начните с:

1. Выбор правильного балансировочного устройства :

   • Сетевая нагрузкабалансировщик (балансировка нагрузки уровня 4 или прокси-сервер для приложений, использующих протокол TCP / SSL), нагрузка пересылается в ваши системы на основе входящих данных протокола IP, таких как адрес, порт и тип протокола.

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

   • HTTP (s) loadbalancer - региональный уровень 7 на основе проксибалансировщик нагрузки, который позволяет вам запускать и масштабировать свои службы за частным IP-адресом балансировки нагрузки, который доступен только в регионе балансировщика нагрузки в вашей сети VPC.

     Балансировщики нагрузки HTTPS и SSL Proxy завершают TLS в расположениях, которые распределены по всему миру .Балансировщик нагрузки HTTP (S) действует как прокси между вашими клиентами и вашим приложением.Если вы хотите принимать HTTPS-запросы от своих клиентов, у вас есть возможность использовать управляемые Google SSL-сертификаты (бета-версия) или использовать сертификаты, которыми вы управляете сами.

     Технические подробности При создании объекта Ingress GKEIngress controller настраивает балансировщик нагрузки GCP HTTP (S) в соответствии с правилами в манифесте Ingress и связанных манифестах службы.Клиент отправляет запрос на балансировщик нагрузки HTTP (S). Балансировщик нагрузки является фактическим прокси ;он выбирает узел и направляет запрос в комбинацию NodeIP: NodePort этого узла.Узел использует свою таблицу NAT iptables, чтобы выбрать Pod.kube-proxy управляет правилами iptables на узле. Трафик маршрутов направляется в работоспособный Pod для Сервиса, указанного в ваших правилах .

2. В корзины документация:

   Балансировщик нагрузки HTTP (S) может направлять трафик с указанных URL-адресов либо в бэкэнд-бакет, либо в бэкэнд-сервис.Bucket должен быть общедоступным при использовании Loadbalncer - Создание корзины Bucket

3. Во время настройки LoaBalancer вы можете выбрать бэкэнд-сервис и бэкэнд-бакет.Вы можете найти больше информации в документах .

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

Надеюсь, что эта помощь.

Дополнительные ресурсы: Балансировщики нагрузки, Контроллеры