Ingress-nginx: Support per-ingress http2 setting through annotation

Created on 9 Mar 2018 · 13Comments · Source: kubernetes/ingress-nginx

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/.): No

What keywords did you search in NGINX Ingress controller issues before filing this one? (If you have found any duplicates, you should instead reply there.): http2

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature Request

Add ingress annotation support for use-http2. So each ingress can choose whether to use http2 or not.

Currently setting nginx.ingress.kubernetes.io/use-http2: "false" Isn't disabling http2 in an ingress. It appears http2 can only be disabled in the controller configmap.

help wanted kinfeature lifecyclrotten

Source

twk3

Most helpful comment

It's better to make use-http2 a per ingress rules not a global config

oilbeater on 17 Mar 2018

👍4

All 13 comments

It's better to make use-http2 a per ingress rules not a global config

oilbeater on 17 Mar 2018

👍4

Is there any progress on this? Nginx shows really bad performance for me when POSTing large files using http2(8x slowdown), this also appears to happen when proxying grpc.

noonien on 10 Apr 2018

Is there any progress on this?

No. One of the reasons is we can enable/disable only in the listen directive of the server section, meaning all the ingress rules (paths) will have http2 disabled.

aledbf on 10 Apr 2018

Could an annotation format specify per-path rules? Though AFAICT that would require a new parser. I imagine either a map of uris to boolean overrides, or two lists of uris. Something like nginx.ingress.kubernetes.io/(enable/disable)-http2: '["www.host1.com/", "host1.com/", "host2.com/v1"]'.

But I know I could use a feature that just disables http2 per-ingress. Do you think that would still be accepted @aledbf?

nicknovitski on 20 Apr 2018

@nicknovitski you cannot disable http2 per Ingress (path). If you disable http2 is for all the locations.
This is because http2 directive is in the listen section of the nginx.conf file

aledbf on 21 Apr 2018

Ah, I think I understand: different Ingress resources can create location config blocks inside the same server config block, so there's no way to translate an annotation on one Ingress resource into behavior that only effects the paths created by that resource. Is that it?

What I was hoping for is a clean way to disable http2 on an entire server block. We get some traffic from clients effected by this problem, and http2 causes them to crash. Since in our case all requests from those clients are made to the same Host, it seemed possible to keep http2 enabled for all traffic except to that host/"server".

What about new ConfigMap key, something like server-http2-blacklist? It'd default to being empty, have the type []string. Then you add a function to the template for seeing if a slice includes some value, and change the server template from {{ if $all.Cfg.UseHTTP2 }} to something like {{ if (and $all.Cfg.UseHTTP2 (not (includes $all.Cfg.ServerHTTP2Blacklist)) }}. Does that sound possible, and acceptable?

nicknovitski on 23 Apr 2018

Ah, I think I understand: different Ingress resources can create location config blocks inside the same server config block, so there's no way to translate an annotation on one Ingress resource into behavior that only effects the paths created by that resource. Is that it?

Exactly

Does that sound possible, and acceptable?

Yes, that makes more sense because is configured in the configuration configmap and it's easy to track where this is.

aledbf on 23 Apr 2018

I have code that I'm pretty sure works. I only have to add e2e tests for it.

nicknovitski on 4 May 2018

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.

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 on 2 Aug 2018

We really need this, is there anything blocking it we can help with?

blakebarnett on 30 Aug 2018

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

fejta-bot on 29 Sep 2018

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

fejta-bot on 29 Oct 2018

@fejta-bot: Closing this issue.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.