Migration From Ingress to Gateway API

Ingress offers a centralized approach for managing external access to services within a Kubernetes cluster, primarily handling HTTP/HTTPS traffic at Layer 7. Rather than assigning a dedicated load balancer to each service, Ingress provides a unified entry point for directing inbound requests to backend applications.

An Ingress resource specifies routing rules that determine how external traffic is forwarded to Kubernetes services. These rules can include hostnames, paths, and TLS settings. An Ingress controller then takes these configurations and applies them to the underlying data plane—such as a reverse proxy or load balancer—to actually serve the traffic.

Limitation

However, Ingress is limited to L7 HTTP/HTTPS. Support for other L7 protocols (like gRPC) or lower-layer protocols (such as TCP and UDP) requires custom controller extensions rather than native Ingress functionality. This creates fragmentation: essential capabilities like authentication, rate limiting, or advanced traffic policies depend on controller-specific annotations. For example, NGINX and HAProxy Ingress controllers each rely on their own custom syntax and extensions.

The Ingress specification also lacks built-in support for many advanced traffic management features expected in production environments. As a result, capabilities such as canary deployments, A/B testing, or distributed tracing become tightly tied to the vendor implementation instead of being portable across platforms. While Ingress focuses narrowly on basic HTTP routing, more sophisticated networking behaviors must be configured directly on the controller, adding complexity and reducing consistency across environments.

To solve the limitations around Kubernetes Ingress, the Gateway API project was created as an evolving standard to unify capabilities across different Ingress Controllers.

Gateway API defines a common set of Kubernetes resource objects and usage patterns that all compliant gateways must support.

Gateway API supports both L4 and L7 protocols including TCP, UDP, HTTP, gRPC, and more are under consideration. This expands its scope beyond just HTTP traffic.

A key architectural difference between Ingress and Gateway API is how they structure the control plane and data plane.

1-Ingress Controller An Ingress Controller is a single component that combines both roles:

Control plane: Watches Ingress resources and translates rules

Data plane: The very same pods run NGINX, HAProxy, Traefik, etc. and serve traffic

After installation, the controller’s pods remain static. When you apply a new Ingress: No new data-plane pods are created The Ingress Controller simply updates its existing proxy configuration.

2-Gateway API

Gateway API deliberately separates the control plane from the data plane.

Control plane: The Gateway controller (e.g., Envoy Gateway) watches Gateway, Route, and policy resources.

Data plane: The controller creates dedicated proxy pods to handle traffic.

When you apply a Gateway:

✅ A new Deployment is created ✅ One or more Envoy proxy pods (or other proxies) are launched

Here is a list of several Gateway controllers

Overview

Gateway API Has Two Types of APIs When working with Gateway API, you must distinguish between:

These are official Kubernetes APIs, fully standardized by the Gateway API project. They exist in the upstream API (same everywhere, same behavior).

Gateway API Standard Resources

While these resources define the standard surface of the Gateway API, not every gateway controller implements all of them, and some only offer partial or controller-specific support.

Gateway API Standard Resource Compatibility

After identifying which controllers fully support the native Kubernetes Gateway API, we can now examine the extensions and proprietary APIs that each one introduces to provide additional capabilities.

Envoy Gateway API

Cillium API

Kgateway API

Nginx Fabrik API

Istio Traffic Management APIs (Service-mesh)

Migration Guide Introduction

This guide explains how to migrate from Ingress to any Gateway implementation. For demonstration purposes, we will use Envoy Gateway as the example, showcasing the setup both with and without ExternalDNS integration.

The environment will include the following components:

• Envoy configured as the GatewayClass
• ExternalDNS (Cloudflare provider) — and a variant of the setup without ExternalDNS
• Gateway API with Envoy Gateway
• Cert-manager with Gateway API support enabled
• Gateway and HTTPRoute configuration

This guide will demonstrate the full setup in two scenarios:

With ExternalDNS enabled (automatic DNS record management)

Without ExternalDNS (manual DNS management)

1. Install Gateway API Standard CRDs

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

2. Install Envoy Gateway

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.5.6 \
  -n envoy-gateway-system \
  --create-namespace

3. Install Envoy Gateway

Create the file gatewayclass.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

4. Create Cloudflare API Token Secret

kubectl create secret generic cloudflare-api-key --from-literal=apiKey=YOUR_API_TOKEN

5. Install ExternalDNS (Cloudflare)

Create a values.yaml for ExternalDNS:

provider: 
  name: cloudflare
env:
  - name: CF_API_TOKEN
    valueFrom:
      secretKeyRef:
        name: cloudflare-api-key
        key: apiKey

If you are using a different DNS provider, refer to the ExternalDNS documentation and update this configuration accordingly.

6. Install Cert-Manager (GatewayAPI enabled)

  helm upgrade --install cert-manager oci://quay.io/jetstack/charts/cert-manager --namespace cert-manager \
  --set config.apiVersion="controller.config.cert-manager.io/v1alpha1" \
  --set config.kind="ControllerConfiguration" \
  --set config.enableGatewayAPI=true

Or in values.yaml:

config:
  apiVersion: controller.config.cert-manager.io/v1alpha1
  kind: ControllerConfiguration
  enableGatewayAPI: true

7. Create ACME Issuer (http01)

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: issuer-demo
  namespace: default 
spec:
  acme:
    privateKeySecretRef:
      name: letsencrypt-gateway
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        gatewayHTTPRoute:
          parentRefs:
          - kind: Gateway
            name: gateway-demo
            namespace: default 

this will depend on

- kind: Gateway
name: gateway-demo
namespace: default 

8. Gateway Resource

Create gateway.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-demo
  namespace: default
  annotations:
    cert-manager.io/issuer: issuer-demo
    cert-manager.io/issuer-kind: Issuer
spec:
  gatewayClassName: eg 
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: example.com
    - name: https
      port: 443
      protocol: HTTPS
      hostname: example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: demo-com-tls

9. HTTPRoute Resource

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-route-demo
  namespace: default
  annotations:
    external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  parentRefs:
    - name: gateway-demo
      sectionName: https
      namespace: default
  hostnames:
    - example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: backend-demo
          port: 80

You may now access: example.com

Setup gateway without exteralDNS

1. Install Gateway API Standard CRDs

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

2. Install Envoy Gateway

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.5.6 \
  -n envoy-gateway-system \
  --create-namespace

3. Install Envoy Gateway

Create the file gatewayclass.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

4. Create ACME Issuer (http01)

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: issuer-demo
  namespace: default 
spec:
  acme:
    privateKeySecretRef:
      name: letsencrypt-gateway
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        gatewayHTTPRoute:
          parentRefs:
          - kind: Gateway
            name: gateway-demo
            namespace: default 

this will depend on

- kind: Gateway
name: gateway-demo
namespace: default 

5. Gateway (initial minimal configuration)

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

6. HTTPRoute (initial minimal configuration)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-route-demo
  namespace: default
spec:
  parentRefs:
  - name: gateway-demo
    sectionName: https
    namespace: default
  hostnames:
    - example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: backend-demo
      port: 80

7.Retrieve Gateway IP

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

Create your record with this ip .

8. Patch Gateway for HTTPS + Certificate

kubectl patch gateway gateway-demo -n cattle-system --type merge -p '{
  "metadata": {
    "annotations": {
      "cert-manager.io/issuer": "issuer-demo",
      "cert-manager.io/issuer-kind": "Issuer"
    }
  },
  "spec": {
    "listeners": [
      {
        "name": "http",
        "protocol": "HTTP",
        "port": 80,
        "hostname": "example.com"
      },
      {
        "name": "https",
        "protocol": "HTTPS",
        "port": 443,
        "hostname": "example.com",
        "tls": {
          "mode": "Terminate",
          "certificateRefs": [
            {
              "name": "demo-com-tls"
            }
          ]
        }
      }
    ]
  }
}'

References

• Kubernetes Gateway API
• NGINX Gateway Fabric
• Envoy Gateway
• Istio Gateway API
• Cilium Gateway API
• Traefik Kubernetes Gateway
• Kgateway (Solo.io)