Используйте тот же GCP Load Balancer для маршрутизации между GCS Bucket и GKE - PullRequest
Новая
       31

Используйте тот же GCP Load Balancer для маршрутизации между GCS Bucket и GKE

3 голосов
/ 28 февраля 2020

Я искал, пытаясь выяснить, возможно ли иметь статус c Приложение React, размещенное в корзине Google Cloud Storage, и использование CDN Google Cloud и одного Google Cloud Load Balancer для маршрутизации ошибок кэширования. в хранилище, управлять сертификатами и направлять внутренний запрос из приложения React в API, размещенный в GKE?

Можно ли достичь этой архитектуры или будет другой рекомендуемый подход?

Ответы [ 2 ]

1 голос
/ 01 марта 2020

Вы можете использовать балансировщик нагрузки с (двумя или более) сопоставителями маршрутов, один для api.example.com с бэкендом для GKE, а другой для stati c .example.com с бэкэнд-бакетом.

В этом внутреннем сегменте включен CDN. При необходимости вы можете указать несколько маршрутов к одному и тому же бэкэнду.

В частности:

  1. создать сервис Kubernetes, который представлен автономной группой конечных точек сети. Это позволит вам управлять балансировщиком нагрузки вне GKE. Документы: https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg

  2. Создайте балансировщик нагрузки HTTP (S) с маршрутами, которые вы хотите сопоставить с конечной точкой API. Создайте BackendService в процессе создания балансировщика нагрузки и укажите его на существующую группу конечных точек зональной сети, созданную на шаге 1. документы: https://cloud.google.com/load-balancing/docs/https/https-load-balancer-example

  3. Создайте BackendBucket в том же потоке, направив его на контейнер, который вы хотите использовать для хранения ваших данных c React assets. Обязательно установите флажок «Включить Cloud CDN» и создайте маршрут, по которому трафик c отправляется в этот сегмент. Документы: https://cloud.google.com/cdn/docs/using-cdn#enable_existing

  4. Fini sh создание LB, который будет назначать IP-адреса и обновлять DNS для ваших доменных имен, чтобы они указывали на эти IP-адреса.

1 голос
/ 28 февраля 2020

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

Кроме того, CDN начинает кэшировать содержимое только после первого пропуска кеша . Это означает, что он должен получить ресурс в первый раз только после того, как клиент запросит указанный ресурс.

Если ресурс еще не кэширован в CDN, он будет направлен на сервер (через балансировщик нагрузки) для его извлечения и создания «локальной копии». Конечно, для этого требуется, чтобы ресурс также существовал в бэкэнде для того, чтобы CDN его кэшировал.

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

Поскольку корзины имеют многорегиональных классов , вы можете достичь чего-то действительно похожего к тому, что вы пытаетесь с CDN.

Обновление:

С учетом новой предпосылки: Использование того же балансировщика нагрузки для маршрутизации запросов между станциями * Сайт 1055 *, размещенный в корзине GCS, и API, развернутый в GKE, с CDN перед ним и с поддержкой сертификатов .

Хотя балансировщик нагрузки HTTP (S) может управлять сертификатами, совместим с облачным CDN, может иметь сегменты или экземпляры GCE в качестве бэкэндов и является опцией по умолчанию [Ingress] в GKE (так что он также совместим с ним), этот подход делает Это не представляется возможным.

Когда вы предоставляете приложение в GKE, используя входной класс по умолчанию (GCE) , который развертывает этот вид балансировщика нагрузки, диспетчер облачных контроллеров GKE отвечает за этот ресурс и использует определения, развернутые в GKE.

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

В противном случае вы вручную создаете балансировщик нагрузки и настраиваете его бэкэнд для обслуживания содержимого вашего сегмента: нет поддержка присоединения этого балансировщика нагрузки к кластеру GKE, он должен быть создан в Kubernetes.

Итак, в двух словах: Либо вы используете балансировщик нагрузки с корзиной или с кластером GKE, но не оба из-за вышеупомянутого дизайна .

Это, конечно, вполне возможно, если вы развернете 2 разных Установите балансировщик нагрузки (ingress в терминах GKE) и поместите CDN перед балансировщиком нагрузки вместе с ковшом. Я упоминаю это, чтобы сравнить это с информацией выше.

Дайте мне знать, если это поможет:)

...