Ingress NGINX Is Retiring

In March 2026, Ingress NGINX — the most widely used Ingress implementation — reaches end of support. While the Ingress API itself remains, the retirement of its flagship implementation signals a shift to the Gateway API.

What makes Gateway API different from Ingress? The key difference is role separation. Infrastructure admins, cluster operators, and developers can configure their respective domains independently, offering greater expressiveness and extensibility.

This post extends the article published on yozm.wishket.com with detailed test data and a selection guide not covered in the original piece.

Test Environment

Cluster Overview

ItemDetails
Kubernetes Versionv1.34.2
ArchitectureARM64 (Apple Silicon)
OSUbuntu 22.04.5 LTS
Container Runtimecontainerd 1.7.24
Gateway API Versionv1.2.0
CNICilium v1.18.4 (eBPF, kube-proxy replacement)

Node Configuration

NodeRoleIPCPUMemory
cp-k8scontrol-plane192.168.1.104 vCPU3.8 GB
w1-k8sworker192.168.1.1014 vCPU7.8 GB
w2-k8sworker192.168.1.1024 vCPU7.8 GB
w3-k8sworker192.168.1.1034 vCPU7.8 GB

Total cluster resources: 16 vCPU, 27.2 GB memory

Gateway IP Assignments

ImplementationGatewayClassIPNamespace
NGINX Gateway Fabricnginx192.168.1.11nginx-gateway
Envoy Gatewayeg192.168.1.12envoy-gateway-system
Istio Gatewayistio192.168.1.14istio-system
Cilium Gatewaycilium192.168.1.15kube-system
Kong Gatewaykong192.168.1.16kong
Traefik Gatewaytraefik192.168.1.17traefik
kgatewaykgatewayARM64 not supported, excluded

All 7 Gateway implementations ran independently in the same cluster. Cilium was chosen as the CNI to include Cilium Gateway in the tests. With a different CNI, the remaining 6 implementations are unaffected.

Cluster Architecture

┌─────────────────────────────────────────────────────────────────┐
│                  Kubernetes Cluster (v1.34.2)                    │
│                                                                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │              Control Plane (cp-k8s)                        │  │
│  │              192.168.1.10 | 4 CPU | 3.8GB                  │  │
│  │  ┌─────────┐ ┌──────┐ ┌───────────┐ ┌──────────┐          │  │
│  │  │kube-api │ │ etcd │ │ scheduler │ │ ctrl-mgr │          │  │
│  │  └─────────┘ └──────┘ └───────────┘ └──────────┘          │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐   │
│  │ Worker: w1-k8s  │ │ Worker: w2-k8s  │ │ Worker: w3-k8s  │   │
│  │ 192.168.1.101   │ │ 192.168.1.102   │ │ 192.168.1.103   │   │
│  │ 4 CPU | 7.8GB   │ │ 4 CPU | 7.8GB   │ │ 4 CPU | 7.8GB   │   │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘   │
│                                                                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │              CNI: Cilium v1.18.4 (eBPF)                    │  │
│  │  • kube-proxy replacement  • Gateway API enabled  • VXLAN  │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐       │
│  │   nginx   │ │   envoy   │ │   istio   │ │  cilium   │       │
│  │ .1.11     │ │ .1.12     │ │ .1.14     │ │ .1.15     │       │
│  └───────────┘ └───────────┘ └───────────┘ └───────────┘       │
│  ┌───────────┐ ┌───────────┐ ┌───────────┐                      │
│  │   kong    │ │  traefik  │ │ kgateway  │                      │
│  │ .1.16     │ │ .1.17     │ │ (ARM64 ✗) │                      │
│  └───────────┘ └───────────┘ └───────────┘                      │
│                                                                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                    Backend Services                         │  │
│  │  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────────────┐   │  │
│  │  │echo-v1 │  │echo-v2 │  │  grpc  │  │  backend-ns    │   │  │
│  │  │(stable)│  │(canary)│  │(HTTP/2)│  │(cross-namespace│   │  │
│  │  └────────┘  └────────┘  └────────┘  └────────────────┘   │  │
│  └───────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Backend Services

Four backend services were used across the test scenarios.

ServiceRoleUsed In
echo-v1Stable versionCanary: receives 80% of traffic
echo-v2Canary versionCanary: receives 20% of traffic
grpcgRPC server (HTTP/2)gRPC routing test only
backend-nsSeparate namespace serviceCross-namespace routing test

echo-v1 and echo-v2 are used across most tests including host/path/header routing, canary, and rate limiting. grpc is dedicated to the gRPC protocol test, and backend-ns is used exclusively for the cross-namespace scenario — routing traffic from the gateway-poc namespace Gateway into the backend-ns namespace.

Which Implementations Were Tested?

ImplementationVersionKey Feature
NGINX Gateway Fabricv2.2.1F5 open source, proven stability and rich documentation
Envoy Gatewayv1.6.0CNCF graduated, xDS-based, native rate limiting support
Istio Gatewayv1.28.0Service mesh integration, automated mTLS, CNCF graduated (2024)
Cilium Gatewayv1.18.4eBPF-based high performance, kernel-level processing, CNCF graduated (2023)
Kong Gatewayv3.9 (KIC v3.5)Enterprise API gateway, rich plugin ecosystem
Traefik Gatewayv3.6.2Cloud-native reverse proxy, Let’s Encrypt integration
kgateway (Solo.io)v2.1.1CNCF Sandbox (2025), excluded — no ARM64 support

Why Each Implementation Was Selected

NGINX Gateway Fabric: The official Gateway API implementation from NGINX, which has the longest production track record in the web server and reverse proxy space. The most natural migration path for teams running Ingress NGINX.

Envoy Gateway: Built on Envoy Proxy (CNCF graduated 2018), featuring xDS protocol-based dynamic configuration and a rich filter chain. The only implementation with native declarative Rate Limiting via CRD.

Istio Gateway: Gateway API support from Istio, the de facto standard for service meshes. Envoy-based but integrated with the Istio control plane, enabling automated mTLS and traffic management.

Cilium Gateway: A high-performance implementation using eBPF for kernel-level packet processing. Integrates L3/L4/L7 with network policy. Requires Cilium CNI.

Kong Gateway: The enterprise API gateway market leader with a rich plugin ecosystem. Strong for API management but Gateway API support is still maturing.

Traefik Gateway: A cloud-native reverse proxy with automatic service discovery and Let’s Encrypt integration. Gateway API support is progressing toward maturity.

What Was Tested?

17 test scenarios were executed over 100 rounds.

Category#Test ItemDescription
Routing1host-routingRoute app.example.com and api.example.com to different backends
2path-routingRoute by URL path patterns like /api/*, /web/*
3header-routingRoute to specific backend when X-Version: v2 header is present
TLS/Security4tls-terminationTLS termination at Gateway, forward HTTP to backend
5https-redirectAutomatic HTTP → HTTPS redirection (80 → 443)
6backend-tlsmTLS between Gateway and backend (requires sidecar)
Traffic Management7canary-trafficWeight-based traffic split (80% v1, 20% v2)
8rate-limitingLimit max requests per second/minute
9timeout-retryRequest timeout and automatic retry on failure
10session-affinitySticky routing — same client to same backend
Request/Response11url-rewriteRewrite URL paths: /old-api/*/new-api/*
12header-modifierAdd, modify, or delete request/response headers
Advanced13cross-namespaceRoute from gateway-poc to backend-ns namespace
14grpc-routingHTTP/2-based gRPC traffic handling
15health-checkBackend health check and automatic failure detection
Performance16load-testLoad test with 20 concurrent requests
17failover-recoveryVerify recovery after Gateway Pod restart

100-Round Test Results

Overall Success Rates

Success rate = PASS / (PASS + FAIL), excluding SKIP

ImplementationSuccess RatePASSFAILSKIPGrade
NGINX Gateway Fabric100%1502A
Envoy Gateway100%1502A
Istio Gateway100%1502A
Cilium Gateway100%1403A
Kong Gateway16.7%2105F
Traefik Gateway8.3%1115F
kgatewayN/A17

Four implementations (NGINX, Envoy, Istio, Cilium) achieved zero failures across all 100 rounds.

Detailed Results by Test Item

#Test Itemnginxenvoyistiociliumkongtraefik
1host-routing
2path-routing
3header-routing
4tls-termination
5https-redirect
6backend-tls
7canary-traffic
8rate-limiting
9timeout-retry
10session-affinity
11url-rewrite
12header-modifier
13cross-namespace
14grpc-routing
15health-check
16load-test
17failover-recovery

✅ PASS · ❌ FAIL · ⏭ SKIP

Skip Reasons

Test ItemReasonAffected
backend-tlsSidecar injection not configured (mTLS)All
session-affinityPolicy not configuredAll
tls-terminationGateway Pod IP not obtainedkong, traefik
https-redirectNot configuredkong, traefik
health-checkNot configuredkong, traefik
rate-limitingHTTP Rate Limiting not supportedcilium (Issue #33500)
kgateway allARM64 architecture not supportedkgateway

Why Did Kong Gateway Fail?

Error: "no Route matched with those values"

HTTPRoute resources failed to sync with Kong’s internal configuration. In “unmanaged gateway” mode, Gateway API compatibility issues caused basic routing to fail, triggering cascading failures across most tests.

Additionally, KIC v3.5.3 has configuration sync failures with Kong Gateway v3.9 — staying on KIC v3.5 is recommended.

Why Did Traefik Gateway Fail?

Error: "404 page not found" / Warning: "Gateway not ready"

Two root causes were identified:

  • EntryPoints port mismatch: Internal ports (8000/8443) vs external ports (80/443)
  • BackendTLSPolicy CRD version mismatch: v1alpha3 vs v1

The Gateway never reached Ready state, making routing impossible.

Both Kong and Traefik are mature Ingress implementations, but their Gateway API support is still evolving.

How Is Rate Limiting Supported?

Rate limiting is not included in the Gateway API standard spec. Each implementation handles it differently.

ImplementationSupportMethodNotes
Envoy GatewayNativeBackendTrafficPolicyDeclarative Gateway API-style config, most intuitive
NGINX Gateway FabricLimitedSnippetsFilterLow-level NGINX config injection
Istio GatewayLimitedEnvoyFilterLow-level Envoy config injection
Cilium GatewayNot supportedIssue #33500 in progress

Envoy Gateway is the only implementation with native declarative Rate Limiting via BackendTrafficPolicy. NGINX and Istio can achieve it through low-level config injection, but this is not a dedicated Rate Limiting API and adds complexity. Cilium currently does not support HTTP Rate Limiting.

Which Implementation Should You Choose?

ScenarioRecommendedReason
Stability firstNGINX Gateway FabricProven ops experience, rich docs, large community
API rate limiting neededEnvoy GatewayOnly implementation with native declarative Rate Limiting CRD
Service mesh environmentIstio GatewayAutomated mTLS, Istio control plane integration
High performance / high trafficCilium GatewayeBPF kernel-level processing, network policy integration
Multi-cloud / hybridEnvoy GatewayFlexible xDS protocol-based configuration

Migration Recommendations

  1. Run Ingress and Gateway API in parallel with gradual transition
  2. Test thoroughly in a staging environment first
  3. Strengthen monitoring during the transition period
  4. Prepare a rollback plan to Ingress in case of issues

Note

This PoC was conducted on December 5, 2025, on an ARM64 (Apple Silicon) cluster. Results may differ as each implementation has been updated since then. We recommend re-validating with the latest versions before adoption.

References