Gateway API vs Ingress: The Future of Kubernetes Networking

As Kubernetes has become the de facto orchestration platform for deploying cloud native applications, networking and traffic management have emerged as pivotal challenges when managing access to services and infrastructure. The core Kubernetes Ingress resource addresses basic Layer 7 (L7) routing needs but has limitations in terms of flexibility, functionality, and standardization. As a successor to Ingress, the Gateway API project introduces a new set of portable network management resources as an evolution beyond traditional Ingress capabilities.

This article will explain the key differences between Kubernetes Ingress and the emerging Gateway API standard, including the limitations of Ingress and how Gateway API aims to solve them. For those using Ingress today or seeking more advanced traffic management controls, understanding these contrasts and the motivations behind Gateway API provides valuable insight into the future of Kubernetes networking.

What is Ingress in Kubernetes?

Ingress provides a centralized way to manage external access to services running inside a Kubernetes cluster, typically HTTP/HTTPS traffic at the L7 layer. Instead of individual load balancers per service, Ingress provides a centralized mechanism to manage all inbound requests to backend applications.

The Ingress resource defines routing rules that govern how external requests get directed to Kubernetes services. Rules can include hostnames, paths, and TLS configurations used to map traffic. An Ingress controller is responsible for ultimately applying routing configurations described via Ingress resources to some data plane (e.g., a reverse proxy, a load balancer, etc.) to serve the traffic.

​​Many organizations with capabilities in developing traditional Layer 7 proxy software supply their own ingress controller implementations, leveraging their expertise to translate Ingress resources into proxy server configurations tailored for the Kubernetes ecosystem.

Ingress abstracts a key component of service networking, allowing Kubernetes teams to simplify external access management. Specifying desired routing at the Ingress level keeps individual services decoupled from external dependencies. Ingress centralizes control so services focus on application delivery rather than networking detail.

Limitations of Ingress

While Ingress Controllers solve important networking and traffic management needs in Kubernetes clusters, the Ingress resource itself has some limitations stemming from its lack of standardization across different controller implementations.

The main limitation of Ingress is that it only works at Layer 7, specifically optimizing for HTTP and HTTPS traffic. Other L7 protocols (like gRPC) and non-L7 protocols (like TCP and UDP) must be handled using custom controller extensions rather than native Ingress capabilities. This leads to fragmentation, as enabling features like authentication, rate limiting policies, and advanced traffic management rely on vendor or platform-specific custom annotations. For example, NGINX Ingress Controllers use a different syntax and set of extensions compared to HAProxy Ingress implementations.

In addition, the core Ingress specification lacks built-in support for many advanced traffic management features needed in production scenarios. As a result, solutions for use cases like A/B testing, canary rollouts, distributed tracing, and more end up vendor-locked rather than portable. The Ingress resource itself focuses narrowly on exposing HTTP routes, while critical network functions rely on the underlying Ingress Controller. This requires configuring the controller separately from the Ingress to achieve production-grade capabilities.

Introducing Gateway API in Kubernetes 

To solve the limitations around Kubernetes Ingress, the Gateway API project was created as an evolving standard to unify capabilities across different Ingress Controllers. 

Gateway API defines a common set of Kubernetes resource objects and usage patterns that all compliant gateways must support. This introduces portability, enabling users to switch between commercial or open-source implementations, across both on-prem and cloud, with reduced migration costs.

Gateway API supports both L4 and L7 protocols including TCP, UDP, HTTP, gRPC, and more are under consideration. This expands its scope beyond just HTTP traffic. Gateway API also introduces new controller objects like GatewayClass for defining controller capabilities, Gateway for instantiating network gateways with those capabilities, and HTTPRoute for declaring HTTP routes (a direct alternative to the Ingress resource). In the future, additional specified objects will emerge covering newer protocols.

These new objects enable capabilities that are not possible purely through Ingress resources. For example, gateway routes support advanced pattern matching and filtering on arbitrary headers as well as paths to precisely control traffic, which facilitates use cases like canary rollouts. Gateways also enable built-in support for critical features like request mirroring, direct response injection, and fine-grained traffic metrics. Vendors no longer need to create custom extensions and annotations to realize these extended capabilities.

Overall, Gateways define a whole new way of declaring and managing traffic targeting Kubernetes services that avoids the limitations teams experience using only Ingress resources. The Gateway API creates a standardized model for enabling features like L4 support, advanced HTTP routing, and built-in traffic management in a portable fashion across all compliant gateway controllers. This will prevent vendor lock-in and give developers expanded declarative management without having to touch low-level controller configurations. 

As of now, only GatewayClass, Gateway, and HTTPRoute are GA. L4 support is still considered alpha and could evolve to either graduate or be deprecated based on community needs and project support. 

Key differences

With Ingress focused narrowly on HTTP traffic and Gateway API introducing a new model for managing all internal cluster traffic, there are significant differences between these Kubernetes networking approaches:

• Protocol support: Ingress only works for Layer 7 protocols like HTTP and HTTPS. Non-L7 support requires custom controller extensions. Gateway API supports both L4 protocols such as TCP and UDP as well as L7 protocols like HTTP natively within the specification.
• Traffic management: Ingress has limited built-in capabilities for advanced traffic management like A/B testing or request mirroring. These require vendor extensions and customization. Gateway API offers built-in support for traffic splitting, mirroring, injections, and fine-grained metrics.
• Portability: Ingress definitions rely on vendor specifics, with each implementation having its own syntax and capabilities around extensions. Gateway API establishes a common standard that works consistently across all compliant controller implementations.
• Resource object definitions: No new resource objects are introduced in the Ingress specification. Gateway API introduces GatewayClass for capability definitions, Gateway for instantiations, HTTPRoute for HTTP traffic rules, and more objects for other protocols.
• Routing customization: Ingress only supports path or host-based routing rules. Gateway API enables route customization based on arbitrary header fields as well as paths and hosts.
• Extending capabilities: Adding capabilities like authentication policies or rate limiting to Ingress requires vendor-specific custom annotations and extensions. These features come built-in with Gateway API as part of the overall specification.

It’s important to note that Ingress is now frozen, and all new features are being added to the Gateway API going forward.

The future of Gateway API

The Gateway API specification aims to standardize and expand upon the baseline traffic management capabilities available through Kubernetes Ingress. It introduces a common set of objects and definitions for consistently enabling both L4 and L7 protocol support, advanced traffic control features, expanded rule customization based on headers, and more. This provides greater portability for use cases like service mesh across different Ingress Controller platforms, both cloud and on-prem. 

The Gateway API will complement existing Ingress Controllers rather than replace them. Ingress Controllers that traditionally implemented Ingress may also now implement Gateway API. Over time, Gateway API will replace vendor-specific Ingress implementations as it matures. Teams can now choose between basic yet fragmented Ingress functionality or adopt Gateway API for production scale needs around multi-protocol support, portable advanced traffic management, and next-generation infrastructure across public and private environments.

Want to see the difference between Ingress and Gateway API? Check out our Tech Talk where we demo a real-world example with Kong Ingress Controller. 

Continued Learning & Related Content

• What is Kubernetes Ingress?
• What is Kubernetes Ingress Controller?
• Gateway to the Future: A Brief History of Kubernetes Ingress

• The Difference Between API Gateways and Kubernetes Ingress
• Enhancing APIOps with decK for Kong Ingress Controller Users

• Managing Docker Apps With Kubernetes Ingress Controller
• Guide to Understanding Kubernetes Deployments