1
votes

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)?

From what I've read in another post, one suitable recommendation is to use NodePort, and manually point yet another external load balancer to the port on your Kubernetes nodes.

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.)

Is there any other mechanism maybe to expose the ingress controller to the external world?

2
Hello, there are a few options here on how you can handle this scenario kubernetes.github.io/ingress-nginx/deploy/baremetalShawlz
Thank you @Shawlz ! This reading is exactly what I was looking for!apereirapy

2 Answers

1
votes

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

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.

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.

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

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

0
votes

You can specify the port via nodePort in the service. Then it would not be random.