Should we align NGINX Ingress Controller Defaults with NGINX Defaults. And if so, how?

[j1m-ryan]

In issue #5050 , it was pointed out that we don't follow NGINX defaults for keepalive_timeout and keepalive_requests. We currently default to 65 and 100 respectively for these values whereas NGINX defaults to 75 and 1000 since 1.19.

The reason we do not follow the default, is because we hardcode these values in NIC, and add keepalive_timeout and keepalive_requests to the config irrespective of whether the user has specified them.

Considering the substantial increase in keepalive_requests could be more than a modest adjustment, should we update our this new defuault to align with NGINX's?

Additionally, should we consider not setting these directives unless specified by the user, allowing for NGINX's latest defaults to always take precedence if undefined by the user (rather than us updating this struct of defaults)?

[brianehlert]

This is a larger exercise across the project.
While NGINX has raised a number of the defaults from the time this project has started, this has not been monitored by the maintainers.

In theory, all users of the project would see performance or experience improvements.

NGINX does not change its defaults lightly. They only do it cases where they feel the experience improvements are worth it, or common practices have changed and the settings align with those.

There are two ways to tackle defaults.
One is expose the directive using a parameter or configmap and set the new default value. Thus the setting is always tune-able.
Another is to simply modify defaults that are applied using the project go templates.
Another is to omit directives when not set, which causes NGINX to default to current.

[nickzelei]

I'm not an advanced nginx user by any means. I'm coming to this project with pretty fresh eyes, as I'm deploying NIC into my clusters.

The problem I ran in to in the issue above was solely based on assumptions, and I'd like to flavor some insight as a new user coming to this project, as I'm sure I am not the only one with these assumptions.

My view on the NIC is that it is simply nginx wrapped into the Kubernetes environment. nginx for K8s.
With that said, I would assume that the nginx docs are the source of truth, and that the NIC simply provides a k8s native way to deploy and assume nginx.

Using the configmap to configure nginx is the k8s way to turn the knobs on what would otherwise be the nginx.conf file. Anything not set in the conf file would simply fall back on the nginx config defaults laid out in the nginx documentation.

However, I've come to realize that isn't true and that there is config drift due to defaults being set in the NIC configmap. I can't really treat the nginx docs as the source of truth anymore, and now must treat the NIC configmap docs as that.

I understand the world isn't perfect and that there are most likely differences and that it's ok to just switch up the mental model and refer to those docs instead, it just makes it harder to find an answer sometimes when most internet searching points to nginx directly, where as now those results simply have an asterisk next to them and must be double checked against the NIC documentation.

Anyways, it would be great to more easily opt the NIC into the nginx defaults so that it can more easily benefit from the main project's decisions, which would allow the NIC to directly benefit from those, as they undoubtedly have more inertia behind them.

Hopefully this insight is helpful! Great work on the project and overall am super happy with it!

[j1m-ryan]

Closing this after merging #5083