Kubernetes Ingress & Gateway Comparison: Traefik, Istio, Kong & More

Now that NGINX Ingress is basically saying “I’m slowly heading to retirement,” everyone has the same question in their head:

“So… who do we trust with all this traffic now?”

In this post, we’re putting eight major players in the Kubernetes traffic game on the table:

Traefik

HAProxy Ingress Controller

Kong Ingress Controller

Contour

Pomerium Ingress Controller

kgateway

Istio Ingress Gateway

Cilium Ingress Controller

Target audience: DevOps / SRE / Platform Engineers who do not lose their heart rhythm when they see kubectl get events.

Style: Technical, precise, mildly sarcastic, still respectful.

We’ll follow this structure:

Short explanation per category

Under each category, tool-by-tool mini breakdown

Short YAML snippets here and there

One big 1–5 scoring comparison table at the end

If you’re ready, let’s kubectl port-forward this into your brain.

1. Controller Architecture

Here we answer “how does this thing actually work?”

Envoy or not, single binary or not, control-plane / data-plane split, sidecars, CRDs…

Traefik

Architecture: Single binary that acts as both control-plane and data-plane. In Kubernetes it usually runs as a Deployment + Service.

APIs: Classic Ingress, its own CRDs (IngressRoute, Middleware, etc.), and a production-ready Gateway API implementation.

Strengths: Easy to install, quick to get working; low barrier for small/medium clusters.

Weaknesses: In very large, complex mesh-style environments, it’s not as “mesh-native” as Istio / Cilium / kgateway.

HAProxy Ingress Controller

Architecture: Go-based controller in front, classic HAProxy as the data-plane. Configuration is usually generated via ConfigMap + annotations into a HAProxy config file.

APIs: Ingress v1 is the main interface; recent versions also support Gateway API.

Strengths: HAProxy-level performance and strong TCP/L4 capabilities.

Weaknesses: CRD ecosystem is thinner than some others, configuration strategy is still heavily annotation + ConfigMap driven.

Kong Ingress Controller

Architecture: Separate Kong Gateway data-plane (NGINX + OpenResty) and a Kong Ingress Controller (KIC) acting as control-plane.

APIs: Ingress, Gateway API, and its own CRDs like KongPlugin, KongConsumer, etc.

Strengths: Very strong API gateway feature set; plugin ecosystem is huge.

Weaknesses: If you “just want a simple ingress,” it can feel a bit overkill and “enterprise-y”.

Contour

Architecture: Envoy as the data-plane, Contour as a separate control-plane. Envoy runs as a Deployment/DaemonSet, Contour runs as a separate Deployment.

APIs: Ingress, its own powerful HTTPProxy CRD, plus solid Gateway API support.

Strengths: Presents the power of Envoy through a relatively clean API; HTTPProxy is great for advanced L7 routing.

Weaknesses: Not a full mesh; lives mostly in the “ingress/gateway + strong L7” space.

Pomerium Ingress Controller

Architecture: Uses Pomerium as an identity-aware proxy for the data-plane, with an ingress controller-style control-plane layered around it.

APIs: Ingress, its own CRDs, and Gateway API support.

Strengths: Identity-centric access control (user, group, device context) is first-class. Perfect for “Zero Trust front door” use-cases.

Weaknesses: Not meant as a general-purpose L4/L7 load balancer; its main job is identity and policy.

kgateway

Architecture: Envoy-based data-plane with a single modular control-plane that unifies ingress, API gateway, service mesh, and even AI gateway functionality.

APIs: Designed Gateway API first; evolved from Gloo experience into a modern control-plane.

Strengths: Ambition to handle ingress + gateway + mesh with a single tool; very modern design.

Weaknesses: Brand-new identity compared to Istio / Cilium; ecosystem is growing but not yet “everywhere”.

Istio Ingress Gateway

Architecture: Classic service mesh: an Envoy sidecar in each pod, plus an Ingress Gateway Envoy Deployment at the edge. Control-plane is istiod.

APIs: Istio Gateway and VirtualService CRDs, plus strong Gateway API support. There is a clear roadmap to rely more on Gateway API in the future.

Strengths: Full mesh + L7 policy + security + advanced traffic management in one package.

Weaknesses: Learning curve is steep; heavy for small clusters.

Cilium Ingress / Gateway

Architecture: Hybrid model: eBPF-based L3/L4 and Envoy-based L7. Cilium is a CNI + service mesh; its Ingress and Gateway API support sit on top of that.

APIs: Ingress and Gateway API (HTTPRoute, GRPCRoute, TLSRoute, etc.).

Strengths: Very efficient data path with eBPF at the bottom and Envoy for L7; gateway and CNI from the same stack.

Weaknesses: If you “just want to route two services,” it can be overkill; you have to think about the cluster’s entire networking model.

2. Configuration & Annotation Compatibility

Here we look at:

“What’s the migration pain from Ingress + NGINX annotations?”

“How messy are the CRDs?”

“Is Gateway API supported?”

You also get a small YAML snippet per tool family.

Traefik

Support: Ingress, its own CRDs (IngressRoute, Middleware), and a mature Gateway API implementation.

From NGINX land: With newer Traefik versions, there’s specific effort to make life easier for people coming from ingress-nginx and annotation-heavy configs.

Complexity: If you dive into its CRDs, there’s some learning involved, but overall readability is decent.

Example Gateway + HTTPRoute (generic Gateway API, usable with many implementations):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
  namespace: prod
spec:
  gatewayClassName: traefik
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  namespace: prod
spec:
  parentRefs:
    - name: web-gw
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-svc
          port: 80

HAProxy Ingress Controller

Support: Ingress v1 as the main API; huge amount of behavior is controlled via annotations + ConfigMap; and there is Gateway API support coming up as well.

From NGINX land: Annotation mindset is similar; if you were already living in “NGINX annotation soup,” this will feel familiar.

Complexity: Very powerful, but the annotation list is long; going in without documentation can cause headaches.

Minimal Ingress example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    haproxy.org/ssl-redirect: "true"
spec:
  ingressClassName: haproxy
  rules:
    - host: web.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

Kong Ingress Controller

Support: Ingress, Gateway API, and Kong-specific CRDs like KongIngress, KongPlugin, KongConsumer, etc.

From NGINX land: Some patterns feel familiar, but using CRDs + labels/annotations instead of pure annotation config is the healthier way.

Complexity: Once you step into the plugin ecosystem, the config surface gets large—this is its biggest strength and also complexity source.

Simple HTTPRoute + plugin example:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  annotations:
    konghq.com/plugins: rate-limit
spec:
  parentRefs:
    - name: kong-gw
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-svc
          port: 80
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit
config:
  second: 10
plugin: rate-limiting

Contour

Support: Ingress, HTTPProxy CRD, plus Gateway API support.

From NGINX land: Instead of annotations everywhere, you use HTTPProxy objects. At first it feels like “too many CRDs,” but readability increases a lot.

Complexity: HTTPProxy brings a lot of power; the trade-off is more YAML.

Example HTTPProxy:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: web
  namespace: prod
spec:
  virtualhost:
    fqdn: web.example.com
  routes:
    - conditions:
        - prefix: /
      services:
        - name: web-svc
          port: 80

Pomerium Ingress Controller

Support: Ingress + Pomerium CRDs, with Gateway API support as well.

From NGINX land: The main object here is “policy”: you declare who can access what and under which conditions on a host.

Complexity: Less about L7 routing, more about “who is allowed to get in”. Network folks might shrug; security folks will smile.

Example Pomerium policy (simplified):

apiVersion: pomerium.io/v1
kind: PomeriumPolicy
metadata:
  name: web-policy
spec:
  from: https://web.example.com
  to: http://web-svc.prod.svc.cluster.local:80
  allow:
    - email: [email protected]

kgateway

Support: Gateway API is the primary interface; Envoy policy and routing behavior is mainly managed via Gateway API objects plus additional CRDs.

From NGINX land: You don’t “translate annotations”; you jump to a different generation—pure Gateway API thinking.

Complexity: The feature set is broad, but the resource model is clean and aligned with Gateway API (GatewayClass, Gateway, HTTPRoute, etc.).

Istio Ingress Gateway

Support: Istio Gateway + VirtualService + DestinationRule CRDs, and Gateway API.

From NGINX land: You move from “one Ingress object for everything” to “Gateway + VirtualService + DestinationRule + Policy + …”

Complexity: Extremely powerful, extremely detailed. Seeing a wrong VirtualService may cause a slight blood pressure drop in some SREs.

Simple Istio Gateway + VirtualService:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: web-gw
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - web.example.com
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: web
spec:
  hosts:
    - web.example.com
  http:
    - route:
        - destination:
            host: web-svc
            port:
              number: 80

Cilium Ingress / Gateway

Support: Ingress and Gateway API (HTTPRoute, GRPCRoute, etc.) for modern traffic management.

From NGINX land: If you’re already on Cilium CNI, moving directly to Gateway API via Cilium Gateway is natural.

Complexity: Managing both networking and L7 together is powerful but mentally heavy; you’re not “just installing an ingress controller.”

3. Protocol & Traffic Support

Here we ask:

“Is it just HTTP, or does it handle TCP/UDP, gRPC, WebSocket, HTTP/3, mTLS, etc. naturally?”

Traefik

Supports HTTP/1.1, HTTP/2, WebSocket, gRPC, and with newer versions, HTTP/3 / QUIC as well.

TCP/UDP routing is possible, but its real strength is L7/HTTP.

Supports mTLS, TLS passthrough, SNI-based routing, etc.

HAProxy Ingress Controller

With HAProxy under the hood, you get full TCP/L4 capabilities: HTTP, TCP, TLS termination, raw TCP load balancing, and so on.

WebSocket, HTTP/2, gRPC proxying are supported; configuration is usually controlled via annotations/ConfigMaps.

Great candidate if you want to offload heavy L4 workloads into the cluster.

Kong Ingress Controller

Strong support for HTTP/1.1, HTTP/2, WebSocket, gRPC and even TCP/UDP; with Gateway API you can model this with different Route types.

mTLS, mutual authentication, and client certificate verification are provided via plugins such as mtls-auth.

Contour

Thanks to Envoy, you get HTTP/1.1, HTTP/2, gRPC, WebSocket, TLS termination out of the box. For pure TCP/UDP you usually rely on a separate load balancer.

With HTTPProxy you have powerful SNI and header-based HTTP routing.

Pomerium

Focus is on HTTP(S) traffic and identity-based authorization. If you want TCP/UDP, you typically layer another tool for that.

Strong in mTLS, identity, and OIDC integration.

kgateway

Envoy-based, so HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP/TLS are all supported and controllable through Gateway API.

Also positions itself for “modern” traffic such as AI/LLM requests, with special routing/rate limiting scenarios.

Istio Ingress Gateway

Handles HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP, mTLS, SNI—you name it.

Since it’s tied into the mesh, you also get the same protocol richness for east-west traffic inside the cluster.

Cilium Ingress / Gateway

With Gateway API you can manage HTTP, gRPC, TLS, TCP routing; GRPCRoute lets you do method-level routing.

Underneath, eBPF handles L3/L4 efficiently while Envoy gives you rich L7 capabilities.

4. Traffic Management & Advanced Routing

Here are the fun bits:

Canary, blue-green, A/B testing, weight-based routing, header-based routing…

Traefik

Supports path/host-based routing, header-based routing, weight-based routing for canary, and request mirroring.

More powerful than basic Ingress, but not as policy-crazy as Istio / Kong.

HAProxy Ingress

Offers path/host/header-based L7 routing, and advanced L4 load balancing on the HAProxy side.

Canary / blue-green are possible but usually involve more manual config.

Kong Ingress Controller

First-class canary, blue-green, and A/B testing with weight-based routing and related plugins.

As an API gateway, it also brings rate limiting, circuit breaking, request/response transformation, etc.

Contour

HTTPProxy offers weight-based routing, header-based routing, subdomain/path routing.

Canary and blue-green setups are straightforward and readable using the HTTPProxy CRD.

Pomerium

Main job is “who can get in” rather than “how do we split traffic.”

For canary/blue-green, you’d typically offload traffic management to another L7 proxy and let Pomerium handle identity/policy.

kgateway

Envoy + Gateway API = advanced traffic management, including modern scenarios like multi-region AI traffic, LLM cost control, rate limiting, etc.

Istio Ingress Gateway

Canary, blue-green, A/B testing, traffic mirroring, fault injection—all your SRE case studies live here.

One of the richest options for traffic management; the price is complexity.

Cilium Ingress / Gateway

Uses Gateway API for weight-based routing, path/host routing, and with GRPCRoute you can route by gRPC method.

Since Cilium is also a service mesh, you can define advanced policies mesh-side and integrate them with the gateway.

Example: Simple Canary with Istio

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: web
spec:
  hosts:
    - web.example.com
  http:
    - route:
        - destination:
            host: web-svc
            subset: v1
          weight: 90
        - destination:
            host: web-svc
            subset: v2
          weight: 10

This YAML says: “Let’s send 10% to v2, check if the world burns, then gradually crank it up.”

5. Security Features

mTLS, JWT, OAuth/OIDC integration, IP allow/deny lists, WAF, rate limiting, etc.

Traefik

Built-in Let’s Encrypt integration, TLS/mTLS, IP allow/deny, rate limiting, basic auth, forward auth via middlewares.

WAF scenarios can be handled via Coraza WAF integration.

HAProxy Ingress

TLS termination, SNI, client certificate verification, rate limiting, classic HAProxy security features brought into the ingress world.

WAF is usually an external or enterprise HAProxy feature.

Kong Ingress Controller

JWT, OAuth2, key-auth, mTLS, rate limiting, ACL, IP restriction, bot detection, WAF integrations… Security is plugin heaven here.

If you want “API gateway + ingress + centralized security policies,” Kong is one of the strongest options.

Very simplified JWT validation example:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: jwt-auth
plugin: jwt
config:
  uri_param_names:
    - jwt
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  annotations:
    konghq.com/plugins: jwt-auth
...

Contour

Envoy-based, so you inherit mTLS, SNI, TLS policies and AuthService/ext_authz integrations.

You can plug in external identity providers and WAF tools via Envoy filters.

Pomerium

Full “security nerd” mode: context-aware access, mTLS, OIDC, SSO, device/location-aware policy, Zero Trust approach.

Ideal for VPN-less access to internal apps, “only corporate laptops allowed,” etc.

kgateway

Envoy security (mTLS, JWT, OAuth, WAF) plus Gateway API-based policy modeling gives you a modern security layer at the edge.

Istio Ingress Gateway

Together with the mesh you can have mTLS by default cluster-wide.

JWT validation, request authentication, and AuthorizationPolicy-based RBAC—all built-in.

Cilium

eBPF-based network policy + Envoy L7 policy combine to provide strong security at L3/L4 and L7.

When used with Cilium service mesh, mTLS and identity-based policies become powerful.

6. Observability

The part where SRE hearts are either broken or healed:

Prometheus metrics, Grafana dashboards, tracing, access logs…

Traefik

Prometheus metrics, access logs, OpenTelemetry integration.

For small/medium scale, it gives you a good picture of “what’s happening on the edge.”

HAProxy Ingress

HAProxy’s legendary stats page plus Prometheus exporter and access logs.

Great for detailed L4/L7 connection metrics.

Kong

Prometheus metrics, log targets (Elastic, Loki, etc.), tracing integrations; Enterprise adds even more observability options.

Contour

Envoy metrics + Contour metrics; plenty of Grafana dashboards floating around.

Pomerium

Detailed audit logs and policy-level visibility for identity/access flows.

Very useful if your main question is “who did what, from where, and when”.

kgateway

Envoy + modern gateway ecosystem = OpenTelemetry, Prometheus, and structured logs all in one place.

Istio

Telemetry v2 provides extremely rich metrics, logs, and tracing. The Ingress Gateway is part of that same telemetry system.

Cilium

eBPF gives you flow-level metrics, policy hits, dropped packets; Envoy adds L7 metrics on top.

If you want to deeply understand what’s flowing across your cluster, it’s one of the best.

7. Performance & Resource Usage

Touchy subject—everyone claims to be the fastest. Let’s stay high-level and focus on general patterns plus some public benchmarks that compare configuration update times and latency.

From public Gateway API benchmarks, a few patterns:

Cilium, Istio, Kong stand out in terms of configuration update latency and responsiveness.

kgateway and NGINX-based solutions land in the middle.

Traefik often appears among the slower ones regarding config update latency.

This is mostly about control-plane / config application speed. Data-plane throughput is another dimension, but the results still show some interesting trends.

Traefik

Proxy type: L7-focused reverse proxy.

General feel: Config updates are somewhat heavier than some rivals, but in small/medium loads it’s not a big issue.

HAProxy Ingress

Proxy type: L4 + L7, benefiting from HAProxy’s well-known performance.

General feel: Very effective under high concurrency; just manage resource limits carefully.

Kong

Proxy type: NGINX/OpenResty-based L7 gateway with TCP/UDP support.

General feel: In API gateway scenarios, strong throughput and solid latency.

Contour

Proxy type: Envoy; modern high-performance L7 proxy.

General feel: Lightweight control-plane (Contour) with a strong data-plane (Envoy).

Pomerium

Proxy type: Identity-aware HTTP proxy.

General feel: You are paying for “inspect every request through policy,” which is expected; the value is in security, not raw throughput.

kgateway

Proxy type: Envoy, tuned for API gateway/microgateway and service/multi-mesh scenarios.

General feel: Built to handle large-scale, complex traffic management.

Istio

Proxy type: Envoy sidecar everywhere plus an Envoy Ingress Gateway.

General feel: Sidecars and extra hops do add overhead, but in return you get security and observability, which many enterprises find totally worth it.

Cilium

Proxy type: eBPF for L3/L4, Envoy for L7.

General feel: Excellent latency/throughput thanks to kernel-space optimizations and advanced L7 capabilities on top.

8. Installation & Community Support

We look at Helm charts, Operators, docs quality, GitHub activity, and enterprise support.

Traefik

Install: Helm charts, Operator, good Gateway API documentation.

Community: Very active; Traefik Labs blogs and Gateway API investments are strong.

HAProxy Ingress

Install: Helm charts and YAML manifests; both Community and Enterprise variants exist.

Community: HAProxy itself has a big community; the Kubernetes-specific bits are solid but not as mainstream as NGINX.

Kong

Install: Helm charts, KIC documentation, and managed options via Kong Konnect.

Community: Very active OSS + Enterprise user base; widely used in large companies.

Contour

Install: Helm, manifests, and detailed guides for enabling Gateway API.

Community: CNCF project; close ties with the Envoy ecosystem.

Pomerium

Install: Helm charts, identity-focused docs, cert-manager/Gateway API integration guides.

Community: Popular in security and Zero Trust circles.

kgateway

Install: Official quickstarts and docs focused on Envoy + Gateway API setups.

Community: Builds on the Gloo heritage and integrates with CNCF / Gateway API ecosystem; quickly growing.

Istio

Install: istioctl, Helm, ambient/sidecar modes; a huge documentation set.

Community: CNCF heavyweight; widely adopted in both research and industry.

Cilium

Install: One stack for CNI + service mesh + gateway; Helm charts and very detailed blogs and guides.

Community: Star of the CNI world; serious investments into Gateway API as well.

9. Ecosystem & Compatibility

Cloud vendor integrations, compatibility with other CNCF projects, plugin/extensions…

All of them work on AKS/EKS/GKE and other managed Kubernetes offerings because they’re plain Kubernetes controllers/CRDs.

The Gateway API itself is designed to be vendor-neutral and role-oriented, so these implementations are meant to coexist nicely.

Traefik

Works nicely on bare-metal, on-prem, and all major clouds.

Middleware concept (rate limiting, auth, WAF integration, etc.) acts as a lightweight plugin model.

HAProxy Ingress

HAProxy runs everywhere; Kubernetes integration is multi-cloud friendly.

Particularly useful when you want to offload complex TCP/UDP traffic from cloud load balancers.

Kong

Can be used as Kubernetes ingress/gateway or as a classical API gateway on VMs; great for hybrid and multi-cloud.

Plugin ecosystem brings integrations for observability, security, transformations, and many third-party systems.

Contour

Envoy-powered; plays well with Istio, Cilium, and other Envoy-based projects.

Pomerium

Deep integrations with identity providers (OIDC, SAML, Google Workspace, etc.); can protect non-Kubernetes apps as well.

kgateway

Aims to be one of the reference implementations of a modern Gateway API-based Envoy controller.

Positioned to work well with multiple meshes and cloud environments.

Istio

Integrates tightly with Envoy, Prometheus, Jaeger/Tempo, Kiali, Grafana, and many CNCF tools.

Cilium

CNI + mesh + gateway = you’re effectively buying most of your Kubernetes networking/security stack from one provider, while still integrating with lots of CNCF projects.

10. Future-Proofing & Roadmap

This is the “Will I still sleep well 3–5 years from now?” section.

Ingress API is stable but limited, and its heavy reliance on annotations has become a common pain point.

Gateway API is the “next generation” replacement for Ingress, designed to be more expressive, role-based, and vendor-neutral.

The ingress-nginx project is sliding into EOL territory in the coming years, which pushes the ecosystem naturally towards Gateway API + newer controllers.

In that picture:

Tools that are Gateway API first (kgateway, Cilium, Istio, Traefik, Kong, Contour, Pomerium, HAProxy) look like the safest long-term bets.

Mesh-centric ecosystems like Istio and Cilium will likely keep pushing the “service mesh + gateway + security + observability” package approach.

kgateway is clearly aiming for the future with Envoy + Gateway API + AI/LLM gateway capabilities.

In short:

The future is Gateway API, and the winners are going to be the stacks that combine Envoy/eBPF with strong, flexible control-planes.

Scoring Scale

Before we dive into the big table, let’s define the scale:

1 → “Please don’t try this in prod.”

2 → “Fine for a PoC, but think twice before prod.”

3 → “It works, but you’ll sweat a bit.”

4 → “Solid choice, even for serious environments.”

5 → “Ship it to prod and don’t look back too often.”

This is subjective, but rooted in the analysis above.

Comparison Table (1–5)

Note: These are general evaluations. For specific use-cases, scores can shift (e.g. if you’re purely doing identity-aware access, Pomerium gets an automatic +1 in your context).
"

Tool	Controller Architecture	Config Simplicity	Protocol & Traffic	Traffic Management	Security	Observability	Performance & Resource	Install Simplicity	Ecosystem & Community	Future-Proofing
Traefik	4	4	4	3	3	4	3	4	4	4
HAProxy Ingress	4	3	4	3	3	3	4	3	3	3
Kong Ingress	4	3	5	5	5	4	4	3	5	5
Contour	4	3	4	4	4	4	4	3	4	4
Pomerium Ingress	3	3	3	2	5	4	3	3	4	4
kgateway	5	3	5	5	4	4	4	3	4	5
Istio Ingress Gateway	5	2	5	5	5	5	4	2	5	5
Cilium Ingress/Gateway	5	3	5	4	4	5	5	3	5	5

Quick notes:

Traefik – Easy to learn, flexible, playing nicely with Gateway API; might feel a bit “light” if you want super-advanced traffic policies.

HAProxy Ingress – Performance beast, especially for TCP/L4; annotation-centric config gives slight “old school” vibes.

Kong – If you want “Ingress + API Gateway + security + plugins,” it’s very compelling; the trade-off is complexity.

Contour – Nice option if you want Envoy power with a clean, focused control-plane and HTTPProxy.

Pomerium – Less of an ingress and more of an “identity-aware secure front door”; a joker card for SSO/Zero Trust.

kgateway – Rising star of the Gateway API era; Envoy + modular control-plane + AI/LLM features make it very future-leaning.

Istio – If you want everything—mesh, mTLS, canary, observability—this is one of the strongest packages, and also one of the hardest to master.

Cilium – If you want networking + security + gateway all in an eBPF-powered stack, it’s a very strong long-term investment.

Closing Thoughts

With NGINX Ingress walking toward EOL, the good news is:

You have many options, and they’re not just Ingress controllers—they’re doorways into a world of Gateway API + mesh + security.

As a rough compass:

For a simple but modern ingress: Traefik, Contour, HAProxy Ingress

For Ingress + API Gateway + plugins galore: Kong, kgateway

For “mesh everything, secure everything”: Istio, Cilium

For VPN-less, Zero Trust front door: Pomerium

The rest depends on your system’s complexity, your team’s patience, and who you’d like to blame when the pager goes off at 3 AM.