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

我将按照教程在

gcp

的

cloudrun

上执行所谓的快速启动，并对其进行一些实验

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

我想问的（找不到任何文档或解释）是为什么，以便我访问需要传递给

curl

特定

主机

标题的服务，如相关教程所示：

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

其中，

YOUR-IP

是由istio管理的入口网关WAU创建的负载平衡器的公共IP

，它根据

主机

头处理外部流量匹配请求。他们使用

主机

头中的内容来决定向哪个服务发送请求。如果没有

Host

头，他们将不知道将请求发送到哪里

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

基于主机的路由允许您向api.example.com发送请求 而对于web.example.com来说，同一个端点是确定的吗 将被传递到正确的后端应用程序

---

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

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

如果您使用Cloud Run并实际设置域的DNS记录，以指向GKE设置上云运行的入口网关，您将不需要它，因为您将实际拥有在GKE设置中使用的域名

---

主机

标头，并由网关识别。因此，交通将流向正确的地方。

给出的所有答案或多或少都是正确的，但我想对挖掘后出现的情况进行更具体的描述

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

---

因此（考虑到它似乎是istio网关服务流量），您的意思是，

istio

如上所述添加了一个路由规则，这样，只有当

主机

是

hello.default.example.com

时，对我的服务的请求才会得到服务？（如果是这种情况，我假设这一定是通过

VirtualService

？）发生的）我认为这里的解释更好，下面的两个答案都是正确的。增列一项。不包含主机头违反了HTTP/1.1和HTTP/2规范：我没有看到Cloud Run实际返回400（错误请求）错误，但如果缺少主机头，则应该返回400（错误请求）。该规范说：“所有HTTP/1.1请求消息中都必须发送主机头字段。如果HTTP/1.1请求消息缺少主机头字段或包含多个主机头字段，则会向其发送400（错误请求）状态代码。”

➣ $  kubectl get virtualservice --all-namespaces
NAMESPACE         NAME                                         AGE
default           cloudrun.mydomain.com                        13m
knative-serving   route-23ad36f5-9326-11e9-b945-42010a800057   31m