Kubernetes Gateway API

Traffic management in Kubernetes can be complex, especially with modern applications composed of multiple services like frontends, APIs, and backends spread across hybrid and multi-cloud environments. As these environments grow, ensuring secure, efficient, and reliable communication between services becomes increasingly difficult.

Traditional approaches often involve combining tools like Ingress for routing, NGINX for load balancing, and NetworkPolicies for security. While effective, this fragmented setup can create operational challenges, such as managing multiple configurations, ensuring consistency across tools, scaling in dynamic environments, and maintaining uniform security policies. These complexities can slow down deployments and make it harder to adapt to the demands of fast-paced microservices environments where scalability and reliability are crucial.

The Kubernetes Gateway API addresses these challenges by introducing a standardized, Kubernetes-native framework for managing traffic. Designed to extend and improve upon Ingress, it supports advanced routing, robust load balancing, enhanced security, and multi-tenancy; all with native support for Kubernetes declarative configurations. Devtron further simplifies this by providing one DevOps platform that natively integrates with new Kubernetes networking technologies like the Gateway API. From deployment automation to security and monitoring, Devtron gets your applications running smoothly without the operational complexity.

Networking In Kubernetes

When you deploy applications in Kubernetes, they run inside a cluster made up of multiple nodes. These nodes could be virtual machines or bare-metal servers, and Kubernetes distributes your application across them using pods. A pod is the smallest deployable unit in Kubernetes, and it can move between nodes based on factors like scaling, replication, and resource availability. To learn more about the different Kubernetes workloads, please refer to this blog: What are Kubernetes Workloads.

To connect users to your applications, Kubernetes relies on services. A service acts as a bridge between the pods running your application and the network. There are different types of services for different use cases:

• ClusterIP: The default type, provides an internal IP that makes the application accessible only within the cluster.
• NodePort: Exposes the service on a static port of each node’s IP, allowing limited external access.
• LoadBalancer: Assigns an external IP address, making the service accessible to users outside the cluster.

For a deeper dive into Kubernetes Services, check out our blog: Kubernetes Services.

For applications that need external access, the LoadBalancer service is a common choice. However, using a separate load balancer for each application doesn’t scale well. It becomes expensive, wasteful, and difficult to manage as the number of services grows.

To solve this, Kubernetes introduced the concept of Ingress. An Ingress acts as a centralized entry point, routing incoming traffic to the correct service based on rules like URL paths or hostnames. For example, traffic to my-site.com/bills can be routed to a billing service. This eliminates the need for a load balancer for every service, making it a more efficient solution.

To learn more about Kubernetes Ingress in more detail, please read this blog: What is Kubernetes Ingress? A Hands-on Guide

However, an Ingress is just a set of rules, and it requires an Ingress Controller (like NGINX or Traefik) to handle traffic and implement those rules. While Ingress simplifies networking in Kubernetes, it comes with its own set of limitations.

Limitations of Kubernetes Ingress

Now that you understand how traffic flows into your Kubernetes applications using LoadBalancers and Ingress, let’s dive into the limitations of Ingress.

While Ingress simplifies application networking in Kubernetes, it does have some limitations that can make it less effective for modern, complex setups:

1. Protocol Restrictions: The standard Ingress is designed only for HTTP/HTTPS traffic (Layer 7). If your application uses other protocols like TCP or UDP (Layer 4), Ingress alone cannot handle them. You’ll need additional tools or combine them with Kubernetes services to enable TCP or UDP protocols.
2. Lack of Standardization: Advanced features like load balancing and traffic routing are not part of the standard Ingress specification. Instead, they depend on the specific Ingress Controller you’re using, like NGINX or Traefik. Each controller has its own way of configuring these features, often requiring annotations or custom setups. This lack of standardization can be frustrating, especially if you’re managing multiple clusters or want to switch controllers.
3. Limited Extensibility: Features like SSL/TLS termination, managing certificates, or integrating with tools like Cert-Manager aren’t natively handled by Ingress itself. Instead, these rely on the Ingress Controller, and the level of support varies. This can make it hard to ensure consistency, especially in multi-cluster or multi-cloud environments. For advanced functionality, like natively handling SSL/TLS without extra configuration or tools, a service mesh like Istio can be introduced. Service meshes extend Kubernetes' capabilities by providing built-in support for tasks like SSL termination, traffic encryption, and more.

These limitations make the standard Ingress less ideal for complex or large-scale applications, especially when dealing with diverse protocols or advanced traffic control needs. Recognizing these challenges, the Kubernetes community developed the Gateway API, a more flexible and extensible solution to address the gaps in the Ingress model.

What is Gateway API

The Kubernetes Gateway API is a specification that standardizes how traffic routing is managed within Kubernetes clusters. It was created by the Kubernetes SIG-NETWORK group as a more flexible and powerful alternative to the limitations of the Ingress API. The Gateway API makes it easier to handle things like ingress, load balancing, service discovery, and traffic routing, and it integrates well with Kubernetes’ native resources, such as Services and Endpoints. While Kubernetes doesn’t offer a default implementation, there are several popular open-source and commercial tools, like Istio and Envoy Gateway, that support the Gateway API.

The Gateway API consists of three main components:

1. GatewayClass: Think of this as a template or a blueprint for setting up Gateways. It defines a group of Gateways that share the same configuration and are managed by a controller that follows the specifications of the class.
2. Gateway: This is where the traffic handling happens. A Gateway is like an entry point to your cluster, such as a cloud load balancer, that directs incoming traffic to the appropriate destinations based on your configuration.
3. HTTPRoute: This is where you set the rules for how HTTP traffic gets routed. It helps map traffic from the Gateway to your backend services, such as those running in Kubernetes Pods, based on things like URL paths, headers, or hosts.

Together, these components provide a structured and flexible way to manage traffic flow and routing in a Kubernetes environment.

How Gateway API Works

So far, we've covered what the Kubernetes Gateway API is, why it's essential, and its key components. Now, let's dive into how it works, giving you a clearer understanding of its functionality.

Here is a logical breakdown of each of its components and how it works:

Gateway Controller

Similar to the Ingress Controller, the Gateway Controller is the central component that manages all Gateway resources. It is responsible for ensuring that the configurations defined in Gateway resources are implemented correctly. The Gateway Controller listens for changes in the Gateway, GatewayClass, and Route objects, then updates the network configuration accordingly to handle incoming traffic as defined. This enables the Kubernetes cluster to react to changes in routing configurations and manage traffic efficiently.

GatewayClass

The GatewayClass defines the behavior and configuration of Gateways in your cluster. Think of it as a template or blueprint for your Gateway resources. It specifies which controller will manage the Gateway (this could be an open-source solution like Istio or a custom implementation). The GatewayClass also contains configurations like IP pools and resource limits. The infrastructure provider is responsible for defining and managing the GatewayClass.

Here is an example code snippet of a GatewayClass:

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

This defines a GatewayClass named example-gatewayclass. It specifies the controller (example.com/gateway-controller) responsible for managing this Gateway.

Gateway

Once the GatewayClass is defined, you can create a Gateway object based on it. The Gateway object is created based on a specific GatewayClass. It defines how traffic enters the cluster and which listeners will handle the traffic (e.g., HTTP, HTTPS). A single Gateway can handle traffic for multiple applications, and these applications can share the same Gateway while still maintaining their own routing rules.

Here is an example code snippet of a Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gatewayclass
  listeners:
    - name: http
      port: 80
      protocol: HTTP

This defines a Gateway named example-gateway, which uses the previously created example-gatewayclass. It listens on port 80 using the HTTP protocol to handle incoming traffic.

HTTPRoute

After setting up the Gateway, you define HTTPRoutes (or other route types, like TCPRoute) to specify how traffic should be forwarded to the services in your cluster. HTTPRoute objects define rules for routing HTTP traffic, such as matching paths, headers, or other HTTP attributes. The HTTPRoute object essentially acts as the set of instructions for how the Gateway should direct incoming traffic to specific applications or services in the Kubernetes cluster.

Here is an example of how HTTPRoute is configured:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  hosts:
    - "example.com"
  rules:
    - matches:
        - path:
            type: Prefix
            value: /app
      forwardTo:
        - serviceName: app-service
          port: 80

This defines an HTTPRoute named example-httproute, which listens for requests to example.com. It forwards requests with the path /app to the app-service on port 80.

These components work together to make it easier to manage traffic routing in Kubernetes. They give teams more control over how network traffic flows and how security is handled. The system is designed so that different teams like infrastructure providers, cluster operators, and application developers can work together smoothly without interfering with each other's tasks.

Gateway API vs. Kubernetes Ingress

Now that we have a clear understanding of how the Gateway API works, let's explore the key differences between the Gateway API and Kubernetes Ingress, both of which are used for traffic management in Kubernetes.

Installing and Using the Gateway API

By now, the need for the Gateway API should be clear. Let’s move on to how you can install the Gateway API in your cluster and use it effectively to manage traffic.

Prerequisites

To follow along, you’ll need a Kubernetes Cluster with two or more nodes. You can create one by using minikube or you can use one of these Kubernetes playgrounds:

• Killercoda
• Play with Kubernetes

In this tutorial, we’ll install the Kubernetes Gateway API and use it to route traffic between the frontend and backend of an e-commerce app. By the end, you’ll understand how to set up GatewayClass, Gateway, and HTTPRoute for efficient traffic management.

Step 1: Install the Gateway API CRDs

First, install the Gateway API Custom Resource Definitions (CRDs) in our cluster:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

Verify the installation:

kubectl get crds | grep gateway

Step 2: Deploy a Gateway Controller

The Gateway API doesn’t come with a built-in controller. You can use an existing one like Istio, Kong, or Envoy Gateway. For example, to install the Istio Gateway Controller, run:

istioctl install --set profile=default

kubectl apply -f https://github.com/istio/istio/releases/latest/download/gateway.yaml

Step 3: Define a GatewayClass

The GatewayClass defines how gateways should behave, similar to an IngressClass.

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

Apply it:

kubectl apply -f gatewayclass.yaml

Step 4: Create a Gateway

The Gateway is the actual network entry point handling traffic.

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

Apply it:

kubectl apply -f gateway.yaml

Step 5: Define HTTP Routes

Routes define how incoming requests are forwarded to backend services.

Routes define how incoming requests are forwarded to backend services.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: frontend-to-backend
spec:
  parentRefs:
  - name: ecommerce-gateway
  rules:
  - matches:
    - path:
        type: Prefix
        value: "/api"
    backendRefs:
    - name: backend-service
      port: 8080

Apply it:

kubectl apply -f httproute.yaml

Step 6: Deploy Frontend and Backend Services

For simplicity, deploy a basic frontend and backend.

Frontend Service:

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

Backend Service:

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Apply both:

kubectl apply -f frontend-service.yaml
kubectl apply -f backend-service.yaml

Step 7: Test the Setup

Retrieve the external IP of your Gateway:

kubectl get gateway ecommerce-gateway

Send a request:

curl http://<GATEWAY-IP>/api

If everything is set up correctly, the request should be routed to the backend service.

Conclusion

To sum it up, the Gateway API offers a more flexible and scalable way to manage traffic in Kubernetes compared to the traditional Ingress. With new resources like GatewayClass, Gateway, and HTTPRoute, it gives teams more control over routing, security, and infrastructure. Its role-oriented design enables collaboration between different teams, offering greater flexibility in defining networking policies and handling complex traffic scenarios. Plus, with support for multiple protocols and advanced features like weighted routing, the Gateway API is a powerful tool for handling traffic in modern Kubernetes environments.

FAQ

Ayaan Bordoloi

Ayaan is a DevOps Evangelist at Devtron, specializing in Kubernetes, Docker, CI/CD, and cloud-native tech. He shares insights through blogs, making complex concepts accessible to all.