feat: gateway api support #402
Description
Need to make a plan to migrate off of Ingress NGINX as it is EOL in march. Any changes will require provider code changes as the hostname operator will only work with Ingress NGINX
What we need to decide is what to switch too, and i see 2 main options. We can use another ingress controller, HAProxy or similar, or we can use the new official way, gateway API.
| Dimension | HAProxy Ingress Controller | Gateway API (e.g. Envoy Gateway) |
|---|---|---|
| API maturity for raw TCP | Stable (controller-specific, long-standing) | Experimental (TCPRoute / TLSRoute) |
| Upstream API status | Uses stable Kubernetes APIs + HAProxy config | Core Gateway API is GA, but TCP/TLS passthrough is not |
| Raw TCP passthrough by port | Yes (stable) | Yes, but experimental CRDs |
| TLS passthrough (backend certs) | Yes (native L4 mode) | Yes, via experimental routes |
| SNI required | ❌ No | ❌ No (for TCPRoute) |
| Client IP preservation | Yes (can run in transparent mode) | Controller-dependent (often not preserved by default) |
| Drop-in replacement for ingress-nginx tcp: | Very close (port → service:port) | Conceptually similar, but different API model |
| Config model for TCP | ConfigMap or CRDs (controller-specific) | Gateway + TCPRoute resources |
| API churn risk | Low | Medium (experimental routes may change) |
| Long-term Kubernetes direction | Maintenance / traditional | Strategic future direction |
| Operational complexity | Low–Medium | Medium |
| Learning curve | Low (if you know nginx TCP maps) | Medium–High |
| Production risk today | Low | Medium (for TCP passthrough use cases) |