Странный способ доступа к Cloud Run на сервисах GKE - PullRequest
Новая
       65

Странный способ доступа к Cloud Run на сервисах GKE

1 голос
/ 18 июня 2019

Я следую этому учебнику, чтобы выполнить так называемый быстрый старт gcp cloud run и немного поэкспериментировать с ним.

За исключением некоторых задержек и несоответствий в отношении объявленной и типичной доступности услуг, шаги по сценарию прошли хорошо.

Я хочу спросить (не смог найти никакой документации или объяснения по этому поводу): почему , чтобы получить доступ к услуге, мне нужно перейти к curl конкретному Host заголовок, как указано в соответствующем руководстве: 

curl -v -H "Host: hello.default.example.com" YOUR-IP

Где YOUR-IP - общедоступный IP-адрес балансировщика нагрузки, созданного управляющим входом istio-управляемым gatewau

Ответы [ 3 ]

2 голосов
/ 18 июня 2019

Большинство прокси , которые обрабатывают запросы на сопоставление внешнего трафика на основе заголовка Host.Они используют то, что находится внутри заголовка Host, чтобы решить, в какую службу отправить запрос.Без заголовка Host они не знали бы, куда отправить запрос.

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

Маршрутизация на основе хоста позволяет отправлять запрос на api.example.com и web.example.com на одну и ту же конечную точку с уверенностью, что он будет доставлен на правильныйфоновое приложение.

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

1 голос
/ 19 июня 2019

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

Как отмечают другие участники, при работе в облаке на основе GKE istio управляет маршрутизацией. Поэтому по умолчанию (и если нет способа переопределить это поведение), istio создаст

  • входной шлюз istio для обработки входящего трафика

  • виртуальный сервис с правилами маршрутизации для конкретного контейнера, который вы запускаете через gcloud cloud run deploy ...

Итак, я обнаружил этот ресурс 

➣ $ kubectl get virtualservice --all-namespaces
NAMESPACE         NAME                                         AGE
knative-serving   route-eaee65aa-91c8-11e9-be08-42010a8000e2   17h

, чье описание и соответствующие правила маршрутизации на основе хоста объясняют необходимость передачи определенного `Host 

➣ $ kubectl describe virtualservice route-eaee65aa-91c8-11e9-be08-42010a8000e2 --namespace knative-serving
Name:         route-eaee65aa-91c8-11e9-be08-42010a8000e2
Namespace:    knative-serving
Labels:       networking.internal.knative.dev/clusteringress=route-eaee65aa-91c8-11e9-be08-42010a8000e2
              serving.knative.dev/route=hello
              serving.knative.dev/routeNamespace=default
Annotations:  networking.knative.dev/ingress.class=istio.ingress.networking.knative.dev
API Version:  networking.istio.io/v1alpha3
Kind:         VirtualService
Metadata:
  Creation Timestamp:  2019-06-18T12:59:42Z
  Generation:          1
  Owner References:
    API Version:           networking.internal.knative.dev/v1alpha1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  ClusterIngress
    Name:                  route-eaee65aa-91c8-11e9-be08-42010a8000e2
    UID:                   f0a40244-91c8-11e9-be08-42010a8000e2
  Resource Version:        5416
  Self Link:               /apis/networking.istio.io/v1alpha3/namespaces/knative-serving/virtualservices/route-eaee65aa-91c8-11e9-be08-42010a8000e2
  UID:                     f0a51032-91c8-11e9-be08-42010a8000e2
Spec:
  Gateways:
    knative-ingress-gateway
    mesh
  Hosts:
    hello.default.example.com
    hello.default.svc.cluster.local
  Http:
    Append Headers:
      Knative - Serving - Namespace:  default
      Knative - Serving - Revision:   hello-8zgvn
    Match:
      Authority:
        Regex:  ^hello\.default(?::\d{1,5})?$
      Authority:
        Regex:  ^hello\.default\.example\.com(?::\d{1,5})?$
      Authority:
        Regex:  ^hello\.default\.svc(?::\d{1,5})?$
      Authority:
        Regex:  ^hello\.default\.svc\.cluster\.local(?::\d{1,5})?$
    Retries:
      Attempts:         3
      Per Try Timeout:  10m0s
    Route:
      Destination:
        Host:  activator-service.knative-serving.svc.cluster.local
        Port:
          Number:       80
      Weight:           100
    Timeout:            10m0s
    Websocket Upgrade:  true
Events:                 <none>

Более того, если вы добавите настраиваемое сопоставление доменов , получается, что GCP позаботится о маршрутизации, создав на этот раз дополнительную виртуальную службу в пространстве имен default 

➣ $  kubectl get virtualservice --all-namespaces
NAMESPACE         NAME                                         AGE
default           cloudrun.mydomain.com                        13m
knative-serving   route-23ad36f5-9326-11e9-b945-42010a800057   31m
0 голосов
/ 18 июня 2019

Как упоминалось в ответе Жозе Арместо, это просто потому, что Cloud Run на GKE использует Knative, который использует Istio. Входящий шлюз Istio получает весь трафик ко всем вашим сервисам Cloud Run и передает их в нужное место на основе зарегистрированных имен хостов сервиса.

Если вы сопоставляете пользовательские домены с помощью Cloud Run и фактически настраиваете записи DNS своего домена, чтобы они указывали на входной шлюз вашего Cloud Run on GKE, вам это не понадобится, так как вы на самом деле будет иметь доменное имя, которое используется в Host заголовок и распознается шлюзом. Таким образом, трафик будет течь в нужном месте.

...