在GKE服务上运行云的奇怪方式

Question

我正在按照本教程对gcp的cloud run执行所谓的快速入门，并对其进行一些实验。

除了宣布和典型服务可用性的一些延迟和不一致之外，脚本化步骤进展顺利。

我想问的是(找不到任何关于它的文档或解释(是为什么，为了让我访问服务，我需要传递给curl相关教程所示的特定Host标头：

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

其中YOUR-IP是由 istio 管理的入口 gatewau 创建的负载均衡器的公共 IP

Answer 1

大多数处理外部流量的代理都根据Host标头匹配请求。它们使用 Host 标头中的内容来决定将请求发送到哪个服务。如果没有 Host 标头，他们将不知道将请求发送到何处。

基于主机的路由是在 Web 服务器上启用虚拟服务器的原因。 它还被应用程序服务使用，如负载平衡和入口 控制器来实现同样的事情。一个 IP 地址，多个主机。

基于主机的路由允许您发送 api.example.com 请求 并且对于确定的同一端点 web.example.com 将交付到正确的后端应用程序。

这在多租户代理/负载均衡器中很常见，这意味着它们处理位于代理后面的完全不同的租户/应用程序的流量。

Answer 2

所有给出的答案或多或少都是正确的，但我想对我经过一些挖掘后遇到的情况进行更具体的描述。

正如其他研究员所指出的，在基于 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

其描述和相应的基于主机的路由规则解释了传递特定"主机"的必要性

➣ $ 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

Answer 3

正如Jose Armesto的回答所提到的，这仅仅是因为GKE上的Cloud Run使用了Knative，而Knative使用了Istio。Istio 入口网关接收所有 Cloud Run 服务的所有流量，并根据服务的注册主机名将它们代理到正确的位置。

如果您使用 Cloud Run 映射自定义域，并实际将域的 DNS 记录设置为指向 GKE 上的 Cloud Run 设置的入口网关，则不需要它，因为您实际上将拥有一个在 Host标头，并由网关识别。因此，流量将流向正确的位置。