Kubernetes Gateway API Implementation

This repository provides a comprehensive guide for implementing the Kubernetes Gateway API, demonstrating its capabilities for modern traffic management.

Project Structure

• apps/: Core application deployments (v1 and v2) for routing tests.
• infrastructure/: Gateway API resources (Gateway, GatewayClass).
• routing/: Traffic management scenarios (Path-based, Canary, and Header-based).
• scripts/: Implementation testing scripts.

Prerequisites

1. General Requirements

• EC2 Instance / Workstation: A Linux-based environment (Amazon Linux 2023, Ubuntu, etc.) to run the implementation commands.

• AWS CLI: Installed and configured with appropriate permissions.

  aws configure

• Tools: kubectl, eksctl, helm (installation steps provided below).

Tool Installation (Linux)

1. kubectl

   # Download the latest release with the command
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
   
   # Install kubectl
   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
   
   # Verify the installation
   kubectl version --client

2. eksctl

   # Download the latest release with the command
   curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
   sudo mv /tmp/eksctl /usr/local/bin
   
   # Verify the installation
   eksctl version

3. Helm

   curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

2. Choosing Your Cluster

• Local (Kind/Minikube): Suitable for development. Access usually requires kubectl port-forward or a LoadBalancer emulator like metallb.
• AWS EKS: Recommended for production-like testing with real LoadBalancers and dynamic DNS support.

Step-by-Step EKS Setup (eksctl)

1. Create EKS Cluster (without node group):

   eksctl create cluster --name gateway-api-cluster --region us-east-1 --without-nodegroup

2. Associate IAM OIDC Provider:

   eksctl utils associate-iam-oidc-provider --region=us-east-1 --cluster=gateway-api-cluster --approve

3. Create Node Group:

   eksctl create nodegroup \
     --cluster=gateway-api-cluster \
     --region=us-east-1 \
     --name=gateway-api-ng \
     --node-type=t3.medium \
     --nodes=2 \
     --nodes-min=1 \
     --nodes-max=3 \
     --node-volume-size=20 \
     --managed

4. Update kubeconfig:

   aws eks update-kubeconfig --region us-east-1 --name gateway-api-cluster

5. Verify nodes

   kubectl get nodes

2. Install Gateway API CRDs

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

3. Install a Gateway Controller

These configurations are tested with Envoy Gateway.

# Install Envoy Gateway via Helm
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.1.0 -n envoy-gateway-system --create-namespace

Wait for the pods to be ready:

kubectl wait -n envoy-gateway-system \
  deployment/envoy-gateway \
  --for=condition=Available --timeout=5m

---

Implementation Steps

Clone the Repository

git clone https://github.com/Amitabh-DevOps/gateway-api-k8s.git
cd gateway-api-k8s

1. Initial Setup

Apply the sample applications:

kubectl apply -f apps/

2. Infrastructure

Deploy the Gateway and GatewayClass:

kubectl apply -f infrastructure/

3. Configure DNS

Before starting the scenarios, ensure your custom domain points to the AWS LoadBalancer:

1. Get the LoadBalancer URL:

   kubectl get gateway demo-gateway -o jsonpath='{.status.addresses[0].value}'

2. Update DNS: Create a CNAME record for gateway.<YOUR-DOMAIN> pointing to that URL.

Important

Search and Replace all amitabh.cloud with your Domain

---

Implementation Scenarios

To see the distinct effects of each routing type, it is recommended to apply them one by one and clean up between steps.

Scenario 1: Path-Based Routing

Route traffic based on URL prefixes (/v1 for Production, /v2 for Beta). This scenario uses URLRewrite filters to strip the prefixes so the backend apps serve correctly.

# 1. Apply rules
kubectl apply -f routing/path-routing.yaml

# 2. Test
curl -s "http://gateway.amitabh.cloud/v1" | grep "Version 1"
curl -s "http://gateway.amitabh.cloud/v2" | grep "Version 2"

You can also check by going to those URL in the browser

• v1:

  

• v2:

  

Clean up

kubectl delete -f routing/path-routing.yaml

---

Scenario 2: Canary Deployment (Weighted)

Distribute traffic between versions (90% to V1, 10% to V2) on the same URL.

# 1. Apply rules
kubectl apply -f routing/traffic-split.yaml

# 2. Test (Run multiple times to see the split)
./scripts/test.sh

You can also check by going to those URL in the browser

• Open: http://gateway.amitabh.cloud multiple times and you will see the split traffic

  • So based on 90% to V1, 10% to V2, user mostly see V1.

    gateway-api-canary-demo.mp4

Clean up

kubectl delete -f routing/traffic-split.yaml

---

Scenario 3: Header-Based Routing

Route specific users based on a request header (e.g., X-Version: v2).

# 1. Apply rules
kubectl apply -f routing/header-routing.yaml

# 2. Test
# Normal request (Default to V1)
curl -s "http://gateway.amitabh.cloud/" | grep "Version 1"

# Request with header (Target V2)
curl -s -H "X-Version: v2" "http://gateway.amitabh.cloud/" | grep "Version 2"

# 3. Clean up
kubectl delete -f routing/header-routing.yaml

Output

• v1:

  

  

• v2:

  

  (We can not see this in browser, because we can not update the Headers in Brower, there are extension that help to update, that you can search and try.)

Testing Script

A helper script is provided to automate verification of the active scenario:

chmod +x scripts/test.sh
./scripts/test.sh

Cleanup

To destroy the cluster and all resources once you are finished:

# Delete the entire cluster (this removes all nodes and cloud resources)
eksctl delete cluster --name gateway-api-cluster --region us-east-1