NGINX LoadBalancer Service IPFamily should match ipFamily from NginxProxy configuration

[sjberman]

When provisioning the NGINX LoadBalancer Service, the IPFamily should be set based on the ipFamily that is set in the NginxProxy resource for the associated Gateway for that Service.

Right now we just create the Service with the Kubernetes default values, which will likely be SingleStack IPv4 in most cases.

Since a user can no longer manually edit the LoadBalancer Service as of our 2.0 release (due to the fact that the control plane provisions and controls it based on the NginxProxy config), this could block users from using dual stack IP traffic.

A user could set to SingleStack IPv6 if they configure their kube-apiserver with an IPv6 address range for the first argument in the --service-cluster-ip-range parameter, but I'm not sure if there's a way to configure k8s itself to default to dual stack.

Acceptance

• When provisioning the NGINX Service, set the ipFamily and ipFamilyPolicy fields based on the ipFamily field in the NginxProxy resource (default is DualStack)

[aviallon]

Thanks for reporting the issue.
Indeed, I am using the 2.0 release.
I guess I'll patch it myself for my own use.

By the way, would it make sense to pass-through any key Nginx doesn't manage to the LoadBalancer?

[sjberman]

By the way, would it make sense to pass-through any key Nginx doesn't manage to the LoadBalancer?

Which keys are you referring to? Any of the fields in the Service spec?

[aviallon]

By the way, would it make sense to pass-through any key Nginx doesn't manage to the LoadBalancer?

Which keys are you referring to? Any of the fields in the Service spec?

Yes, indeed. This is the only way to cover everyone's use case.

[sjberman]

Our goal is to expose most (if not all) of the Service spec fields so that a user can configure them through our NginxProxy CRD. The current behavior is that if a user doesn't specify them, then we use the Kubernetes defaults. There aren't too many fields, but we missed the IPFamily here.

Unfortunately we decided against letting users edit the NGINX Service directly, because then we are stuck in a position that isn't very deterministic. When provisioning or updating the Service, we would have to decide whether to leave the fields empty (using Kubernetes defaults) or get the user's manual configuration and apply that (while having to know if the user's configuration is different from the k8s defaults so we know if we need to apply it or not). And then somehow reconcile that with the NginxProxy fields that tell our control plane how we need to configure the Service.

It gets messy :) so we decided that the NginxProxy resource is the source of truth, and if nothing is specified, then Kubernetes defaults are used by leaving those fields empty. We just need to ensure that all fields are available in there for users to set.

[sjberman]

Fix will be included in a patch release, hopefully next week. Thanks for bringing this to our attention!

[sjberman]

Once merged into main, you can also verify the fix in the edge release, before we release the patch.