Using Gloo TCP Proxy to forward port 27017 for MongoDB access in a Kubernetes cluster.
The following Gateway spec works for forwarding all port 27017 traffic to the specified upstream.
spec:
bindAddress: '::'
bindPort: 27017
tcpGateway:
tcpHosts:
- destination:
single:
upstream:
name: default-mongodb-27017
namespace: gloo-system
name: one
useProxyProto: falseI would like to forward 27017 traffic based on hostname (for example, d.db.example.com points to the dev instance of Mongo and p.db.example.com points to the prod instance).
Is there a way to specify hostname (like in a virtual service route)?
(Note: This is for a educational simulation, and as such isn't a real "production" environment. This is why both the dev and prod instance will exist in the same Kubernetes cluster. This is also why a managed or external MongoDB solution isn't used)
As I mentioned in comments, as far as I know it´s not posibble to do in gateway,atleast I could not find anything about that in gateway documentation, but you can configure virtual services to make it work.
As mentioned in documentation 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).
And 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.
Take a look at this tutorial.
And more specifically at this example where they use 2 domains, echo.example.com and foxtrot.example.com, in your case that would be d.db.example.com and 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'
...
I hope this helps.