<p>This is more a design question than an issue. We have deployed in our company our own Kubernetes infrastructure and we are trying to use ingresses and NGINX ingress controller to externally expose our services, but since it is not a cloud environment such as GCP or AWS, we can't use service type "LoadBalancer". Should we just expose our ingress controller through a service type "NodePort"? Is that the normal way to go for production environments (non-cloud)?</p>

<p>From what I've read in another <a href="https://stackoverflow.com/questions/52654769/how-to-expose-a-ingress-for-external-access-in-kubernetes">post</a>, one suitable recommendation is to use NodePort, and manually point yet another external load balancer to the port on your Kubernetes nodes.</p>

<p>It just seems that exposing the ingress controller through this mechanism is somehow not very practical or robust (e.g. you don’t know what port your service is going to be allocated, and the port might get re-allocated at some point, etc.)</p>

<p>Is there any other mechanism maybe to expose the ingress controller to the external world?</p>

apereirapy
<p>The Loadbalancer service approach is one way to do it but behind it it's nothing more than a nodeport on the cluster.</p>

<p>Even if you use a service that create a LB on cloud provider, the LB needs to have a target port to communicate with the cluster.</p>

<p>When using a nginx-ingress that will mostly handle web requests, it's common usage to put an ingress in front of a nodeport service.</p>

<p>So with this I think using NodePort services is a good idea to do what you want ;)</p>

<p>This is my opinion, I'm interested if anyone else has another way to do it.</p>
