Next-generation Ingress replacement (GA in October 2023, K8s 1.28+). Expressive, extensible, role-oriented API for configuring service networking. Splits configuration into GatewayClass (infrastructure), Gateway (load balancer instance), and HTTPRoute/TCPRoute (routing rules). Vendor-neutral standard implemented by 20+ controllers (Istio, Cilium, Envoy Gateway, NGINX).
Gateway API Vs Ingress FAQ & Answers
12 expert Gateway API Vs Ingress answers researched from official documentation. Every answer cites authoritative sources you can verify.
unknown
12 questionsRole separation: (1) GatewayClass (cluster operator/platform team): infrastructure template defining implementation (Istio, Cilium, etc), (2) Gateway (cluster operator): load balancer instance with listeners and TLS config, (3) HTTPRoute/TCPRoute (application developer): routing rules, traffic splitting, filters. Enables secure multi-tenant delegation.
Beyond Ingress capabilities: (1) Header-based routing (route by user-agent, custom headers), (2) Query parameter matching, (3) HTTP method filtering (GET vs POST), (4) Traffic splitting/weighted routing (canary: 90% stable, 10% canary), (5) Request/response header manipulation, (6) URL rewriting, (7) Request mirroring, (8) Retry policies, (9) Timeout configuration.
HTTPRoute supports weighted traffic distribution via backendRefs. Example: 90% to stable-service (weight: 90), 10% to canary-service (weight: 10). Enables gradual rollouts, A/B testing, blue-green deployments. More declarative than Ingress annotations (which are controller-specific).
HTTPRoute filters enable: (1) RequestHeaderModifier: add/set/remove headers, (2) ResponseHeaderModifier: modify response headers, (3) RequestRedirect: HTTP redirects with status code, (4) URLRewrite: path prefix replacement, (5) RequestMirror: duplicate requests to secondary backend. Standard API vs controller-specific Ingress annotations.
ReferenceGrant resource enables cross-namespace references with explicit permission. Application team grants Gateway in namespace-A permission to route to Services in namespace-B. Prevents unauthorized access. Example: Gateway in 'infra' namespace routes to Services in 'app1', 'app2' namespaces with explicit ReferenceGrant in each.
Enhanced TLS: (1) TLS passthrough (alpha): SNI-based routing without termination, (2) Multiple TLS configs per Gateway (different certs per hostname), (3) TLS version/cipher suite control, (4) Client certificate authentication (mTLS), (5) TLS route specification in TCPRoute/TLSRoute, (6) Certificate references across namespaces (via ReferenceGrant).
Four route types: (1) HTTPRoute (GA): HTTP/HTTPS routing, (2) GRPCRoute (stable): gRPC with method matching and header routing, (3) TCPRoute (alpha): TCP load balancing, (4) TLSRoute (alpha): TLS SNI-based routing with passthrough. UDPRoute experimental. Ingress only supports HTTP/HTTPS.
Rich status conditions on Gateway and HTTPRoute resources. Reports: (1) Accepted/Rejected state with reasons, (2) Programmed (configuration applied to data plane), (3) Per-route parent status (which Gateways accepted route), (4) Conflict detection, (5) ResolvedRefs (backend discovery status). Ingress has minimal status reporting.
Production implementations: Istio (full support), Cilium (service mesh mode), Envoy Gateway (reference implementation), NGINX Gateway Fabric, Kong, Traefik, HAProxy, Google Cloud Load Balancer, AWS Load Balancer Controller. 20+ conformant implementations. Choose based on: feature set, performance, cloud integration, observability needs.
Migrate when: (1) Need advanced routing (headers, query params, traffic splitting), (2) Multi-tenant clusters requiring role separation, (3) Cross-namespace routing with security, (4) Protocol support beyond HTTP/HTTPS (gRPC, TCP, TLS), (5) Portable configs across providers, (6) Rich status reporting. Ingress adequate for: basic host/path routing, single-tenant clusters.
Conformance profiles ensure portability: (1) Core conformance (required): basic Gateway, HTTPRoute functionality, (2) Extended conformance (optional): advanced features like request mirroring, URL rewriting, (3) Implementation-specific features: custom extensions via policy attachment. Check implementation conformance reports before deploying.