Ingress2Gateway Reaches 1.0 With Support for 30+ Annotations as Kubernetes Teams Race to Migrate Off Retired Ingress-NGINX
SIG Network ships the stable release of its migration tool two weeks before Ingress-NGINX was archived, expanding annotation coverage tenfold and introducing behavioral equivalence testing against live clusters.
Overview
Kubernetes SIG Network released Ingress2Gateway 1.0 on March 20, a stable migration assistant designed to help organizations transition from the retired Ingress-NGINX controller to the Gateway API standard. The tool now supports over 30 common Ingress-NGINX annotations, up from just three in earlier versions, and introduces integration tests that verify behavioral equivalence in live clusters rather than relying on static YAML comparison.
The release arrived just days before the Ingress-NGINX repository was archived to read-only status on March 24, 2026, cutting off all future security patches and bug fixes for the controller that handled roughly half of all Kubernetes ingress traffic. This follows previous reporting on the retirement’s impact and the urgent migration timeline facing cloud-native teams.
What We Know
Ingress2Gateway 1.0 addresses the primary obstacle that had slowed migration planning: annotation translation. According to the official release announcement, the tool now handles over 30 commonly used Ingress-NGINX annotations covering CORS, backend TLS, regex matching, path rewriting, header manipulation, canary deployments, timeouts, and IP allowlists. Previous versions could translate only three annotations, leaving the vast majority of production configurations untouched.
The tool operates through a pluggable emitter architecture, generating output tailored to specific Gateway API implementations. Supported emitters include Envoy Gateway, KGateway, AgentGateway, and Ingress-NGINX itself. Users run ingress2gateway print against their existing manifests or live cluster namespaces, review the generated Gateway API resources, and apply them alongside the existing Ingress configuration for parallel validation.
A key addition in the 1.0 release is the testing methodology. Each supported annotation is backed by controller-level integration tests that spin up both Ingress-NGINX and multiple Gateway API controllers in live clusters, according to the Kubernetes blog. The tests apply Ingress resources, translate them with Ingress2Gateway, then compare actual runtime behavior including routing decisions, redirects, and rewrites. This approach catches edge cases that documentation-based translation would miss.
When the tool encounters annotations it cannot translate, it does not silently drop them. Instead, it identifies untranslatable settings and suggests implementation-specific alternatives, as noted in the release announcement. Annotations such as configuration-snippet and proxy-body-size lack direct Gateway API equivalents, and the tool explicitly flags these gaps.
The retirement of Ingress-NGINX was driven by a combination of security debt and a maintainership gap, as explained by Google’s Open Source Blog. The project’s reliance on raw NGINX configuration injection through annotations created persistent attack surface, and despite serving millions of users, only one or two volunteers maintained the controller. Multiple critical vulnerabilities preceded the shutdown, including CVE-2025-1974, a CRITICAL 9.8-severity unauthenticated remote code execution flaw exploitable via admission webhooks.
What We Don’t Know
No public data exists on how many organizations have completed their migration since the March 24 archival date, or how many remain on the now-unsupported controller. The roughly 50-percent market share figure cited in the original retirement announcement predates the EOL cutoff, and updated adoption numbers have not been published.
It is also unclear how quickly the major cloud providers will drop Ingress-NGINX from their managed Kubernetes distributions. Organizations running the controller in compliance-sensitive environments now face audit findings under SOC 2, PCI-DSS, ISO 27001, and HIPAA frameworks, since end-of-life software in the L7 data path is a recognized risk.
The tool’s annotation coverage, while a tenfold improvement, still leaves some configurations requiring manual intervention. Complex setups using configuration-snippet for custom NGINX directives, ModSecurity rules, or advanced rate limiting will need per-case engineering work that Ingress2Gateway cannot automate.
Analysis
The Gateway API represents a fundamental architectural shift from Ingress’s annotation-driven model to a role-separated design where infrastructure providers, cluster operators, and application developers each control distinct resources. As Google’s Open Source Blog characterized it, Gateway API is effectively “Ingress 2.0,” offering native support for traffic splitting, CORS, timeouts, and multi-protocol routing without the configuration-snippet security risks that plagued its predecessor.
Ingress2Gateway 1.0 lowers the barrier to this transition considerably, but the project’s maintainers are clear that it is a migration assistant, not a one-click replacement. The recommended workflow involves parallel deployment of both Ingress and Gateway API resources, gradual DNS-weighted traffic shifting, and careful validation before decommissioning the old configuration. For organizations that have not yet started planning, the window between comfortable migration and emergency remediation continues to narrow.