kubernetes - 访问 Cloud Run on GKE 服务的奇怪方式

Question

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

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

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

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

YOUR-IPistio 管理的入口网关创建的负载均衡器的公共 IP 在哪里

Answer 1

Most proxies that handle external traffic match requests based on the Host header. They use what's inside the Host header to decide which service send the request to. Without the Host header, they wouldn't know where to send the request.

Host-based routing is what enables virtual servers on web servers. It’s also used by application services like load balancing and ingress controllers to achieve the same thing. One IP address, many hosts.

Host-based routing allows you to send a request for api.example.com and for web.example.com to the same endpoint with the certainty it will be delivered to the correct back-end application.

That's typical in proxies/load balancers that are multi-tenant, meaning they handle traffic for totally different tenants/applications sitting behind the proxy.

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

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

Answer 3

As mentioned by Jose Armesto’s answer, it’s simply because Cloud Run on GKE uses Knative, which uses Istio. Istio ingress gateway receives all traffic to all your Cloud Run services, and proxies them to the right place based on registered hostnames of the service.

If you Map custom domains using Cloud Run and actually set up your domain‘s DNS records to point to the ingress gateway of your Cloud Run on GKE set up, you won't need it as you will actually have a domain name that’s used in the Host header, and recognized by the gateway. So the traffic will flow to the right place.