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.
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.
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.
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.
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:
GatewayClass for capability definitions, Gateway for instantiations, HTTPRoute for HTTP traffic rules, and more objects for other protocols.
It’s important to note that Ingress is now frozen, and all new features are being added to the Gateway API going forward.
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
We're very excited to announce Kong Mesh 2.12 to the world! Kong Mesh 2.12 delivers two very important features: SPIFFE / SPIRE support, which provides enterprise-class workload identity and trust models for your mesh, as well as a consistent Kuma R
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
In my previous post, we discussed how we can implement a basic AI Agent with Kong AI Gateway. In part two of this series, we're going to review LangGraph fundamentals, rewrite the AI Agent and explore how Kong AI Gateway can be used to protect an LLM
This is part one of a series exploring how Kong AI Gateway can be used in an AI Agent development with LangGraph. The series comprises three parts: Basic ReAct AI Agent with Kong AI Gateway Single LLM ReAct AI Agent with Kong AI Gateway and LangGr
What Is RAG, and Why Should You Use It? RAG (Retrieval-Augmented Generation) is not a new concept in AI, and unsurprisingly, when talking to companies, everyone seems to have their own interpretation of how to implement it. So, let’s start with a r
In February 2024, Kong became the first API platform to launch a dedicated AI gateway, designed to bring production-grade performance, observability, and policy enforcement to GenAI workloads. At its core, Kong’s AI Gateway provides a universal API