Tabs or spaces? Ubuntu or Debian? Now we have Ingress or Gateway.
Platform teams operating Kubernetes clusters and cloud native applications today face a clear fork in the road. For their Ingress and traffic management, should they use products built on the stable Ingress API specification, or should they adopt the new, and developing Gateway API?
The answer to this question depends on your circumstances, goals and requirements. This article aims to provide an unbiased guide to help you make the right decision for your business. Both specifications in the APIs they support are viable, useful, and usable. But the devil is in the details of your specific deployment patterns, goals, and use cases. This is not an either/or situation, as many organizations can benefit from running some applications with the proven Ingress API, while standing up newer applications with the Gateway API.
Organizations with stable and secure production environments might find the Ingress API more suitable for their needs. However, they may also benefit from adopting the newer Gateway API for designing and implementing future projects. Since the Gateway API is still relatively new, it is important to provide the team with the resources and time to become familiar with it – allowing them to build skills, test applications, and plan for future production improvements more effectively.
This guide cuts through the noise and provides objective insights to help you make the decisions for optimizing your Kubernetes traffic management technology and cloud native deployments. Fortunately, unlike tabs or spaces, there doesn’t have to be one right answer.
Ingress and Gateway: API comparison
Ingress API
Ingress is the long-standing Kubernetes API for exposing HTTP/HTTPS from outside the cluster to services. It remains stable at networking.k8s.io/v1, and official docs label it as frozen, indicating that no new features will be added to the API. That said, some vendors continue to add feature enhancements to their own ingress controllers that use the Ingress API.
The Ingress API handles L7 edge routing and requires an Ingress Controller to implement its functionality. It is designed to be minimal and portable, but advanced features like timeouts, URL rewrites, authentication, rate limiting, and canary releases are typically added using controller-specific annotations, which differ across implementations and may affect portability. While Kubernetes RBAC provides access control, the Ingress API itself does not define role boundaries or enforce safeguards across namespaces. Multi-tenancy and security measures are primarily managed through conventions and controller-specific policies.Operationally, the Ingress API remains ubiquitous across clouds and third-party controllers and is perfectly fine for straightforward HTTP(S) front-door routing. Management patterns center on IngressClass selection and per-object annotations, which can make large fleets harder to standardize and audit as observability, logging, and security knobs are often non-portable. The Ingress API also does not natively support non-HTTP protocols like gRPC or UDP. L4 use cases usually require Service types or controller extensions.
Gateway API
The Gateway API is a new, role-oriented family of resources maintained by SIG-Network that separates infrastructure ownership from application routing. Platform teams define GatewayClass (cluster-scoped) and instantiate Gateway with listeners; app teams attach protocol-specific *Route resources such as HTTPRoute and GRPCRoute. The model adds first-class multi-tenancy and scoping with AllowedRoutes (to control which namespaces and kinds can attach) and cross-namespace safety via ReferenceGrant.
For security and management, Gateway API formalizes policy attachment, enabling implementations to expose auth, TLS, rate limit, and logging as structured policies. It also documents an explicit security model for RBAC boundaries across personas. Gateway API reached v1.0 GA in 2023 and has since continued to add features and functionality. (gateway-api.sigs.k8s.io)
The Gateway API supports both L7 and L4, offering TCPRoute, UDPRoute, and TLSRoute as experimental, while HTTPRoute and GRPCRoute are generally available. It includes an official conformance program with profiles and badges to verify feature support across implementations, enhancing portability and observability across vendors. Overall, The API provides you and your team with richer, portable routing capabilities (e.g., header and method matching, traffic splitting, gRPC-aware rules), clear delegation and tenancy controls, and an extensible design using policies. It also improves management by integrating defined personas into the API, aligning RBAC with permissions, and enabling telemetry/security settings to be attached and audited as first-class resources. (gateway-api.sigs.k8s.io)
Choosing the right option for your business
The table below details several use cases to consider when choosing Gateway API or Ingress Controller.
Decision guidelines
Ingress and Gateway APIs are both mature enough to run in production. The real work is matching each to the shape of your traffic and team. For simple front-door HTTP and HTTPS with same-namespace backends, the Ingress API remains a clean default that most engineers already understand. As soon as you need stronger multi-tenant controls and portable advanced routing, Gateway API becomes more suited to these use cases.
Many platform teams will take a mixed model approach-keeping Ingress where it fits and introducing Gateway API where it delivers clear value. Moving existing brownfield applications over from Ingress to Gateway may be time-intensive and require significant modifications to existing infrastructure. If it isn’t broken, you may not want to try to upgrade it.
Lastly, the Kubernetes Ingress API is frozen – no new features or major enhancements are being added to Ingress API. However, this does not mean that vendors have stopped supporting it or that they will stop adding features specific to their implementations. They continue to build useful features on top of Ingress and will likely continue to do so in order to accommodate the use cases of their customers. That said, the Ingress API will no longer change to reflect future requirements, a key consideration for building greenfield applications or when Ingress is lacking a foundational capability that you need.
Start with your workloads
Start by looking at the dominant shape of your workloads. If most services need only host and path routing with TLS, you will move faster by standardizing on Ingress, templating it, and using policy to keep configurations safe. If you run shared edge gateways for many teams and want explicit delegation across namespaces, shift those entry points to the Gateway API and use AllowedRoutes and ReferenceGrant to define who can attach and what they can reference. If your teams require header-level matching, weighted canaries, mirroring, or WebSockets natively, choose the Gateway API. Pick an implementation with published conformance for the features you need. If your roadmap includes alignment with edge and mesh, or adoption of cloud-managed multi-cluster traffic, plan around the Gateway API from the start and follow GAMMA guidance for east-west policy. Finally, be honest about your history. If you have a brownfield platform with years of controller-specific annotations or CRDs, keep those paths on Ingress for now and introduce the Gateway API where the benefits outweigh the translation work.
Clear Use-Case Delineation
When your cluster acts as a straightforward web or microservice front door, the Ingress API is still the right tool. Teams can express host and path rules with TLS in a single object, operations are familiar, and backends remain in the same namespace, which matches common tenancy boundaries. Many controllers supply a handful of advanced behaviors through well-documented annotations or vendor CRDs, and you can standardize those with templates and reviews.
Gateway API fits scenarios where shared infrastructure and portability are important. Platform engineersown GatewayClass and Gateway, while application teams manage their own Routes within limits you define. The API models header matches, rewrites, and filters directly, and treats gRPC as first class. Recent releases brought common features like timeouts, retries, and WebSockets into the standard channel, which reduces the need for one-off annotations. If your organization wants one mental model for edge and mesh, the Gateway API is designed to support that direction. If your use case involves management of L4 traffic, the Gateway API natively supports this through use of both UDPRouteand TCPRoute
Brownfield Reality Check
Brownfield changes are rarely just YAML swaps. Many companies have tuned their Ingress controllers for years with large annotation sets, controller ConfigMaps, custom NGINX templates, or vendor CRDs such as VirtualServer and VirtualServerRoute. These investments work well in place, but do not map one-for-one to all Gateway API resources. Expect to inventory every feature you rely on and classify each item. Some behaviors will be first class in HTTPRoute. Others will require a controller policy attachment. A few may have no exact equivalent and will need redesign.
Operations will also change. The Gateway API formalizes a split between platform ownership of the data plane and application ownership of routes. You will likely introduce admission policies, document who can attach to which listeners, and set a platform contract for certificates, logging, and security settings. Certificate automation also shifts. Cert-manager can issue via Gateway and an HTTP-01 solver that creates temporary HTTPRoutes, but you should validate this early and update runbooks. To reduce surprises, choose an implementation with published conformance results and test the exact profile you plan to use.
The outcome for most brownfield shops is a pragmatic split. Keep Ingress for the mature, customized paths that work today and don’t require huge new feature changes or upgrades. Deploy Gateway API for new services and for the multi-tenant or portability gaps that Ingress cannot address cleanly. For use cases where granular RBACs and controls are key, bias towards Gateway API as for clear managability.
Non-Functional Decision Criteria
Security and isolation should drive the first decision point. If you need explicit, auditable trust across namespaces on shared gateways, Gateway API gives you the controls in the API itself through AllowedRoutes and ReferenceGrant. If single-namespace isolation dominates, Ingress remains simple and safe.
Portability is the next lever. Gateway API reduces the reliance on vendor specific annotations by placing common routing features in portable resources. Its conformance program gives you confidence when picking a controller. Ingress can be portable for basic use, but advanced behavior tends to be vendor specific.
Cloud strategy matters as well. If you want managed multi-cluster or cross-account connectivity, the major clouds are investing in Gateway-aware controllers and data planes. If you plan to stay on-cluster with a single proxy, both models are viable and you can select from open-source implementations that meet your needs.
Team readiness is the final check. Gateway API introduces new roles and objects. If your team is small and your needs are modest, the cognitive load may not be worth it yet. You can adopt Gateway API later when the benefits become clear.
Coexistence and Migration Guidance
You can adopt Gateway API without disturbing what already works. Begin by stabilizing your Ingress usage. Publish which annotations and CRDs are supported, prefer typed CRDs over free-form annotations, and enforce the rules with admission policies. In parallel, stand up a small Gateway. Install the CRDs and a controller, define one GatewayClass and a single Gateway with conservative listeners, and attach a simple HTTPRoute to learn status conditions, metrics, and logs in your environment.
Pilot something that is challenging with Ingress API. Good candidates include cross-namespace delegation, a header-rich routing policy you want to express portably, or a gRPC service that deserves GRPCRoute. Wire in certificate automation with cert-manager’s Gateway support and prove issuance and renewal end to end. Where it helps, use the ingress2gateway tool to convert representative Ingress objects, then review and refine the output to match your ownership and policy model. When you are ready to expand, choose a controller with published conformance that matches your required profile and version.
Bottom Line
Keep Ingress when you have straightforward web entry needs or when your current controller’s annotations and CRDs are delivering real value today. Move to Gateway API when you need explicit multi-tenant controls, portable advanced routing, first-class gRPC or L4, or alignment with mesh and cloud-managed traffic. In brownfield environments, plan for coexistence. Let Ingress continue to serve the customized paths you already trust, and introduce Gateway API where it clearly earns its keep. Tabs or space? Not necessary and no need for strife. Both Ingress and Gateway work great – if you deploy them the right way and understand how they differ.
KubeCon + CloudNativeCon North America 2025 is taking place in Atlanta, Georgia, from November 10 to 13. Register now.
##
ABOUT THE AUTHOR
Shaun O’Donovan, Software Development Engineer III
Shaun O’Donovan has over 8 years of experience in the software industry, with the last 3 years dedicated to the Kubernetes space. Shaun graduated from CIT (now called MTU) with a degree is software development.
