Kubernetes Gateway API
Introduction
As Kubernetes has become the standard 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.
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
Gateway API is an official Kubernetes project focused on L4 and L7 routing in Kubernetes. This project represents the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs. From the outset, it has been designed to be generic, expressive, and role-oriented.
Kubernetes Gateway API is introduced to solve some pressing challenges with native Kubernetes Ingress:
- Limited functionality: Native K8s Ingress only provides basic load-balancing functionality. Advanced traffic routing capabilities, such as path-based routing, require DevOps folks to configure tedious custom annotations provided by their respective Ingress controller.
- Lack of standardization: Vendors providing Ingress controllers have their own annotation specifications. If DevOps has to switch Ingress controllers, they have a learning curve regarding vendor-specific CRDs and annotations. Besides, they will have to rewrite the current vendor’s specifications using the new ones. It takes a reasonable amount of time to write and test annotations before they can be implemented.
- Single Ingress resource: Usually, in an enterprise, there will be a single Ingress resource, and multiple teams will work on it. An admin will create multiple Ingress objects for various app teams at max, but it is still hard to implement role-based access controls on any object. If proper RBAC policies are not in place, teams may mess up the route configuration. Gateway API not only solves the challenges at the Gateway/Ingress-level, it could also evolve to manage service-to-service/east-west traffic within the same cluster.
Gateway API is Role-Oriented
In the original design of Kubernetes, Ingress and Service resources were based on a usage model in which the developers who create Services and Ingresses controlled all aspects of defining and exposing their applications to their users.
In practice, though, clusters and their infrastructure tend to be shared, which the original Ingress model doesn’t capture very well. A critical factor is that when infrastructure is shared, not everyone using the infrastructure has the same concerns, and to be successful, an infrastructure project needs to address the needs of all the users.
This raises a fundamental challenge: how do you provide the flexibility needed by the users of the infrastructure, while also maintaining control by the owners of the infrastructure?
Gateway API defines several distinct roles, each with an associated persona, as a tool for surfacing and discussing the differing needs of different users in order to balance usability, flexibility, and control. Design work within Gateway API is deliberately cast in terms of these personas.
Gateway API defines three roles and personas:
Infrastructure provider, responsible for the care and feeding of a set of infrastructure that permits multiple isolated clusters to serve multiple tenants.
Cluster operator, responsible for managing clusters to ensure that they meet the needs of their several users. He will typically be concerned with policies, network access, application permissions, etc.
Application developer, responsible for creating and managing an application running in a cluster. From Gateway API’s point of view, He will need to manage configuration (e.g. timeouts, request matching/filter) and Service composition (e.g. path routing to backends).
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.
