kubernetes - Gloo TCP代理(按主机名)

Question

使用Gloo TCP代理转发端口27017以在Kubernetes集群中进行MongoDB访问。
以下网关规范适用于将所有端口27017流量转发到指定的上游。

spec:
  bindAddress: '::'
  bindPort: 27017
  tcpGateway:
    tcpHosts:
      - destination:
          single:
            upstream:
              name: default-mongodb-27017
              namespace: gloo-system
        name: one
  useProxyProto: false

我想根据主机名转发27017流量(例如， d.db.example.com指向Mongo的dev实例， p.db.example.com指向prod实例)。
有没有办法指定主机名(例如在虚拟服务路由中)？
(注意:这是用于教育模拟的，因此不是真正的“生产”环境。这就是为什么dev和prod实例都存在于同一Kubernetes集群中的原因。这也是为什么托管或外部MongoDB解决方案的原因。不使用)

Answer 1

正如我在评论中提到的那样，据我所知，在网关中这样做并不是不可能的，至少我在网关documentation中找不到关于此的任何内容，但是您可以配置virtual services使其起作用。
如文档there所述

The VirtualService is the root Routing object for the Gloo Gateway. A virtual service describes the set of routes to match for a set of domains.

It defines: - a set of domains - the root set of routes for those domains - an optional SSL configuration for server TLS Termination - VirtualHostOptions that will apply configuration to all routes that live on the VirtualService.

Domains must be unique across all virtual services within a gateway (i.e. no overlap between sets).

和 there

Virtual Services define a set of route rules, an optional SNI configuration for a given domain or set of domains.

Gloo will select the appropriate virtual service (set of routes) based on the domain specified in a request’s Host header (in HTTP 1.1) or :authority header (HTTP 2.0).

Virtual Services support wildcard domains (starting with *).

Gloo will create a default virtual service for the user if the user does not provide one. The default virtual service matches the * domain, which will serve routes for any request that does not include a Host/:authority header, or a request that requests a domain that does not match another virtual service.

The each domain specified for a virtualservice must be unique across the set of all virtual services provided to Gloo.

看一看 this教程。
更具体地说，在此示例中，它们使用2个域，echo.example.com和foxtrot.example.com，在您的情况下为 d.db.example.com和 p.db.example.com

Option 2: Separating ownership across domains

The first alternative we might consider is to model each service with different domains, so that the routes are managed on different objects. For example, if our primary domain was example.com, we could have a virtual service for each subdomain: echo.example.com and foxtrot.example.com.

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: echo
  namespace: echo
spec:
  virtualHost:
    domains:
      - 'echo.example.com'
    routes:
      - matchers:
          - prefix: /echo
---
apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: foxtrot
  namespace: foxtrot
spec:
  virtualHost:
    domains:
      - 'foxtrot.example.com'
...

我希望这有帮助。