I've been using Envoy Gateway in my homelab and have found it to be good for my modest needs (single node k3s cluster running on an old PC). I needed to configure the underlying EnvoyProxy so that it would listen on specific IPs provided by MetalLB, and their docs were good enough to find my way through that.
^ I second Envoy Gateway! It has support for HTTPRoute like all the others, but also TCPRoute, UDPRoute, TLSRoute, GRPCRoute backed by Envoy and they have worked great for me on EKS clusters I manage for work. The migration from Ingress API to Gateway API hasn’t been bad, as you can have both running side-by-side (just not using the same LB) and the EnvoyPatchPolicy has been great for making advanced changes for things not covered by the manifests
But envoy configs are unreadable abominations, why would you choose it? How did you even learn how to configure it? It's documentation is so confusing.
Configuring of the proxy is done by the k8s Gateway controller. Exactly like for the ingress controller. You just use standardized k8s CRDs to configure it.
The gateway/ingress controller takes the k8s resources and configures the proxy server accordingly. In some cases additional config snippets specific to the proxy (nginx, envoy, etc) are required, but it's usually just a few lines.
Which http server is used is not that important (the most common ones are all fine), it's more about how well the integration to k8s works.
Envoy is designed with the intent that a machine is dynamically reconfiguring it at runtime. It is not designed to be configured directly by a human.
The tradeoff is that you can do truly zero downtime configuration changes. Granted, this is important to a very small number of companies, but if it's important to you, Envoy is great.
> Where would one take a machine to dynamically reconfigure envoy? How would one configure it?
When I worked in this area a while back - Ingess Controllers and Ingress / a custom type we made because Ingress was too limited.
We didn't use nginx because it would drop requests and mess up connections during certain config reloads. With a custom controller, Envoy never dropped a connection or request we didn't explicitly tell it to (excepting network reliability of course). For context a slow day for us was many billions of requests.
You don't. Envoy is great if you programmatically configure it, or if you have very small and simple configs. It can't be maintained by a human. But if you have tools that generate it programmatically based on other config, you can read through it.
https://gateway.envoyproxy.io/