Introduction

When Ingress works in Kubernetes but not in a browser on a MacBook, the problem is usually not the browser itself. The usual causes are missing local DNS mapping, no ingress controller running, or using a local Kubernetes environment where the ingress address is not exposed the way a cloud cluster would expose it.

First Check the Controller, Not Just the Ingress Object

An Ingress resource is only routing configuration. It does nothing until an ingress controller is running and watching it.

Start with these checks:

kubectl get ingress
kubectl get pods -A | grep ingress
kubectl describe ingress <ingress-name>

If no ingress controller is running, the resource can exist perfectly and still never answer traffic.

A Minimal Working Ingress Example

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

This only says that requests for demo.local should be routed to demo-service. Your Mac still needs to resolve demo.local to the right IP.

MacBook Local DNS Is Often the Missing Piece

On a local machine, demo.local is not automatically meaningful. You usually need to map the hostname manually in /etc/hosts.

For local environments such as Minikube, the target may be the Minikube IP:

minikube ip

Then add an entry such as:

192.168.49.2 demo.local

If your local Kubernetes setup exposes the ingress controller on 127.0.0.1, then map the host there instead. The right address depends on the local cluster implementation.

Minikube-Specific Path

If you are using Minikube, make sure the ingress addon is enabled:

minikube addons enable ingress

Then check the controller pods again. In some local setups, you may also need minikube tunnel or another exposure mechanism depending on how the controller service is published.

The key is that a browser on macOS must be able to reach the ingress controller's actual listening address, not just the cluster-internal service name.

Test Routing Without the Browser First

Before blaming Safari or Chrome, test the route with curl.

curl -H "Host: demo.local" http://192.168.49.2/

If that works, the ingress rule and controller are fine, and the remaining issue is local hostname resolution.

If that fails, inspect the backend service and endpoints:

kubectl get svc
kubectl get endpoints demo-service

An ingress controller cannot route to a service that has no healthy endpoints.

Do Not Skip the Service Layer

Sometimes the ingress rule is fine and the browser host resolves correctly, but the backend Service points to the wrong port or selector. If the service cannot reach pods, the ingress controller has nothing useful to forward traffic to.

Common Pitfalls

The biggest pitfall is thinking the Ingress object itself exposes traffic. It does not. The controller does.

Another issue is forgetting the /etc/hosts mapping on a MacBook for custom local hostnames such as demo.local.

Developers also sometimes test only in the browser without checking curl and kubectl describe ingress. That makes it harder to tell whether the failure is DNS, routing, or backend health.

Finally, remember that local Kubernetes environments differ. Minikube, Docker Desktop, and kind do not always expose ingress traffic the same way, so copy-pasted cloud instructions may not apply directly.

Summary

• Make sure an ingress controller is actually running.
• Verify the ingress resource, service, and endpoints separately.
• On macOS, custom local hostnames usually need an /etc/hosts entry.
• For Minikube, use the Minikube IP and enable the ingress addon.
• Test with curl and a Host header first so you can separate DNS issues from Kubernetes routing issues.