Proposal to add loadBalancerClass to Helm Chart

[RouxAntoine]

Background

I want to use the nginx-gateway-fabric in a on-premises environment the fact is that there is no default loadBalancerClass in this cluster, So no ip is assign to my services.

Proposal

I propose to enhance the Helm chart by adding support for loadBalancerClass in the service specification. This addition will allow users to define class name of loadbalancer controller that can handle the service, support multiple loadbalancer controller in a same cluster.

Implementation

The addition involves updating the service.yaml template to include a conditional check for loadBalancerClass values and append them to the service spec if provided. The values.yaml file will also need to be updated to include a default empty configuration for backward compatibility.

Example:
In values.yaml, users could specify:

service:
  type: LoadBalancer
  loadBalancerClass: metallb

This list would be utilized in service.yaml as:

spec:
  {{- if .Values.service.loadBalancerClass }}
  loadBalancerClass: {{ .Values.service.loadBalancerClass }}
  {{- end }}

Benefits

• Usability: support cluster without default loadbalancer class.
• Flexibility: allow different loadbalancer class for different nginx-gateway-fabric deployment.

Seeking Feedback

I would appreciate feedback on everything.

Contribution Offer

I could do the pull request :)
My pull request would be highly inspired by this one

[sjberman]

Thanks @RouxAntoine for the suggestion. We are currently in the process of changing our architecture a bit, so the addition of this field will be a little bit more than just a helm chart addition. But we can definitely include this in the changeset to allow users to configure this on the load balancer service.

[RouxAntoine]

Ok thanks for considering.

For the moment I don't use NginxProxy at all, not sure to understand its purpose.

I try to follow this https://docs.nginx.com/nginx-gateway-fabric/installation/installing-ngf/helm/
to deploy nginx-gateway-fabric to handle the gateway of my cluster.

From what I seems to understand the proxy will became a required asset in future ?

Is the configuration you are talking about this one https://github.com/nginx/nginx-gateway-fabric/blob/tests/update-nfr-cp-dp/charts/nginx-gateway-fabric/templates/nginxproxy.yaml#L32 ?

[sjberman]

We are working on splitting the control plane and data plane (nginx) into separate pods. The control plane will provision the data plane when a Gateway resource is created, and the NginxProxy resource (which will be able to attach to either the GatewayClass or the Gateway) can control infrastructure-related fields (like loadBalancerClass) for the nginx deployment/service that we provision.

You'll be able to set the global Service config in the helm chart, which will set the value in the NginxProxy attached to the GatewayClass, which will be created at installation time. If you create multiple Gateways, you could create multiple NginxProxy resources with different configurations and attach to each one. This will all be coming in our 2.0 release.

Currently, the NginxProxy resource is used to configure some global nginx settings.

[RouxAntoine]

Thanks for explanation and link 🙂

[sjberman]

Closing this discussion in favor of #3303