Ingress2Gateway 1.0 turns Ingress migration into a reviewable conversion

Kubernetes SIG Network released Ingress2Gateway 1.0 on March 20, giving platform teams a stable migration assistant for translating Ingress resources into Gateway API manifests. The release announcement frames the tool as a bridge: it converts configuration where it can, and warns when implementation-specific behavior cannot be represented safely.

More Ingress-NGINX behavior is understood

Version 1.0 expands support from three Ingress-NGINX annotations to more than 30. The covered set includes common CORS, backend TLS, regular-expression matching, path-rewrite, and timeout settings. SIG Network says each supported annotation and representative combinations are backed by controller-level integration tests that compare the behavior of the original configuration with the generated Gateway API resources.

The command can read manifests from files, a namespace, or an entire cluster. Its output is YAML, which makes the conversion easy to place in version control and review before any cluster change. That is a useful boundary: generated resources are a starting point for migration, not proof that every controller-specific edge case survived.

Test traffic semantics, not just syntax

Teams should inventory their Ingress classes, annotations, ConfigMaps, snippets, and controller defaults before running the converter. Review every warning, then test routing precedence, redirects, TLS termination, timeouts, and rewritten paths with representative requests. A manifest that applies successfully can still change application behavior.

The 1.0 release makes the mechanical portion of Gateway API migration more repeatable. Its strongest use is in a staged workflow: export, convert, review the diff, exercise traffic tests against a parallel gateway, and only then switch production routes.