Journey from Ingress to Gateway API

• In Kubernetes (K8S), the Ingress resource is one of the standard ways to define routes for external client traffic.

• Kubernetes Ingress has two fundamental problems - its advanced routing logic relies on vendor-specific annotations, locking teams into a single controller, making it annotation hell, and the spec itself has no native support for L4 routing, SSL passthrough, traffic splitting, or header manipulation

• Gateway API is the official next-generation replacement for Kubernetes Ingress. It addresses the limitations of Ingress with strict, type-validated resources (GatewayClass, Gateway, HTTPRoute) and a role-based model that cleanly separates the concerns of infrastructure providers, cluster operators, and application teams, keeping route definitions portable across providers.

This talk walks through the journey of migrating a cluster from Ingress to Gateway API in two parts:    

• Part 1: What Ingress is and its limitations, and how the Gateway API is designed to overcome those limitations.

• Part 2 (Migration case): How we migrated from Ingress-NGINX to Envoy Gateway, covering the before/after configurations, the surprises on a real cluster, and lessons learnt in the migration journey.

Demo
A live migration walkthrough comparing an Ingress resource with annotations against the equivalent Gateway and HTTPRoute objects on a real workload, showing exactly what changes and what you gain.

• Attendees will understand the limitations of Ingress controller and how the Gateway API solves them, giving you a clear picture of both sides and why the switch makes sense.

• Explore the Gateway API provider landscape and get hands-on familiarity with the migration tool - ingress2gateway

• Viewers can see it in action - Walk through real YAML migration examples, from Ingress-Nginx to Envoy Gateway.

• The migration mechanics and trade-offs in this talk apply equally to other compliant providers such as NGINX Gateway Fabric and Istio.