DEV Community

Gaberial Sofie
Gaberial Sofie

Posted on

Your Ingress does nothing until you have an Ingress controller (and 3 more local-k8s networking traps)

The single most common local-Kubernetes frustration is "I applied an Ingress and nothing responds." The docs are blunt about why: "You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect."

Takeaways

  • An Ingress manifest is just rules. It needs a running controller (Traefik, NGINX...) that reads them and actually accepts traffic. Which controller serves it is set by ingressClassName.
  • k3d ships Traefik out of the box (k3d is built on k3s), plus a built-in ServiceLB (Klipper) so LoadBalancer services don't hang in pending. But Traefik listens inside the cluster — to reach it from the host you must forward a port at cluster-creation time:
  k3d cluster create dev --api-port 6550 -p "8081:80@loadbalancer" --agents 2
Enter fullscreen mode Exit fullscreen mode

You cannot add this port map to a running cluster. Forgot it? Recreate. This is the #2 pain after "forgot the controller."

  • DNS inside the cluster is by name, not IP (CoreDNS). FQDN pattern: <service>.<namespace>.svc.cluster.local. Short names resolve only within the same namespace via search domains — cross-namespace you need postgres.myapp or the full FQDN.
  • *.localhost is DNS behaving to spec, not k3d magic. RFC 6761 reserves .localhost for loopback. Chrome and Firefox resolve any *.localhost to 127.0.0.1 with zero config — but Safari and non-browser tools (curl, HTTP clients) treat it as an ordinary domain and hit the OS resolver, giving could not resolve host. Fix: add it to /etc/hosts.

The full traffic chain to memorize: curl -> host port 8081 -> Traefik (port 80) -> Service myapp -> Pod.

Full article: https://dorokhovich.com/blog/local-k8s-networking-and-ingress?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-networking-and-ingress

Top comments (0)