Skip to content
This repository has been archived by the owner on Feb 27, 2023. It is now read-only.

Solicit feedback on supporting upstreams with non-routable Pod/VM IPs #39

Open
rosskukulinski opened this issue Apr 18, 2018 · 5 comments
Open

Solicit feedback on supporting upstreams with non-routable Pod/VM IPs #39

rosskukulinski opened this issue Apr 18, 2018 · 5 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. kind/question Categorizes an issue as a user question. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@rosskukulinski
Copy link
Contributor

At launch, Gimbal requires that discovered Application VMs (OpenStack) and Pods (Kubernetes) must have routable IPs that can be reached from the Gimbal cluster. While this is sufficient for our initial user and other users with flat IP namespaces, this will likely prohibit other common scenarios.

We should extend Gimbal to support Kubernetes and OpenStack deployments that do not provide routable IPs. This could include clusters that use an overlay network (e.g. Weave or Flannel) or that simply do not provide routable IPs.

One proposed solution would be to configure a GRE tunnel per upstream cluster.

This goal of this issue is to solicit feedback from the community about their deployments and use-cases so that we can design a viable solution.
@rosskukulinski rosskukulinski added kind/feature Categorizes issue or PR as related to a new feature. kind/question Categorizes an issue as a user question. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Apr 18, 2018
@ncdc
Copy link

ncdc commented Apr 23, 2018

One possible option - set up 1+ contour instances in each upstream using hostNetwork: true, then forward from the routing cluster to the upstream cluster using the IP of the node in the upstream cluster where contour/envoy is running.

@alexbrand
Copy link
Contributor

Thanks @ncdc - this is one approach I was thinking about. I think of it as "tiered ingress", where gimbal ingress proxies send traffic to backend cluster ingress proxies. The only detail here is that the discovery components would have to sync endpoints with the node IPs instead of the pod IPs.

@ncdc
Copy link

ncdc commented Apr 23, 2018

The only detail here is that the discovery components would have to sync endpoints with the node IPs instead of the pod IPs.

Exactly. I'd be happy to donate my demo code that does this :-)

@stevesloka
Copy link
Member

I wrote up a design doc here to further discuss the idea of "edge" proxies: https://docs.google.com/document/d/1kCPeX3QDeK2s7PX91prkFSPufIb17EQQCZrBE2BUM2w/edit?usp=sharing

@jcrowthe
Copy link

Hey, I am also very interested in this work for an alternative to routable pod IP's. Do we have an update?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
kind/feature Categorizes issue or PR as related to a new feature. kind/question Categorizes an issue as a user question. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ncdc @alexbrand @stevesloka @rosskukulinski @jcrowthe