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 10.110.97.46 <none> 8000/TCP 24m service/kubernetes-dashboard ClusterIP 10.105.88.10 <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 10.110.180.58 <pending> 80:31035/TCP,443:32736/TCP 76s service/ingress-nginx-ingress-controller-default-backend ClusterIP 10.109.54.99 <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
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.