Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes Ingress Controller #311

Closed
andrewwebber opened this issue Jan 2, 2017 · 6 comments
Closed

Kubernetes Ingress Controller #311

andrewwebber opened this issue Jan 2, 2017 · 6 comments
Labels
question Questions that are neither investigations, bugs, nor enhancements

Comments

@andrewwebber
Copy link

Are there any plans to look at a kubernetes ingress controller implementation?

@mattklein123 mattklein123 added the question Questions that are neither investigations, bugs, nor enhancements label Jan 2, 2017
@mattklein123
Copy link
Member

Please following along with the https://github.com/istio project. They are building k8s support for Envoy (and other service mesh proxies).

@emmanuel
Copy link

emmanuel commented Feb 5, 2017

Istio looks interesting, but I don't think that it's particularly relevant to the request. As far as I saw (from a quick look), istio is targeting service-to-service communications (i.e., east-west, service mesh). An ingress controller is about north-south communications.

Please consider this another expression of interest for an Envoy-based ingress controller. Preferably this would be simple and unencumbered by ambitions of targeting a multitude of use-cases.

@mattklein123
Copy link
Member

@emmanuel it's very unlikely that we will work on any direct k8s integration any time soon. From my perspective Istio is the vehicle that will get Envoy into k8s including an ingress controller. It's possible this will change in the future depending on project trajectories, but for now I think it's best to let the Istio project evolve and see where it goes.

cc @rshriram @louiscryan in case you want to add any other color here. I'm going to leave this issue open just to track this general question since it keeps coming up.

@emmanuel
Copy link

emmanuel commented Feb 6, 2017

@mattklein123 thanks for the response. I fired off that comment without doing my homework on istio and I hope that it didn't come across as uninformed, entitled and/or ubnoxious. That is how my comment looks to me upon re-reading, so I'm asking for a more generous interpretation than I myself would likely give. Hmmm.

Anyhow, istio is clearly targeting both east-west and north-south use-cases. It was right there to see if I had but read a bit further. I'll track istio and look forward to it's evolution.

@emmanuel
Copy link

emmanuel commented Feb 6, 2017

Curses, I forgot the most important part. Sorry for my tone in the first message.

@rshriram
Copy link
Member

rshriram commented Feb 6, 2017

@emmanuel we are writing an ingress controller for Envoy in Istio, with much more functionality than the limitations of existing ingress controller (i.e. expose lots of Envoy features). It's a work in progress. Please see istio/old_pilot_repo#71

rshriram pushed a commit to rshriram/envoy that referenced this issue Oct 30, 2018
rshriram pushed a commit to rshriram/envoy that referenced this issue Oct 30, 2018
…#311)

* Support mixerclient to extract authentication attributes

* Fixes file format.

* Fixes file format.

* Updated function name for Auth attributes extraction.

* Update function comment.
lizan pushed a commit to lizan/envoy that referenced this issue Nov 25, 2019
Signed-off-by: John Plevyak <jplevyak@gmail.com>
jpsim pushed a commit that referenced this issue Nov 28, 2022
Moves the streaming method requirements out of the `EnvoyEngine` class and into a protocol interface. Swift will then take a conformer to this protocol instead of calling directly into `EnvoyEngine`, which will allow us to inject mock conformers for better testing. We'll do this on Android as well.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit that referenced this issue Nov 29, 2022
Moves the streaming method requirements out of the `EnvoyEngine` class and into a protocol interface. Swift will then take a conformer to this protocol instead of calling directly into `EnvoyEngine`, which will allow us to inject mock conformers for better testing. We'll do this on Android as well.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions that are neither investigations, bugs, nor enhancements
Projects
None yet
Development

No branches or pull requests

4 participants