访问GKE服务上运行的云的奇怪方法

Question

我正在遵循这教程，在gcp的cloud run上执行一个所谓的快速启动，并对它进行一些实验。

除了公布的服务可用性和典型的服务可用性方面的一些延迟和不一致之外，编写的步骤进行得很顺利。

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

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

其中，YOUR-IP是istio管理的入口网关创建的负载均衡器的公共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的回答所提到的，这仅仅是因为在GKE上运行的Cloud使用了Istio，后者使用了Istio。Istio入口网关接收到所有云运行服务的所有流量，并根据注册的服务主机名将它们代理到正确的位置。

如果您使用Cloud运行并实际设置域的DNS记录以指向在GKE上运行的云运行的入口网关，您将不需要它，因为您实际上将有一个在Host头中使用的域名，并且由网关识别。所以交通会流向正确的地方。