Kubernetes Gateway API: Next-Gen Ingress for Cloud Native Apps

Kubernetes has traditionally provided ways to expose services via NodePort, LoadBalancer, or Ingress. NodePort opens a static port on each node; LoadBalancer provisions an external IP for a single service. That can get quite wasteful when many services need external access. To solve that, Ingress allows you to share a single gateway - for example, a cloud LB or NGINX - and route HTTP(s) traffic by host/path rules.

However, the Ingress API in its classic form is somewhat limited-it only supports HTTP/HTTPS and basic rules; extra features depend on non-standard annotations. As one CNCF guide puts it, Ingress "has significant limitations" for complex apps: it's stuck on layer-7 HTTP(s) only, without built-in advanced routing like traffic splitting and header rules, and relies on controller-specific annotations that aren't portable. That is, in real-world scenarios, cluster operators juggle several controllers - NGINX, Traefik, Istio Gateway among others - or add a service mesh just to get features beyond vanilla Ingress.

The Gateway API is a new Kubernetes standard, graduated in 2023, designed to address these gaps. It offers a richer, more flexible way to configure the routing in and out of a cluster. The core idea is a family of CRDs-GatewayClass, Gateway, and route types, such as HTTPRoute, TCPRoute, TLSRoute, GRPCRoute, etc.-which give fine-grained control over traffic. Gateway API is role-oriented and extensible, meaning cluster admins, platform engineers, and app developers each manage the pieces they own.

For example, infra teams create a Gateway with TLS, IPs and listeners using a GatewayClass while app teams create HTTPRoute objects that attach to that Gateway and define path/host rules. This separation of concerns is a major improvement over Ingress’s single-persona model.

Gateway API also natively supports multiple protocols (not just HTTP). You can define TCPRoute or GRPCRoute alongside HTTPRoute, so a single Gateway can route L4/TCP traffic or gRPC in addition to HTTP. This avoids awkward workarounds (like running a separate Service for non-HTTP) In short, the Gateway API is a superset of Ingress functionality with more power and flexibility.

Why Gateway API? The trouble with Ingress

Ingress in Kubernetes was a good start, but it has some obvious disadvantages;

1. Scope is limited: Ingress only handles HTTP and HTTPS. For other protocols, such as TCP, UDP, or gRPC, you are adding extra Services or a sidecar proxy. Gateway API allows TCPRoute or GRPCRoute, so a single gateway can handle multi‑protocol ingress natively.

2. Features are basic: Standard Ingress does host/path matching and TLS termination. More advanced capabilities—rate limiting, traffic splitting, header-driven routing, retries, and so on—usually required controller-specific annotations. Gateway API folds more features into the API itself—for example, header matches and traffic weights.

3. Poor extensibility: With Ingress, every controller had its own annotations and CRDs. That meant moving to a new controller required rewriting configs. The Gateway API uses a consistent spec, so rules and filters are more portable across implementations

4. No built-in multi-tenancy model: Ingress exposes everything to a single user persona, which is rather risky on shared clusters. Gateway API clearly separates roles, where infrastructure providers and cluster operators define the Gateways, or the entry points, whereas application owners define only Routes that attach to those Gateways. Teams can share a common gateway with central policies-like TLS certificates-while keeping app-specific routing in their own namespaces.

5. No cross‑namespace support: Ingress routes must target Services in their own namespace. Gateway API allows an HTTPRoute in one namespace to point to a Gateway in another using parentRefs and, if needed, ReferenceGrant objects. This enables controlled, cluster-wide gateway sharing.

Overall, the Gateway API is “a more flexible and extensible solution to address the gaps in the Ingress model. It’s designed as a unified, Kubernetes-native framework for all ingress/egress routing, with built-in support for advanced traffic management, security, and multi-tenancy.

Core Concepts: GatewayClass, Gateway, HTTPRoute, etc.

The Gateway API introduces several new resource kinds:

• GatewayClass: Consider this as the template or “blueprint” for the Gateways in the cluster. The GatewayClass defines what controller will manage Gateways of this class via spec.controllerName, optionally including default configuration. For example, an ops team would create a GatewayClass named my-cloud-gw which points to the company's cloud-controller. Any Gateway using that class will be managed by that controller

• Gateway: This is the real entry-point resource. A Gateway is like an Ingress, but with concrete details: it has listeners (ports and protocols) and refers to a GatewayClass. When a Gateway is created, the controller provisions load balancers or proxies as necessary. For instance, you might define a Gateway that listens on port 80 (HTTP) and port 443 (HTTPS) using the my-cloud-gw class, and it may be assigned an external IP address. The Gateway resource is under the control of platform/infrastructure teams.

• Route (HTTPRoute, TCPRoute, TLSRoute, GRPCRoute, etc.): These define how traffic from a Gateway listener is routed to backend services. An HTTPRoute attaches to one or more Gateways (via parentRefs), and declares rules like hostnames, path matches, header matches and where to send matching traffic (which Service and port). TCPRoute is similar but for raw TCP port routing; TLSRoute for SNI-based TLS passthrough; GRPCRoute for gRPC, and so on. Each Route lives in a namespace (often the app's namespace), and the controller merges all applicable Routes into the Gateway's configuration. In this way many apps can share one Gateway resource.

These critically separate responsibilities: cluster or platform teams define GatewayClasses and Gateways-defining entry points, TLS certs, etc.-while app teams define HTTPRoutes-defining the routing logic-that attach to those Gateways. gateway-api.sigs.k8s.io tigera.io This would mean, for instance, the infra team can enforce a corporate TLS certificate on the Gateway and the app teams can only attach to it without touching the certificate. The Kubernetes SIG Network points out that this is aligned with real org structures, letting "multiple, potentially non-coordinated teams" share infrastructure effectively.

Route delegation is an advanced Gateway API feature that lets one HTTPRoute hand off some traffic to another HTTPRoute. In practice, you might have a “parent” route matching a broad host/path prefix that then delegates finer-grained sub-paths to child routes owned by different teams. This breaks up a big routing table into smaller pieces and lets each team manage its own sub-routes. Delegation is useful in complex orgs: e.g. parent-route matches /app/* and delegates /app/foo to one team’s route and /app/bar to another’s. This limits blast radius and keeps each team’s routes.

Real-World Scenarios

North-South Ingress for Multiple Teams

Suppose a SaaS cluster hosts two independent webapps, store and site, operated by different teams. The cluster operator, the platform team, creates in the cluster a Gateway resource with HTTPS port 443 using a shared certificate. They use a GatewayClass, basic-gateway-class that instructs the cloud LB controller how to provision an external load balancer. The applications' devs create in their namespace each an HTTPRoute: one matches store.example.com paths to the store Service, the other matches site.example.com to the site Service. Both HTTPRoutes point to the same Gateway. The effect is: both applications share one entry point - and certificate - without interfering because the platform team operates the Gateway, and application teams operate their routes. This centralizes policies (TLS, security) while isolating routing logic per app.

Shared Gateway, Multiple Apps (Separation of Concerns)

In the same vein, suppose three teams deploy microservices. Instead of each team creating its own LoadBalancer Service, the cluster has one Gateway in a “shared-gateway” namespace. Each team defines an HTTPRoute in its own namespace, attaching to shared-gateway, and matches only the paths/hosts it needs. The gateway listens on common ports 80/443. Now ops can enforce things like IP whitelisting or mTLS on the Gateway, while teams only touch their routes. This multi-tenancy model is a core design goal.

All of its contributors are professional, independent experts with extensive first-hand experience in the field.

Multi-Protocol Services

An online gaming app might need both HTTP (for the web UI) and a TCP port (for game data). With Ingress, you’d need a hack (e.g. an Ingress plus a separate Service: NodePort for the TCP) or a full Nginx TCP proxy. With Gateway API, you can add a second listener on the same Gateway: one listener with protocol: HTTP on port 80, another with protocol: TCP on port 25565, for example. You’d then define one HTTPRoute for the UI and one TCPRoute pointing to the game server Service. No annotations or workarounds needed – the Gateway handles both protocols natively.

East-West (Service Mesh) Integration

Gateway API also supports internal (“east-west”) traffic. The GAMMA initiative extends Gateway API to service meshes. For instance, Istio’s implementation supports GRPCRoute and internal routing. In one scenario, a service running inside a mesh needs strict URL path validation and timeouts. A developer can write an HTTPRoute (without needing platform help) that the mesh control plane enforces on internal calls. This lets app teams use Gateway API policies inside the cluster without complex Istio configs.

YAML Examples

Below are simple, illustrative YAML snippets. These omit some fields for brevity, but show the key ideas. In practice, you would customize names, namespaces, and selectors as needed.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-class
spec:
  controllerName: example.com/gateway-controller

This GatewayClass named example-class tells Kubernetes that any Gateway using this class will be managed by the controller example.com/gateway-controllertigera.io. In a real setup, the controller name might be something like istio.io/gateway-controller or acme.com/aws-gateway, depending on your ingress provider. Only admins or ops teams typically create GatewayClasses.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert

This Gateway named example-gateway uses the class example-class and defines two listeners. It listens for plain HTTP on port 80 and HTTPS on port 443 (terminating TLS with the Kubernetes Secret my-cert). When this Gateway is created, the controller will provision network routes (e.g. assign an IP or create a load balancer) so external clients can reach it. The listeners specify how traffic is accepted; routing rules come from attached Route objects.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
  namespace: app-namespace
spec:
  parentRefs:
  - name: example-gateway
    namespace: default
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

This HTTPRoute in namespace app-namespace attaches to the example-gateway (which is in the default namespace). It matches requests with hostname www.example.com and paths starting with /login, and forwards them to the Service example-svc on port 8080. Multiple rules and matches can be combined here (paths, headers, etc.), and you could add more backendRefs for traffic splitting. The key is the parentRefs field: it binds this route to the given Gateway listener, so the controller knows where to apply it.

Comparison with Other Options

• Ingress vs Gateway API: Both manage HTTP(s) traffic, but Gateway API is a superset. Ingress requires a controller (NGINX, Traefik, etc.) and uses annotations for anything advanced. Gateway API is an official Kubernetes API with first-class fields for routing features, and it supports more protocols. . Gateway API resources can do everything Ingress can do (HTTP routing, TLS) and much more (e.g. TCP, traffic weighting, cross-namespace rules) in a consistent way.

• Service Type LoadBalancer: Traditionally, you might give each Service its own cloud load balancer. Gateway API lets you consolidate. Instead of dozens of LBs, you have one Gateway (with possibly one external IP) that handles many services via routes. This is more cost-efficient and centralizes global policies (like WAFs or VPC attachments).

• NodePort: NodePort is very low-level and rarely used in production. Gateway API replaces the need to expose every app via NodePort, since the Gateway (backed by a cloud LB or ingress controller) is the new entry point.

• API Gateways (Kong, AWS API Gateway): Those are higher-level products (often SaaS) focused on API management (auth, developer portals, etc.). Gateway API is in-cluster and purely about routing/connectivity. That said, projects like Kong support the Gateway API – Kong’s Ingress Controller and Gateway Operator can manage Gateway/HTTPRoute objects as part of its setup. Similarly, cloud providers (AWS and GCP) have native Gateway API controllers: AWS’s Gateway API Controller uses Amazon VPC Lattice to provision gateways, and GKE’s Gateway controller provisions Cloud Load Balancers for pods. So you can integrate Gateway API with major environments in a vendor-neutral way.

• Service Mesh Gateways (Istio, Envoy Gateway): Istio and other meshes have their own “Gateway” abstractions (usually custom CRDs). Gateway API provides a common contract. For example, Istio’s v1.18+ fully supports the Gateway API for north/south traffic and integrates GAMMA for east/west . This means you could write standard Gateway API objects and let Istio implement them, instead of writing Istio-specific Gateway and VirtualService configs.

Implementations and Ecosystem

The Gateway API is just a specification; you need a controller (a “data plane”) that implements it. Good news: many are available. Some popular choices:

Contour: A CNCF project (Envoy-based) that fully implements Gateway API v1.2.1. Contour supports the core resources (GatewayClass, Gateway, HTTPRoute) and many extended ones (TLSRoute, TCPRoute, GRPCRoute)

Istio (or Envoy Gateway): Istio, the service mesh, can act as a Gateway API controller. A minimal Istio install provides full v1 Gateway API support for ingress. Istio also supports the GAMMA spec for east-west routing, letting you use Gateway API for internal service-to-service traffic

AWS/GCP Managed: Cloud vendors have their own. On GKE, there’s the GKE Gateway controller (built-in) which provisions Google Cloud Load Balancers for Pods. On EKS, Amazon provides the AWS Gateway API Controller (using VPC Lattice) to route services. These let you use the native Kubernetes API and get cloud LBs without annotation hacks. This is useful if you want Kong’s features (analytics, auth plugins) while still defining routes via standard CRDs.

Others: Many other routers support Gateway API, including Envoy Gateway, Contour, HAProxy’s newer controllers, Cilium’s service mesh, and more….

Conclusion: It keeps the best parts of Ingress (declarative HTTP routing) but fixes its shortcomings by adding multi-protocol support, richer routing primitives, and a clear separation of concerns between infrastructure and application teams. In practice, it means platform operators can manage Gateways and policies centrally, while developers safely self-service their routing via HTTPRoute, TCPRoute, etc. The result is a more scalable, maintainable way to handle ingress (and even service mesh) traffic.

Sources: Official Kubernetes Gateway API guides.