QUIC & HTTP/2 Ingress controller

[wernight]

I see there are various Ingress controller, even though I don't know how to choose in my Kuberentes Yaml files.

I'd like to suggest having one that enabled QUIC and HTTP/2 like https://devsisters.github.io/goquic/ does. It should also support WebSockets. That would allow easy creation of a network Ingress frontend that would improve speed for many users transparently. The current GoQuic doesn't support virtualhost so that would have to be implemented somehow.

[aledbf]

@wernight the nginx ingress controller supports http/2, spdy and websockets ootb.
I'm not sure nginx will support QUIC in the near future

[wernight]

I wasn't referring to just supporting it, but to have it automatically server as HTTP/2 QUIC reverse proxy. Like QoQuic but for all domains (or selected domain of an Ingress). I agree having support for it and then install GoQuic on all endpoints.

Just wondering, how can one use the Nginx Ingress instead of whatever is the default (that doesn't support WebSocket in my test)?

[aledbf]

@wernight this was opened today in the nginx trac https://trac.nginx.org/nginx/ticket/1057

[bprashanth]

I see there are various Ingress controller, even though I don't know how to choose in my Kuberentes Yaml files.

Currently, through an annotation like: https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc, https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#disabling-nginx-ingress-controller
In the future we might have ingress claims: kubernetes/kubernetes#30151

not sure if that's what you meant

[wernight]

What I mean is I'd like to use Nginx Ingress Controller (that's pretty easy) and no matter the backend (may be that Ingress connects to the actual services via HTTP and that's fine), it could support QUIC and act as QUIC proxy.

This means that the (very likely slower) connection from clients to Ingress would be QUIC-enabled without any extra work. The connection from Ingress to the various services could also support QUIC and make use of it, but I don't see it being a big gain for most.

[bprashanth]

That should be easy once nginx supports quic. You can flip it at various levels:

1. All ingresses: command line flag to controller
2. Opt in at ingress level: annotation
3. Opt in at host level: field

1 or 2 actually makes the most sense to begin with. Converging to 3 will allow us to enable Quic from ingress to backend, but like you pointed out the more important journey is from client -> ingress. Also 3 is harder because this won't work cross platform.

I believe caddy supports quic, though I don't think anyones written an ingress controller for it yet.

[metalshark]

@aledbf how do you enable HTTP/2 on the Nginx Ingress Controller? I don't seem to get it ootb

[aledbf]

@metalshark is enabled by default

[metalshark]

@aledbf thanks

Must be due to the Azure Load Balancer infront on it.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close