Using Gateway API with Kong

Pre-requisites

minikube or any k8s cluster
helm
kubectl

Ways to Expose Pods in Kubernetes

In Kubernetes, pods are ephemeral, meaning their IPs can change as they are recreated. To provide stable access to applications running in pods, Kubernetes offers several abstraction layers:

Pod IP (Internal Cluster Access): Each pod receives a unique IP address within the cluster network. While pods can communicate directly using these IPs, this is not a stable or recommended way to expose applications, especially for external access or for communication between pods that might be rescheduled.
Services: A Kubernetes Service is a fundamental abstraction that defines a logical set of pods and a policy by which to access them. Services provide a stable IP address and DNS name. There are several types of Services:
1. ClusterIP: Exposes the Service on a cluster-internal IP. This type is only reachable from within the cluster.
2. NodePort: Exposes the Service on a static port on each Node’s IP. This makes the service accessible from outside the cluster via NodeIP:NodePort. While simple, it’s not ideal for production due to port management and lack of advanced routing.
3. LoadBalancer: Provisions an external load balancer (if supported by the cloud provider) that routes external traffic to the Service. This provides a dedicated external IP, but can be expensive if you have many services.
4. ExternalName: Maps the Service to a DNS name, essentially a CNAME record, for accessing external services.
5. Ingress: For HTTP/HTTPS traffic, Ingress acts as an API object that manages external access to services in a cluster, typically providing HTTP and HTTPS routing. It allows you to consolidate routing rules into a single resource, eliminating the need for a dedicated LoadBalancer per service for many common use cases.

The Existing Ingress and Its Shortcomings

Kubernetes Ingress, along with an Ingress Controller (e.g., NGINX Ingress Controller, Traefik, Kong Ingress Controller), has been the go-to solution for exposing HTTP/HTTPS applications.

How Ingress Works:

An Ingress resource defines rules for routing external HTTP/HTTPS traffic to Services within the cluster. The Ingress Controller then watches these Ingress resources and configures an underlying load balancer or reverse proxy (like NGINX or Envoy) to implement the defined rules.

Example Ingress Resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-api-service
            port:
              number: 8080

This Ingress routes traffic for myapp.example.com/ to my-service and myapp.example.com/api to my-api-service.

Shortcomings of Ingress:

While Ingress is powerful for basic HTTP/HTTPS routing, it has several limitations, which led to the development of the Gateway API:

Limited Protocol Support: Ingress is primarily designed for HTTP/HTTPS (Layer 7) traffic. It lacks native support for other common protocols like TCP, UDP, or gRPC, often requiring vendor-specific annotations or custom configurations.
Limited Advanced Traffic Management: Features like advanced traffic splitting (e.g., A/B testing, canary deployments), header-based routing (beyond host and path), request manipulation, or circuit breaking are not natively supported. These often rely on non-portable, vendor-specific annotations.
Lack of Role-Oriented Design: Ingress combines infrastructure-level concerns (like load balancer configuration) with application-level routing rules in a single resource. This can lead to a lack of clear separation of concerns, making it difficult for different teams (infrastructure operators, application developers) to manage their respective responsibilities without stepping on each other’s toes.
Vendor Lock-in via Annotations: To overcome Ingress’s limitations, Ingress Controller vendors introduced custom annotations. While these extended functionality, they made Ingress configurations less portable across different Ingress Controller implementations. Migrating from one controller to another often required significant re-configuration.
No Standardized API for Gateways: Ingress focuses on routing to Services, but it doesn’t define a standard way to represent the actual “gateway” or “proxy” itself. This means each Ingress Controller might have its own way of exposing metrics, configuring listeners, or handling external IPs.
Extensibility Challenges: While annotations provide extensibility, they are not a formal API and can be brittle. Adding new features or complex policies consistently across different implementations becomes challenging.

The Need for Gateway API

Recognizing the limitations of Ingress, the Kubernetes SIG (Special Interest Group) Network initiated the development of the Gateway API. The Gateway API aims to provide a more expressive, extensible, and role-oriented way to manage traffic routing in Kubernetes.

Key Motivations and Design Principles of Gateway API

Role-Oriented: The API is designed with distinct roles in mind:
Infrastructure Provider: Manages GatewayClass resources, defining the capabilities of different gateway implementations.
Cluster Operator: Deploys and configures Gateway resources, representing the actual network entry points (e.g., a load balancer, proxy). They control listeners, ports, and IP addresses.
Application Developer: Manages Route resources (e.g., HTTPRoute, TCPRoute, GRPCRoute), defining how their applications’ traffic should be routed through the Gateways. This separation allows developers to manage their application’s routing without needing deep knowledge of the underlying network infrastructure.
Portable: By defining a standardized API, the Gateway API aims for greater portability across different implementations. While vendors can still offer extended features, the core functionality is consistent.
Expressive: It offers built-in support for advanced routing capabilities that were previously only available through custom annotations, such as:
1. Header-based matching
2. Query parameter matching
3. Traffic weighting for canary deployments and A/B testing
4. Request/response header manipulation
5. Traffic mirroring
6. Support for multiple protocols (HTTP, HTTPS, TCP, UDP, TLS passthrough).
Extensible: The API is designed to be highly extensible through explicit extension points, allowing vendors to add custom functionality without breaking portability for core features.
Conformance: The Gateway API defines conformance tests to ensure that different implementations adhere to the specification, promoting interoperability.

Gateway API with Kong

You can run the below command to install Kong Ingress Controller with Gateway API and also have a test route created for a hello service. You can find the different steps being explained below,

curl -Ls https://raw.githubusercontent.com/kong-tools/scripts/refs/heads/main/build-gateway-api-1.3.0.sh | bash

Install KGO

Kong Gateway Operator is the Kubernetes-native way to interact with Kong. Driven entirely by Kubernetes Custom Resource Definitions (CRDs), Kong Gateway Operator allows you to deploy and configure Kong’s products in a 100% declarative way. After installing the KGO, kong will listen/wait for any Gateay configurations to be applied which then triggers the creation of Control Plane and Data Plane. Prior to this you can see command that installs the CRDs specific to Gateway API being installed in the cluster.

Create Gateways

This step helps to configure the Gateway and the listeners being used which will be listened to in the cluster and expose them via Gateway. GatewayClass name kong helps us to associate any routes we create in the cluster to be associated with this gateway. This will expose the Gateway on the port 80. In order to have this exposed with an external IP, you need to run the minikube tunnel to provide a localhost IP.

Create Service

This step will deploy a REST API (hello) which exposes two operations GET and POST and returns a json response. This is published as a docker image in the docker hub repository and this serice will be running in the port 8080

Create Route

HTTPRoute helps us to expose Http APIs via Gateway. Below configuration says that this route is associated with the Gateway kong and matches for the path /hello and redirects it to the service referenced as backend hello on port 8080

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
 name: hello
spec:
 parentRefs:
   - group: gateway.networking.k8s.io
     kind: Gateway
     name: kong
 rules:
   - matches:
       - path:
           type: PathPrefix
           value: /hello
     backendRefs:
       - name: hello
         port: 8080

Testing

To test the route we can issue the following command and validate the response

curl http://127.0.0.1/hello

{"from":"Go","message":"Hello, Go!","status":true}

curl http://127.0.0.1/hello -X POST -H 'Content-Type: application/json' --data '{"name":"YOUR_NAME"}'

{"from":"Go","message":"Hello, YOUR_NAME!","status":true}

This example demonstrates a basic HTTPRoute. The Gateway API supports much more complex routing logic, including multiple matchers, filters, and more.

By transitioning to the Gateway API, Kubernetes users can achieve a more structured, powerful, and portable approach to managing external traffic, paving the way for advanced use cases and better separation of concerns in cloud-native environments.