您可能遇到了虚拟主机问题。firebase-project-123456.firebaseio.com是一个虚拟主机名，然后用于将您的请求路由到正确的后端。Kubernetes外部服务本质上是一个DNS CNAME，它强制对实际主机名进行第二次DNS查找。
看看这对你是否有效：

curl -v -H "Host: firebase-project-123456.firebaseio.com" http://firebase/activity.json

字符串
如果是的话，那就是你遇到的问题了，你可能不得不做一个简单的服务来代替，它将你的请求代理到firebase上正确的URL。

我遇到了同样的问题，@MarcinRomaszewicz的答案和问题陈述都是正确的。但是his answer并没有包含这样一个解决方案的实现细节。我做了一些研究，发现了它。这比旋转nginx的想法更相关：让我们使用K8S Ingresses。

kind: Service
apiVersion: v1
metadata:
  name: backend-svc
  namespace: my-namespace
  annotations:
    ingress.kubernetes.io/preserve-host: "false"
spec:
  type: ExternalName
  externalName: backend.address.com
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-ing
  namespace: my-namespace
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/upstream-vhost: backend.address.com
spec:
  rules:
    - host: myweb.address.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-svc
                port:
                  number: 443
---

字符串
在这个例子中，我创建了一个ExternalService类型的服务，只是为了重定向到其他服务（实际上，在我的例子中，它也是k8S中的Ingress，但是在不同的命名空间甚至集群中），并创建了一个Ingress来接收来自myweb.address.com/api的请求，并将它们转发到我们的外部服务。

此处的主要信息是入口注解！请使用upstream-vhost解决此问题！

P.S.另一个建议是使用端口443和backend-protocol注解通过HTTPS而不是HTTP工作。