Introduction to the Gateway API: Revolutionizing Kubernetes Networking

Image source: Google Open Source Blog

As Kubernetes continues to evolve, so do the networking challenges that come with managing complex, distributed microservices at scale. Traditional tools like the Ingress API have long been the backbone for exposing services to external traffic, but as environments grow more sophisticated, developers and operators are looking for greater flexibility, extensibility, and fine-grained control over network traffic.

In this article, we’ll dive deep into what the Gateway API is, why it was developed, and how it’s set to transform the way we handle networking in Kubernetes.

The Evolution of Kubernetes Networking

Earlier, the Ingress resource was introduced as a way to manage external access to services in a cluster. While Ingress served its purpose, it had limitations:

1. Limited support for complex routing scenarios
2. Lack of support for non-HTTP protocols
3. Difficulty in extending functionality across different implementations

Enter the Gateway API

Recognizing these challenges, the Kubernetes community began work on the Gateway API in 2019. The Gateway API was designed to address the limitations of Ingress while providing a more flexible, extensible, and powerful way to manage traffic routing in Kubernetes.

Key features of the Gateway API include:

1. Improved Resource Model: The API introduces new custom resources like GatewayClass, Gateway, and Route (HTTPRoute, TCPRoute, etc.), providing a more granular and expressive way to define routing rules.
2. Protocol Agnostic: Unlike Ingress, which was primarily designed for HTTP, the Gateway API supports multiple protocols, including TCP, UDP, and TLS.
3. Enhanced Security: Built-in support for TLS configuration and more granular access control.
4. Cross-Namespace Support: Ability to route traffic to services in different namespaces, enabling more flexible architectures.
5. Extensibility: The API is designed to be easily extended with custom resources and policies.
6. Role-Oriented: Clear separation of concerns between cluster operators, application developers, and security teams.
   This is probably one of the most interesting features of Gateway API in my humble opinion.

If you notice, the Gateway API Logo illustrates the dual purpose of this API, enabling routing for both North-South (Ingress) and East-West (Mesh) traffic to share the same configuration🤓

Gateway API vs. API Gateway

One of the first questions that came to my mind when I started exploring the Kubernetes Gateway API was, “How is it different from an API Gateway?” I figured you might have the same question too!😃

While both concepts involve routing and managing traffic, they serve very different purposes.

1. What is Kubernetes Gateway API?

The Kubernetes Gateway API is a networking API that extends and improves upon the traditional Ingress API in Kubernetes.

It is primarily focused on managing traffic to services running inside a Kubernetes cluster.

The Gateway API is built with flexibility and extensibility in mind, allowing for more complex traffic management scenarios like handling HTTP, TCP, and other protocols, as well as north-south (external to internal) and east-west (internal to internal) traffic.

Key points about the Gateway API:

• Works at Layer 4 (Transport) and Layer 7 (Application) of the OSI model: It can manage different protocols like HTTP, TCP, and UDP.
• Integrated with Kubernetes: It is part of the Kubernetes ecosystem.
• Flexible routing: It allows more advanced routing configurations than the traditional Ingress API, such as weighted routing, traffic splitting, and multi-protocol support.
• Multiple resource types: It uses resources like Gateway, HTTPRoute, TCPRoute, TLSRoute, and GatewayClass to provide granular control over how traffic is handled.

Use Case:

The Gateway API is ideal for managing traffic to and from applications running within a Kubernetes cluster, handling both north-south traffic (external to the cluster) and east-west traffic (internal service-to-service communication).

2. What is an API Gateway?

An API Gateway is a specific type of application-level service that sits between external clients (such as mobile apps, browsers, or external APIs) and backend microservices or APIs.

Its primary purpose is to manage and orchestrate API traffic by acting as a single entry point for all client requests.

An API Gateway includes additional features beyond simple traffic routing, such as authentication, rate limiting, caching, load balancing, logging, and monitoring.

Key points about an API Gateway:

• Focused on APIs: It primarily deals with traffic related to API calls (Application Layer — Layer 7 of the OSI model).
• Manages API requests: It acts as a single entry point for API consumers and can proxy requests to different backend services based on the API routes.
• Additional features: API Gateways often include security (authentication, authorization), traffic management (rate limiting, throttling), caching, and monitoring.
• Not tied to Kubernetes: API Gateways can be used in any environment (cloud, on-premise, or hybrid) and aren’t limited to Kubernetes clusters.

Use Case:

API Gateways are commonly used in microservice architectures to simplify client access and add additional layers of security and management for API calls.

I’ll break down the key differences:

Core Components of the Gateway API

Here are the main components of the Gateway API and their roles:

1. GatewayClass

• What It Is: Similar to how a StorageClass defines different types of storage, a GatewayClass defines how networking infrastructure (like load balancers, proxies, etc.) is provisioned and managed.
• Role: It represents the overall configuration of a “type” of Gateway and is used by an administrator to define specific implementation details for that Gateway. It abstracts the specific network configuration like whether the load balancer is cloud-based, on-premises, or a service mesh.
• Practical Use: When creating a Gateway, we must specify the GatewayClass as we want the Gateway to use.
  It’s typically provided by a specific Cloud vendor or tool, such as Istio (e.g., istio.io/gateway-controller), GCP (e.g., networking.gke.io/gateway-controller), AWS Load Balancer Controller (e.g., aws.example.com/gateway-controller), or NGINX Ingress Controller (e.g., k8s.io/ingress-nginx), etc.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: my-cloud-gatewayclass
spec:
  controllerName: example.com/cloud-lb-controller

2. Gateway

• What It Is: The Gateway resource describes the specific details of the networking infrastructure being used, such as the ports it listens on and the protocol it supports.
• Role: It serves as the logical entry point for traffic into the cluster. Gateways can listen for HTTP(S), TCP, UDP, and other protocols. It binds to a specific GatewayClass, which dictates the underlying infrastructure (e.g., load balancer, reverse proxy).
• Practical Use: The Gateway can specify one or more listeners (for different protocols like HTTP or HTTPS) and act as a load balancer, receiving external traffic and directing it based on rules defined in HTTPRoute, TCPRoute, etc.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-example-gateway
spec:
  gatewayClassName: my-cloud-gatewayclass
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces: 
        from: All

3. Route Resources

Routes are the rules that define how traffic is routed to backend services once it enters through a Gateway. They allow for complex traffic routing and splitting logic.

For more detailed information, please refer to the official Gateway API documentation here.

4. ParentRef

The parentRef field is used in route resources (such as HTTPRoute, TCPRoute) to reference a parent Gateway that will be handling the traffic.

It allows the Route resource to declare its relationship with the Gateway, and ensures that only allowed Gateways can be referenced by the Route resource, maintaining security and order in multi-tenant setups.

The Gateway resource may allow or disallow specific routes, and routes can reference multiple Gateways.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-example-http-route
spec:
  parentRefs:
  - name: my-example-gateway

5. Listeners

The Listener is a component of the Gateway that defines how traffic is accepted on a specific port and protocol.

Each Gateway has one or more listeners that define which ports, protocols, and types of traffic (HTTP, HTTPS, TCP, etc.) the Gateway will accept and how it should route that traffic.

For example, we could define both HTTP (port 80) and HTTPS (port 443) listeners on the same Gateway to handle both encrypted and unencrypted traffic.

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

6. BackendRefs

Backend references specify the backend services that should handle the traffic after being processed by the Gateway.

They are defined in the routing resources like HTTPRoute, TCPRoute, etc. and point to Kubernetes services.

BackendRefs allow you to send traffic to one or more services with specific rules or balancing methods (e.g., round-robin, weighted).

backendRefs:
- name: app-service
  port: 80
  weight: 80
- name: another-service
  port: 80
  weight: 20

Conclusion

Now that we’ve explored the foundational concepts of the Kubernetes Gateway API — from its key features and advantages over the traditional Ingress API to its core components, I would like to dive into a practical implementation to illustrate the full power of the Gateway API.

We’ll demonstrate how different personas — how different personas — Infrastructure Providers, Cluster Operators, and Application Developers — can collaborate to manage traffic routing in a real-world scenario.
We’ll highlight how the Gateway API works in conjunction with a Service Mesh to manage both external (north-south) and internal (east-west) traffic, showcasing how these roles come together to build a secure, flexible, and scalable traffic control system🚀