<p>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)</p>
<p>but it has an nginx ingress controller :</p>
<pre><code> 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   &lt;none&gt;           &lt;none&gt;
pod/nginx-ingress-controller-72d8s          1/1     Running   0          6d    172.34.10.123    pr-k8s-fe-fastdata-worker-03   &lt;none&gt;           &lt;none&gt;
pod/nginx-ingress-controller-rn4fw          1/1     Running   0          6d    172.34.10.192    pr-k8s-fe-fastdata-worker-01   &lt;none&gt;           &lt;none&gt;
pod/nginx-ingress-controller-v2m8b          1/1     Running   0          6d    172.34.10.173    pr-k8s-fe-fastdata-worker-02   &lt;none&gt;           &lt;none&gt;

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service/default-http-backend   ClusterIP   192.168.33.89   &lt;none&gt;        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           &lt;none&gt;          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

</code></pre>
<p>and as I'm watching a video tutorial ( <a href="https://www.youtube.com/watch?v=KnOZwxvxfnA" rel="nofollow noreferrer">[ Kube 59.1 ] Nginx Ingress in Kubernetes Revisited</a>) <strong>I noticed that he when he display all like me alongside the default backen svc in the ingress namespace he also has an &quot;ingress-controller svc of type load balancer&quot; and I don't, so how can I rectify that ?</strong>
thank you for your help .</p>

Ait Zaid
<p><a href="https://youtu.be/KnOZwxvxfnA?t=205" rel="nofollow noreferrer">Nginx Ingress in Kubernetes Revisited 3:25</a> --&gt; he sais that <code>nginx-ingress-controller</code> of type <code>LoadBalancer</code> goes from <a href="https://stackoverflow.com/questions/65985098/no-externalip-showing-in-kubernetes-nodes/65991935#65991935"><strong>Metallb</strong></a>. That means he running on-prem cluster, not in cloud. You can install the same using kubeadm</p>
<p>MetalLB makes LoadBalancer services:
<a href="https://metallb.universe.tf/" rel="nofollow noreferrer">https://metallb.universe.tf/</a></p>
<blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</blockquote>
