- General best practice for Kubernetes clusters is to have a proxy that routes external traffic to internal services

- This is because Kubernetes provides its own internal network space so each of your internal services aren't directly exposed externally (although you can do this if you like)

- Kubernetes has a spec for how this is done, the "ingress" spec

- An ingress controller implements the ingress spec

- The ingress spec is pretty limited in functionality (basic routing, no support for timeouts, as an example)

So if you just need to do basic routing, any ingress controller is going to do the same thing, more or less.

If you want to do more than that (which is very likely), then you'll want to compare the ingress controllers beyond basic ingress. That's where NGINX vs Envoy Proxy vs Traefik etc come into play as your core data plane proxy, and then how much stuff comes on top of it.

Hope that helps.

(Disclosure: I work on Ambassador, one of the Envoy-based ingress controllers)

Edited: formatting

https://medium.com/flant-com/comparing-ingress-controllers-f...

I don't see myself using something like this on a public cloud when I could just use an Ingress Controller offered by the cloud provider unless there are very good reasons for it. Which there might be! Which is what I ask for. :)