Introduction

When we talk about Kubernetes networking, one of the first topics is Ingress. For years, it's been the main method for exposing applications to the outside world. However, if you've used it, you know the challenges: Ingress mainly handles HTTP/S traffic, behaves differently depending on the controller, and becomes limiting when you need advanced routing, multi-tenancy, or support for protocols beyond HTTP.

This is where the Gateway API comes in. Think of it as the next generation of Kubernetes networking—designed to be more flexible, consistent across implementations, and easier for different teams to work with. It supports not just HTTP but also TCP, TLS, and gRPC, offering cleaner ways to manage policies and traffic routing at scale.

Gateway API aims to solve the issues we face with ingress.

What is the Gateway API?

The Gateway API is a set of Kubernetes resources that offer more power and flexibility in managing networking. Instead of relying on rigid configurations, it lets you dynamically set up infrastructure and create advanced traffic routing in a clear and consistent manner.

What makes it unique is its design: it’s extensible, allowing it to grow with your needs; role-oriented, enabling different teams (like platform engineers, infrastructure teams, and app developers) to manage their parts without conflict; and protocol-aware, meaning it works smoothly with HTTP, TCP, TLS, gRPC, and more.

In short, the Gateway API makes exposing and managing network services in Kubernetes smarter, more flexible, and ready for modern workloads.

Gateway API design concepts

The Gateway API was built with a few guiding principles that shape how it works and why it’s more powerful than Ingress:

1. Role-oriented Design: Gateway API kinds are modelled after organizational roles that are responsible for managing Kubernetes service networking:

   • Infrastructure Provider: Manages infrastructure that allows multiple isolated clusters to serve multiple tenants, e.g. a cloud provider.

   • Cluster Operator: Manages clusters and is typically concerned with policies, network access, application permissions, etc.

   • Application Developer: Manages an application running in a cluster and is typically concerned with application-level configuration and service composition.

2. Portable: Gateway API resources are Kubernetes custom resources (CRDs), and they work consistently across different implementations, so you’re not locked into a single vendor.

3. Expressiveness - In addition to HTTP host/path matching and TLS, Gateway API can express capabilities like HTTP header manipulation, traffic weighting & mirroring, TCP/UDP routing, and other capabilities that were only possible in Ingress through custom annotations.

4. Extensible: The API is flexible enough to let you plug in custom resources at different layers, giving you fine-grained control and customization possible at the appropriate places within the API structure.

Key Resources in the Gateway API

Gateway API has three stable API kinds:

• GatewayClass: These are cluster-wide resources that work like templates for networking. They define the behavior and configuration for Gateways created from them. If you’ve used StorageClasses in Kubernetes, it’s a similar concept—only here it’s applied to the networking data plane instead of storage.

A sample GatewayClass CRD:

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

• Gateway: These are the actual instances created from a GatewayClass. You can think of them as the “real” networking components that handle traffic. A Gateway could be an in-cluster proxy, a hardware load balancer, or even a cloud provider’s load balancer. It takes the traffic from outside the cluster. Gateways are attached to respective GatewayClass.

A sample Gateway CRD:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: my-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80

• Routes: which are not a single resource, but represent many different protocol-specific Route resources. The HTTPRoute has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are TCPRoutes, UDPRoutes, TLSRoutes which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.

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

How the Request Flows

Let’s walk through what happens when a request goes through a Gateway acting as a reverse proxy:

• A client tries to reach http://www.example.com.

• The client’s DNS resolver looks up www.example.com and gets back the IP address of the Gateway.

• The client sends the HTTP request to that Gateway IP. The reverse proxy receives it and checks the Host header to find the right configuration defined by the Gateway and its attached HTTPRoute.

• If needed, the proxy can do extra checks like matching headers or paths based on the rules in the HTTPRoute.

• It can also tweak the request, for example by adding or removing headers, using filters defined in the route.

• Finally, the reverse proxy forwards the request to the right backend service(s).

Note: Gateway API is the successor to the Ingress API .However, it does not include the Ingress kind. As a result, a one-time conversion from your existing Ingress resources to Gateway API resources is necessary.

If you are already using ingress then want to use Gateway API, we require migrating Ingress resources to Gateway API resources.

Common Use Cases for Gateway API:

1. Multi-tenant clusters : Perfect for environments where multiple teams share the same cluster but still need isolation and clear boundaries.

2. Progressive delivery : Enables deployment strategies like canary releases or blue/green rollouts, making it easier to test changes safely before full rollout.

3. Beyond HTTP : Unlike traditional Ingress, Gateway API supports other protocols like TCP, gRPC, and WebSockets. also,making it a versatile choice for modern applications.

Final Thoughts:

Kubernetes has made deploying and scaling applications much easier, but networking has always been one of its tougher challenges. Ingress did the job for simple scenarios, but as apps, teams, and protocols grew more complex, its limits quickly showed.

That’s where the Gateway API comes in. It’s the next generation of Kubernetes networking-flexible, extensible, and designed for today’s workloads. With role-based design, multi-protocol support, and consistency across implementations, it brings infrastructure providers, operators, and developers onto the same page.

Whether you’re just starting with Kubernetes or planning for the future, Gateway API is more than just an upgrade to Ingress-it’s the new foundation for Kubernetes networking.