[Doc] Update Helm chart instructions to avoid UX friction when using Kind

[kevin85421]

Proposed changes

For kind clusters, NodePort services require extra configuration and LoadBalancer services need a third-party controller like MetalLB for external IP assignment. However, the Helm chart creates a LoadBalancer service by default. Therefore, the --wait flag will hang until timeout.

The guide running-on-kind.md asks users to create a Kind cluster by running the make create-kind-cluster command. However, the command neither sets the extraPortMappings Kind configs nor installs MetalLB, so users cannot use NodePort and LoadBalancer directly after running the command.

This PR suggests users disable the creation of NodePort / LoadBalancer Kubernetes service, and uses the port-forwarding command from the running-on-kind.md guide.

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

[kevin85421]

Sorry, I did not notice the presence of a pre-commit configuration. I have now fixed the linting error.

[sjberman]

@kevin85421 We're about to migrate our docs a little bit in the next day or two, so we'll wait to rebase your change on the new structure before we look at merging it.

[kevin85421]

Just out of curiosity, what's the reason for using LoadBalancer as the default service instead of ClusterIP? Based on my observation, the L4 load balancing seems to be less popular in the Kubernetes community. Thanks!

[sjberman]

@kevin85421 The main use case of NGINX Gateway Fabric is to get traffic into a cluster, using it as an ingress point. ClusterIP Services are for traffic within the cluster network, whereas the LB Service is for getting traffic into the cluster from an outside source.

[sjberman]

@kevin85421 Our docs have now been migrated if you want to rebase. The kind document now lives at /site/content/installation/running-on-kind.md. Please format the note as {{<note>}}your text{{</note>}}, instead of using ">".

[kevin85421]

@kevin85421 The main use case of NGINX Gateway Fabric is to get traffic into a cluster, using it as an ingress point. ClusterIP Services are for traffic within the cluster network, whereas the LB Service is for getting traffic into the cluster from an outside source.

Thank @sjberman for your reply! Recently, I have begun delving into more details about Kubernetes networking to enhance support for Ray Serve on Kubernetes (KubeRay). Therefore, some of my questions might be basic.

I've come across numerous articles and videos (example) that compare the Kubernetes LoadBalancer service (OSI L4) and Ingress/Gateway (OSI L7) as alternatives. Hence, this makes me feel a bit puzzled when they are presented simultaneously.

Based on your reply, I guess:

• Kubernetes LoadBalancer Service: Each application running on the Kubernetes cluster requires its own LoadBalancer, which can be expensive.
• Ingress/Gateway: With Ingress/Gateway, users only need to create a LoadBalancer for the Ingress/Gateway controller. This controller can then forward requests to multiple applications within the Kubernetes cluster.

Is my understanding correct? Thanks!

[sjberman]

@kevin85421 Yes, you're understanding is correct. Ingress/Gateway is fronted by a load balancer for traffic incoming to the cluster, and then the Ingress/Gateway handles routing traffic to all of your backends within the cluster.

[netlify]

✅ Deploy Preview for nginx-gateway-fabric ready!

Name	Link
🔨 Latest commit	a2abd4a
🔍 Latest deploy log	https://app.netlify.com/sites/nginx-gateway-fabric/deploys/656de890bb0d330008741e3d
😎 Deploy Preview	https://deploy-preview-1281--nginx-gateway-fabric.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kevin85421]

I have already updated the PR. I will figure out how to build the documentation locally and ensure that it is rendered correctly.

[kevin85421]

I followed this doc and ran hugo server -e development -b "http://127.0.0.1/nginx-gateway-fabric/" to build the doc locally, and the note is rendered correctly.

[ADubhlaoich]

LGTM!