-
|
Can the Gateway API as currently specified express the concept of a reverse-tunnel endpoint as a gateway or route? I want to be able to have workloads on "spoke" kube clusters that aren't directly addressable/reachable make connections to "hubs" and expose services on the spoke to workloads running on the hub such that the hub workloads can discover and query those spoke services. I'd like to be able to have those spokes make inbound connections to the hub Gateway and expose Listeners that transit traffic back to the spoke over a reverse tunnel. I realise there's probably no actual implementation for this at present, but I'd be very interested in the API itself being able to express this concept for future implementations to use. For example, the spokes might be k8s clusters behind NAT, without public IPs, and/or with aggressive firewalls, so they can only make outbound connections. I'd like to be able to deploy some kind of ReverseTunnelProxy on each spoke that connects to some reverse tunnel listener associated with a Gateway on the hub. Preferably exposed as a separate CR, not a I don't see any way to express reverse tunnel connectivity via the Gateway API spec as written. An operator could presumably dynamically manage the gateway listeners to reflect reverse tunnels, but I don't see how a HTTPRoute could express a backendRef in terms of a reverse tunnel to service on a federated cluster. Am I missing something, or is the API currently written with the assumption that connections can only be made to endpoints that are directly reachable (via a peer gateway with a public IP address)? (For example, Teleport supports having a Teleport Agent behind NAT connect to a Teleport Proxy on a reachable endpoint and register itself to reverse-tunnel connections back from the proxy through the agent to workloads reachable from the agent. But multi-network federated mesh tools like Istio do not currently appear to have any similar reverse tunnel support, or any way to express that concept in their APIs. It'd be good to see the Gateways API able to express peering via reverse tunnels to help tools more easily present this useful functionality) Some related posts I've made elsewhere: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
The simplest answer to your question is: For now, no it cannot. However, a more interesting answer is that it could - I've kind of anticipated something like this for a while - we define a Gateway as a thing that add context that's missing on the "outside" - but there's no reason that we couldn't spin that around and have "outside" mean "in another cluster". This is very early speculation that we haven't really discussed though, and we already have a pretty full feature queue, so it may take a while to get to discussing it. Thanks for the links, let's come back to this after we finish launching GA? |
Beta Was this translation helpful? Give feedback.
-
|
Thankyou very much. I appreciate the response. Hopefully this helps others find answers. In the mean time I landed up exploring building something based on https://gost.run/en/ |
Beta Was this translation helpful? Give feedback.
The simplest answer to your question is: For now, no it cannot.
However, a more interesting answer is that it could - I've kind of anticipated something like this for a while - we define a Gateway as a thing that add context that's missing on the "outside" - but there's no reason that we couldn't spin that around and have "outside" mean "in another cluster". This is very early speculation that we haven't really discussed though, and we already have a pretty full feature queue, so it may take a while to get to discussing it.
Thanks for the links, let's come back to this after we finish launching GA?