Ingress solved routing in 2017 and has been accumulating vendor annotations ever since. Gateway API is the replacement — here's how to move without a traffic incident.
Almost every Ingress resource we inherit has the same tell: a block of controller-specific annotations doing work the spec never described. Rewrite rules, timeouts, auth snippets, canary weights — all encoded as strings that no schema validates and no reviewer can reason about.
Gateway API fixes the root cause. Routing becomes typed resources with real fields, and the split between GatewayClass, Gateway and HTTPRoute maps onto how organisations are actually structured: the platform team owns the listener and its certificates, application teams own their own routes.
How we stage the migration
- Stand up a Gateway alongside existing Ingress — both controllers can serve traffic simultaneously
- Move one low-risk service, and compare response headers and latency against the old path before proceeding
- Translate annotations deliberately: most map to typed fields, and the ones that don't are usually behaviour nobody meant to depend on
- Shift DNS last, so rollback is a DNS change rather than a redeploy
- Delete the Ingress resources only once the Gateway has carried production traffic through a full peak
The part teams underestimate
The technical migration is straightforward. The organisational one is not: Gateway API makes the boundary between platform and application explicit, which surfaces ownership arguments that Ingress annotations let everyone avoid. Have that conversation early — it is the actual work.