-
Notifications
You must be signed in to change notification settings - Fork 11
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
Pro/con in description #39
Comments
Thank you for suggestion. One of pros for nghttpx is it can connect to backend using HTTP/2 protocol with L7 routing, which nginx lacks at the moment. |
That can indeed improve performances (wonder how much given Ingress Controller and Pods are co-located), if the servers behind also support it. |
As for location of Ingress controller, and service Pods, Ingress controller is typically running as DaemonSet on dedicated node (e.g, node label selection), and Pods will be on the other nodes. |
But even nghttpx would be an endpoint for L7 and just create another L7 to gRPC server, no? |
If I understand correctly, yes. Ingress is L7 thing. |
nghttpx can change backend configuration without reloading/process restart. It is just a matter of internal HTTP POST request, and we are done. We use watch interface for Ingress resource, and the application of change is done very fast. I'm not sure that nginx supports this. |
I see in README "nghttpx ingress controller is created based on nginx ingress controller." which makes sense but looking at this repo and knowing it has less people behind it, it makes me wonder: Why would I want to use nghttpx instead of Nginx Ingress Controller as Nginx also support HTTP/2.
May be you could include a short PRO/CON next to that statement.
The text was updated successfully, but these errors were encountered: