The Gateway API has been positioning itself as the successor to Kubernetes Ingress for years. Today, it’s real: the Ingress2Gateway 1.0 tool is officially Generally Available, giving cluster operators a production-ready migration path from the aging Ingress specification to the more powerful Gateway API.
Why This Matters
For WordPress hosts and anyone running modern Kubernetes workloads, Gateway API isn’t just a nicer API—it’s a fundamentally different approach to traffic management. While Ingress controllers shoehorned complex routing logic into annotations, Gateway API separates concerns with distinct resources (Gateway, HTTPRoute, TLSRoute) that mirror how platform and application teams actually work together.
The 1.0 release of Ingress2Gateway represents the Kubernetes project’s confidence that automated migrations are ready for production. The tool reads existing Ingress resources and emits equivalent Gateway API configurations, handling the tedious translation work that previously required manual effort.
What 1.0 Delivers
- Multiple controller support: Handles custom provider-specific annotations from popular controllers like NGINX, Traefik, and HAProxy.
- Namespace-aware conversion: Properly respects Kubernetes RBAC and multi-tenancy patterns.
- Validation-first output: Generated resources pass Gateway API validation before they’re written to the cluster.
- Backward compatibility: Run it in audit mode against existing clusters without committing changes.
The Migration Reality Check
Here’s what “generally available” means in practice: the tool is stable enough that the Kubernetes project will support your migration. The API won’t change out from under you. But it doesn’t mean every edge case is covered—complex rate limiting, custom middleware, and provider-specific extensions still require human review.
The recommended path is gradual: use Ingress2Gateway to generate your new Gateway resources, validate them in a staging environment, then cut over traffic incrementally. The tool can run repeatedly against the same Ingresses to catch drift.
For WordPress Specifically
WordPress on Kubernetes has historically leaned heavily on Ingress controllers. Gateway API’s improved traffic splitting capabilities make blue-green deployments and canary WordPress updates significantly more reliable. The ability to share a single Gateway across multiple Routes simplifies multi-site WordPress architectures where different domains route to different namespace-isolated installations.
Getting Started
ingress2gateway convert -f ingress.yaml --providers=nginx --output=gw.yamlThe project is available via the Kubernetes GitHub org. Documentation covers converting from the major Ingress controller implementations, with specific guidance for handling provider-specific features that don’t map cleanly to Gateway API’s extension points.
Sources
- Kubernetes Blog – Ingress2Gateway 1.0 Release (March 20, 2026)
- Gateway API Documentation – ingress2gateway tool
Migration Timeline Considerations
When planning your Ingress2Gateway migration, several factors should guide your timeline. Organizations with simpler routing needs can typically complete migrations within a few weeks, while those with complex rate limiting rules or custom authentication requirements may need several months of preparation. The key is to avoid treating this as a simple find-and-replace operation.
Start with non-critical workloads to understand the pattern, then gradually move toward your most important traffic paths. The Ingress2Gateway tool supports this incremental approach, allowing you to validate and refine your migration strategy before touching production traffic.
The Road Ahead
Looking forward, the Gateway API ecosystem continues to expand. Support for TLS route delegation, improved backend protocol selection, and enhanced observability hooks are all on the near-term roadmap. For organizations still running legacy Ingress controllers, 1.0 is the signal to start planning your migration—the tooling is ready, the APIs are stable, and the operational benefits are substantial.