访问 Cloud Run on GKE 服务的奇怪方式答案

【问题标题】：Weird way of accessing Cloud Run on GKE services访问 Cloud Run on GKE 服务的奇怪方式
【发布时间】：2019-11-01 03:44:01
【问题描述】：

我正在关注this 教程，在gcp 的cloud run 上执行所谓的快速入门并进行一些实验。

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

我想问（找不到任何文档或解释）是为什么，为了让我访问服务，我需要传递给curl 一个特定的@987654326 @header 如相关教程所示：

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

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

【问题讨论】：

以下两个答案都是正确的。一项额外的项目。不包含 Host 标头违反了 HTTP/1.1 和 HTTP/2 规范：developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host 我没有看到 Cloud Run 实际上返回 400（错误请求）错误，但如果缺少 Host 标头，它应该会返回。规范说：“必须在所有 HTTP/1.1 请求消息中发送 Host 标头字段。400（错误请求）状态代码将发送到任何缺少 Host 标头字段或包含多个标头字段的 HTTP/1.1 请求消息。 "

标签： kubernetes google-cloud-platform istio google-cloud-run knative

【解决方案1】：

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

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

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

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

【讨论】：

所以（鉴于它似乎是 istio 网关服务流量）您暗示istio 添加了如上所述的路由规则，因此只有在Host是hello.default.example.com 吗？（如果是这种情况，我认为这必须通过VirtualService 进行？）
我认为这里解释得更好istio.io/docs/reference/config/networking/v1alpha3/gateway

【解决方案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

谁的描述和对应的基于主机的路由规则，说明需要通过具体的`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>

更重要的是，如果您添加 custom domain mapping，GCP 会通过在 default 命名空间中创建附加虚拟服务来处理路由

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

【讨论】：

【解决方案3】：

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

如果您 Map custom domains 使用 Cloud Run 并实际设置域的 DNS 记录以指向您在 GKE 上设置的 Cloud Run 的入口网关，您将不需要它，因为您实际上将拥有一个域名用在 Host 标头，并被网关识别。这样流量就会流向正确的地方。

【讨论】：