[Kubernetes]Accessing cluster nginx, dashboard and other services on the external public IP

How to access the cluster nginx, dashboard and other services on the external public IP? I have tried metallb, ingress-nginx, but not yet working are am I doing something wrong or something else I have to try?

With a problem statement as vague as this, all I can say is that you should indeed keep trying.

I have following

pod/dashboard-metrics-scraper-799d786dbf-9jgxn   1/1     Running   0          24m
pod/kubernetes-dashboard-6b6b86c4c5-kqgb4        1/1     Running   0          24m

NAME                                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/dashboard-metrics-scraper   ClusterIP   <none>        8000/TCP   24m
service/kubernetes-dashboard        ClusterIP   <none>        443/TCP    24m

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/dashboard-metrics-scraper   1/1     1            1           24m
deployment.apps/kubernetes-dashboard        1/1     1            1           24m

NAME                                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/dashboard-metrics-scraper-799d786dbf   1         1         1       24m
replicaset.apps/kubernetes-dashboard-6b6b86c4c5        1         1         1       24m```
What is the best way to access the dashboard now?

Concept-wise reading this article of mine may tilt your table somewhat so that things get rolling.

If you read this, you’ll probably know what to look for as your next step. In case you don’t, come back and ask.

If I understand correctly I need an Ingress controller to access the dashboard. as of now dashboard is getting served at Cluster-IP … and need to get it running at external-IP to access.

If I try to do the port-forward it is still serving at the clusternetwork and not the public external IP. What am I doing wrong?

Do you have a ingress-controller and ingress rules to access the dashboard? If yes, how are you trying to access them?

Ingress-controller I don’t have yet trying this now . do you have any other suggestion for ingress-controller

It gives following and external IP as pending (as I don’t have LoadBalancer or the Ingress-controller)

pod/ingress-nginx-ingress-controller-7d945f9ff5-x6g5x                 1/1     Running   0          76s
pod/ingress-nginx-ingress-controller-default-backend-7d448456fkrfdq   1/1     Running   0          76s

NAME                                                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-ingress-controller                   LoadBalancer   <pending>     80:31035/TCP,443:32736/TCP   76s
service/ingress-nginx-ingress-controller-default-backend   ClusterIP    <none>        80/TCP                       76s

NAME                                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-ingress-controller                   1/1     1            1           76s
deployment.apps/ingress-nginx-ingress-controller-default-backend   1/1     1            1           76s

NAME                                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-ingress-controller-7d945f9ff5                   1         1         1       76s
replicaset.apps/ingress-nginx-ingress-controller-default-backend-7d448456f9   1         1         1       76s```
 which one should I have ? LoadBalancer or the Ingress-controller?

Please try to comprehend what you read before flinging code about.

You do not have to have an ingress controller if you don’t use Ingress resources.

And you don’t have to use Ingress resources to expose a service.

This time, however, this particular service will probably have best been exposed that way.

And, as stated earlier, the way most people do this is via exposing the ingress controller and routing all requests through it to the actual service you wanted to publish, which are in this context referred to as backends from the Ingress perspective. A backend still needs to be a service, though. The most common pattern is that the backend remains of the type ClusterIP.

The ingress controller will not do anything unless there is an incoming request hitting it that wants to access a path on a host that it has an Ingress rule configured for.

Request -> ingress controller -> backend service -> pod -> container -> netloc

Exposure of the ingress controller can happen in multiple ways, but I generally recommend using a LoadBalancer-type service

The IC itself is a self-configuring reverse proxy that consumes Ingress resources, adding their rules to its configuration and rehashing when needed

LoadBalancer-type service means can it be metallb? I have done the metallb but it takes a random internal IP and not the external IP, should I work more on that or metallb is not the solution and something else?

MetalLB is an on-prem CCM implementation for LoadBalancer-type services.