nginx ingress no controller service

Question

Helo guys I'd like some help with an issue : I'm using a kubernetes cluster that is provided to me by rancher (so I did not configured it)

but it has an nginx ingress controller :

 kubectl -n ingress-nginx get all -o wide
NAME                                        READY   STATUS    RESTARTS   AGE   IP               NODE                           NOMINATED NODE   READINESS GATES
pod/default-http-backend-598b7d7dbd-fgpns   1/1     Running   3          48d   192.168.121.64   pr-k8s-fe-fastdata-worker-02   <none>           <none>
pod/nginx-ingress-controller-72d8s          1/1     Running   0          6d    172.34.10.123    pr-k8s-fe-fastdata-worker-03   <none>           <none>
pod/nginx-ingress-controller-rn4fw          1/1     Running   0          6d    172.34.10.192    pr-k8s-fe-fastdata-worker-01   <none>           <none>
pod/nginx-ingress-controller-v2m8b          1/1     Running   0          6d    172.34.10.173    pr-k8s-fe-fastdata-worker-02   <none>           <none>

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service/default-http-backend   ClusterIP   192.168.33.89   <none>        80/TCP    48d   app=default-http-backend

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS                 IMAGES                                                   SELECTOR
daemonset.apps/nginx-ingress-controller   3         3         3       3            3           <none>          48d   nginx-ingress-controller   rancher/nginx-ingress-controller:nginx-0.35.0-rancher1   app=ingress-nginx

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS             IMAGES                                                         SELECTOR
deployment.apps/default-http-backend   1/1     1            1           48d   default-http-backend   rancher/nginx-ingress-controller-defaultbackend:1.5-rancher1   app=default-http-backend

NAME                                              DESIRED   CURRENT   READY   AGE   CONTAINERS             IMAGES                                                         SELECTOR
replicaset.apps/default-http-backend-598b7d7dbd   1         1         1       48d   default-http-backend   rancher/nginx-ingress-controller-defaultbackend:1.5-rancher1   app=default-http-backend,pod-template-hash=598b7d7dbd

and as I'm watching a video tutorial ( [ Kube 59.1 ] Nginx Ingress in Kubernetes Revisited) I noticed that he when he display all like me alongside the default backen svc in the ingress namespace he also has an "ingress-controller svc of type load balancer" and I don't, so how can I rectify that ? thank you for your help .

Answer 1

So I managed to make it work , the nginx that was on my rancher was deployed from the rancher app catalogue, and the field "deploy a service" was set to false, so I upgraded it and put the field to true and it deployed me the load balancing service so now it's working fine. Thank you

Answer 2

Nginx Ingress in Kubernetes Revisited 3:25 --> he sais that nginx-ingress-controller of type LoadBalancer goes from Metallb. That means he running on-prem cluster, not in cloud. You can install the same using kubeadm

MetalLB makes LoadBalancer services: https://metallb.universe.tf/

Kubernetes does not offer an implementation of network load-balancers (Services of type LoadBalancer) for bare metal clusters. The implementations of Network LB that Kubernetes does ship with are all glue code that calls out to various IaaS platforms (GCP, AWS, Azure…). If you’re not running on a supported IaaS platform (GCP, AWS, Azure…), LoadBalancers will remain in the “pending” state indefinitely when created.

Bare metal cluster operators are left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare metal clusters second class citizens in the Kubernetes ecosystem.

MetalLB aims to redress this imbalance by offering a Network LB implementation that integrates with standard network equipment, so that external services on bare metal clusters also “just work” as much as possible.