Replies: 5 comments 8 replies
-
I would first probably make the subject more descripting of the problem being solved. As "configuration for production use" is pretty vague. Is the intention to support some type of 'snippets' functionality? My assumption would be both that the user has knowledge of nginx.conf as well as they would not try to bypass the API objects entirely (and thus the value of a controller) by simply presenting a complete nginx.conf. |
Beta Was this translation helpful? Give feedback.
-
The NIC capabilities of snippets, custom templates, and custom annotations was mentioned. While custom templates, custom annotations, and template customization are possible - they tend to limit and restrict the ability for users to upgrade. Upgrades frequently result in broken configurations. Or the upgrade cycle is long for these customers to validate and update for each release which results in the customers not keeping up to date. The snippets style is a pattern has survived well through upgrades. Combine this with reliable NGINX behavior from directives and the customers have had a relatively painless experience with this pattern. |
Beta Was this translation helpful? Give feedback.
-
For the functionality that can be updated by a user directly in the initialization ConfigMap, we can document a user's ability to do this. We would need to be clear that this is not dynamic and will only be set at deploy-time. For backend-specific settings that cannot be set at deploy time, we can rely on nginx defaults, or update the defaults to values we think are better. This would cover most general cases for users until we allow more fine-tuning for the users that will get into the weeds more. If we truly want to expose a general way to inject nginx config at v1.0, like snippets, we need to consider security implications and treat them as a feature, and not just a "hack" for users to update configuration until we have an official API for them, because users will take this feature and run with it. Support and engineering will be on the hook to help diagnose issues with it. This all means that it should be robust from the start so we don't break things to make it better in a future release. Which leads to the question of: do we have time for that compared to our current list of must-haves for v1.0? |
Beta Was this translation helpful? Give feedback.
-
Closing this because #1566 and https://github.com/nginxinc/nginx-gateway-fabric/blob/main/docs/proposals/nginx-extensions.md will address the mentioned production use cases. |
Beta Was this translation helpful? Give feedback.
-
@pleshakov Do u know when body size setting will be available on production? |
Beta Was this translation helpful? Give feedback.
-
Summary
Problem statement
How can we support NGINX configuration not available in the Gateway API, but relevant for production use? So that our users can start using NGINX Kubernetes Gateway (NKG) in their production environments?
This discussion is to:
Out of Scope
We will focus on NGINX configuration related to basic proxying features available through Gateway API HTTPRoute and Gateway resources rather than advanced features like authentication and rate limiting.
Background
Currently, NKG supports features reflected in https://github.com/nginxinc/nginx-kubernetes-gateway/blob/1df6bcd08129c687178a38f880f95871fb5275c2/docs/gateway-api-compatibility.md
Supporting those features does not mean NKG is suitable for production use, as many NGINX configuration settings related to those features are not available to configure through the Gateway API resources.
Below is a list of such settings:
Additionally, sometimes, it is necessary to tune some aspect of NGINX behavior from a broader number of NGINX directives. For example, configure the backlog parameter of the listen directive for high performance optimization. In NKG, we already support the listen directive - it is necessary for NGINX to accept client traffic -- but we don't expose the listen directive parameters.
What do we already have in NKG?
So far, NKG only supports features configurable through Gateway API resources. For many of those features, NKG either chooses a default or uses the NGINX default for the settings mentioned above.
Additionally, NKG creates the main NGINX configuration file from this ConfigMap -- https://github.com/nginxinc/nginx-kubernetes-gateway/blob/1df6bcd08129c687178a38f880f95871fb5275c2/deploy/manifests/nginx-conf.yaml#L8-L20 -- so a number of those mentioned above settings can be supported by editing that ConfigMap.
Can Gateway API support those settings?
Evolution of Gateway API
Some of those settings, although in limited form (because of data plane differences) will (or might) be supported in the Gateway API:
Extensibility of Gateway API
The Gateway API comes with a number of extension points that NKG can take advantage of to expose additional NGINX-specific settings. See https://gateway-api.sigs.k8s.io/concepts/api-overview/#extension-points
Additionally, the GatewayClass resource can reference a ConfigMap or an implementation specific resource that can define implementation-specific configuration -- https://gateway-api.sigs.k8s.io/api-types/gatewayclass/#gatewayclass-parameters
Gateway resource will reference an implementation specific configuration once this GEP https://gateway-api.sigs.k8s.io/geps/gep-1867/ is implemented.
Existing Solutions in Related Projects
In NGINX Ingress Controller (NIC) those settings are part of its configuration API:
Additionally, NIC comes with advanced configuration method to support settings not available through the configuration API:
Beta Was this translation helpful? Give feedback.
All reactions