Introduction

When Minikube is reinstalled, the cluster identity, IP address, certificates, and addon state can all change. NGINX Ingress problems after reinstall usually come from stale local assumptions rather than from ingress itself: an old minikube ip, an outdated /etc/hosts entry, a missing addon, or ingress resources that still point at services no longer matching the new cluster.

Reinstalling Minikube Changes More Than You Think

A fresh Minikube cluster is not just the old cluster restarted. It may have:

• a new control-plane IP
• a new Kubernetes version
• a new container runtime state
• no previously enabled addons
• empty cluster resources unless you reapplied them

If your browser or curl command still targets the old Minikube IP, ingress will appear broken even if the new controller is healthy.

The first command to run is:

minikube status
minikube ip
kubectl config current-context

Make sure your shell is talking to the current Minikube cluster and not to an old context.

Re-enable the Ingress Addon

On Minikube, the easiest NGINX ingress path is the built-in addon. After reinstall, that addon may simply be disabled.

minikube addons enable ingress
kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

Wait until the ingress controller pod is Running and ready. If the namespace does not exist or the controller never starts, the addon installation is incomplete.

Verify the Application Service and Ingress Object

Ingress only routes traffic to services that already work inside the cluster. Before debugging hostnames, confirm the service and endpoints are healthy.

1kubectl get svc
2kubectl get endpoints
3kubectl get ingress
4kubectl describe ingress your-ingress-name

A common failure is that the ingress resource still exists, but the service selector no longer matches the pods deployed after reinstall. In that case, the ingress controller is fine; it just has no healthy backend endpoints to send traffic to.

Update Local Hostname Mapping

Many Minikube ingress tutorials rely on a local hosts entry such as:

192.168.49.2 myapp.local

After reinstall, the Minikube IP often changes. If /etc/hosts still points to the previous address, every ingress request goes to the wrong place.

Refresh the IP and update the hosts file accordingly.

minikube ip

If you use nip.io or a similar wildcard DNS helper, rebuild the hostname using the current IP instead of reusing the old URL blindly.

Check the Ingress Class

Recent Kubernetes setups can require an explicit ingress class. If the NGINX controller watches only a specific class and your ingress resource does not declare it, the controller may ignore the object.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: demo.local
9      http:
10        paths:
11          - path: /
12            pathType: Prefix
13            backend:
14              service:
15                name: demo-service
16                port:
17                  number: 80

This detail becomes especially relevant after reinstall because the controller version or defaults may differ from the previous cluster.

Read the Controller Logs

If the addon is enabled and the ingress object exists, the controller logs usually tell you what is missing.

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Look for messages about:

• ignored ingress objects
• invalid backends
• missing services
• host or path rule parsing failures

These logs are much more useful than guessing from browser behavior alone.

A Reliable Recovery Sequence

When the local setup is confused, a clean recovery sequence is often faster than piecemeal debugging.

1minikube delete
2minikube start
3minikube addons enable ingress
4kubectl apply -f deployment.yaml
5kubectl apply -f service.yaml
6kubectl apply -f ingress.yaml
7kubectl get all -A
8kubectl get ingress -A

Then update the local host mapping with the fresh minikube ip and test again.

This is effective because it rebuilds the known-good order: cluster, controller, app, service, ingress, local routing.

Common Pitfalls

The most common mistake is keeping an old Minikube IP in /etc/hosts or in a bookmarked URL.

Another frequent issue is forgetting to re-enable the ingress addon after reinstalling Minikube.

Developers also debug the ingress object before checking whether the backend service has endpoints. If the service is broken, ingress cannot fix it.

Finally, watch for ingress-class mismatches after version changes. A resource that worked in an older local cluster may now be ignored until ingressClassName is explicit.

Summary

• Reinstalling Minikube changes cluster state, IP address, and addon state.
• Re-enable the ingress addon and confirm the controller pod is healthy.
• Verify the backend service and endpoints before blaming ingress.
• Update any local host mapping to the new minikube ip.
• Check ingress class and controller logs when the object exists but routing still fails.