Hacker News Reader

Comment by alexellisuk | Hacker News Reader

How does "just using ingress" work on your local cluster with K3d/KinD/minikube/Docker Desktop etc?

There are so many options, and Ingress isn't the answer for those. Ingress isn't a thing that can receive traffic, Ingress Controller is and it - itself has to be exposed somehow, on port 80 and 443.

The lowest common denominator is the one which works everywhere - kubectl port-forward. After that, hobbyists have a propensity for MetalLB, but it's not strictly safe at work with advertising ARP ranges.

I think the takeaway is YMMV. For production, it's of course Ingress Controller plus a cloud-managed LoadBalancer.

View on HN

> How does "just using ingress" work on your local cluster with K3d/KinD/minikube/Docker Desktop etc?

The nginx ingress controller works great when running on a local cluster using KinD and others. You can drop it in and it works, then for the hostname + path combo in your ingress config you can use a combo that produces URLs like `localhost/myapp/test` or `localhost/myapp/prod` to test different app + environment combos if you were using Kustomize or Helm variables. No port forwarding or extra tooling needed.

This lets you keep things fairly simple at the Kubernetes level where all services end up being a ClusterIP type and then you hook up an ingress to the services you want to route traffic to from outside of your cluster.

The same ends up working in production except you'd use your cloud provider's ingress controller instead if they happen to have one (such as the AWS Load Balancer Controller). From your service's point of view nothing changes, the ingress config is also mainly the same except for a few different annotations being set which is easy to account for with Kustomize or Helm. This gives you a consistent interface to your services in any environment.

Even k3s/k3d (I haven't used the others but I assume it's the same) comes with ingress controllers built-in, Traefik in the case of k3s, but it's easy to switch to nginx. So the OP is right, this is unnecessary complexity, and it really is just an ingress, even in a local cluster.

You can launch kind clusters with some nodeports binded to your workstation, they are just docker containers after all.

My favorite way is to use metallb - simply deploy it with the same subnet cidr of your docker kind network and your loadbalancer services will be routable from your workstation

Reply on news.ycombinator.com