Use the Istio API Gateway, you must (end of NGINX Ingress Controller support)

For the last decade, we have exposed our services on Kubernetes through the NGINX Ingress Controller. Big news: in 2026, the service will stop and won’t be officially supported anymore.

So what to do? Let Master Yoda answer that question.

“Use the Istio API Gateway, you must” — Yoda, Jedi

What is an API Gateway?

First, let’s take a tour of the list of cons and pros of API Gateways in general. If you’re new and wondering why you should choose one or the other, you’re in the right place.

What were we using Ingress Controller for?

When you only need to deploy a web service on your Kubernetes cluster and expose the entire service on a certain port, the Ingress Controller is easy to use and will do the job. For example, if you have a REST API that you need to put behind app.domain.co, then the Ingress Controller will provide an Ingress object that will expose it for you.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: specific-namespace
spec:
  ingressClassName: nginx
  rules:
    - host: app.domain.co
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-clusterip
                port:
                  number: 80
  tls:
    - hosts:
        - app.domain.co
      secretName: cert-tls

But what if you want to get more security and greater control? You’ll need a new system for it. That is where an API Gateway becomes helpful.

New protocols

Ingress controllers mainly manage HTTP / HTTPS protocols, even though some can currently handle UDP / TCP protocols. With API Gateway, you can see the world in a very different way :

• gRPC, for high-performance and open-source Remote Procedure Call (RPC) framework.
• WebSockets, bi-directional communication channel on a single TCP connection that allows you to share data from your webapp to your backend without having to refresh — for example.

Management on specific routes (& auth integration)

Most API Gateway systems provide their own API for security purposes. You’ll find everything you need: OAuth2, JWT, API keys, mTLS, WAF.

With an API Gateway, you don’t have to expose the entire application. You can choose which routes to expose, which routes to secure and which route to block.

Here is an example of VirtualService you can create for managing the routes :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-vs
  namespace: specific-namespace
spec:
  hosts:
    - app.domain.co
  gateways:
    - api-gateway
  http:
    - match:
        - uri:
            prefix: "/blocked"
      fault:
        abort:
          httpStatus: 403
          percentage:
            value: 100
    - match:
        - uri:
            prefix: "/public"
      route:
        - destination:
            host: api-clusterip
            port:
              number: 80
    - match:
        - uri:
            prefix: "/private"
      route:
        - destination:
            host: api-clusterip
            port:
              number: 80

And then, you just have to expose the service with anad IngressGateway :

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: api-gateway
  namespace: specific-namespace
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - app.domain.co
      tls:
        mode: SIMPLE
        credentialName: cert-tls  

Integrate monitoring

In my case, I mainly used Istio as an API Gateway. And one of my favorite parts of Istio is that it comes with its own Prometheus that records all the logs and communications between your services. As I already wrote about this, I let you read this article (free if you come from my LinkedIn 💚).

Is Istio the only alternative?

Of course it isn’t! And as a good DevOps engineer, you want to see all the alternatives before launching your migration. That makes sense! 💪

So here are the links to different mesh services that also provide API Gateway :

• Linkerd, maybe the first alternative you’ll find during your research. It has an enterprise proposition for your most critical services. It can integrate with the official Kubernetes Gateway API. (link)
• Traefik Cloud Native API Gateway, a very popular competitor to NGINX as an Ingress Controller, Traefik also have its own Mesh service and its own API Gateway. (link)
• Kong Gateway, I really like their API for managing the configurations and the fact that everything is stored in a specific database (PSQL) (link). I wrote an article about that. 🐳

I hope this article helps you understand why the end of the NGINX Ingress Controller support is not that bad. You’ll need to prepare a bit, and then your infrastructure can only feel better! 👌

For the Netflix of applications: Odin by Caelus 🌳🚀

Sources :

• Kubernetes.io
• Istio docs