High Availability Deployment of Nginx Gateway Fabric Replacing Retired Ingress Nginx in AKS - Part 1 - Plan for Smooth Transition

 We have discussed setting up ingress-nginx as ingress controller for AKS previously. Ingress-nginx for kubernetes is retiring in March 2026 as announced here in github and in kubernetes documentation. Gateway API is the recommended replacement for ingress-nginx and Nginx Gateway Fabric is an implementation of Gateway API by Nginx. When you have true blue-green deployments with new AKS cluster getting created at each deployment, transitioning from ingress-nginx to nginx gateway fabric is relatively simpler, and we can discuss that in the last blog of this blob post series. However, when you have a single AKS cluster (situations such as hosting elastic search on AKS demands, we use only a single AKS cluster - we will discuss this topic in a later blog series), where blue-green deployments happen using node pools and cluster upgrades as inplace upgrades, the transtion needs to be done over multiple releases to achive zero down time deployments for production. In this blog, let's plan how we can get the transition done in a step by step manner.

The expectation is to get nginx-gateway setup as shown below, so that HTTP routes can be setup via the gateway.

 The current situation example

• There is AKS custer setup to host elastic search. 
• Blue-green pipeline deployments setup within AKS cluster, with node pools having constraints for blue and green transtions.
• Ingress-nginx used as ingress controller
• Private DNS is setup with internal vNET IP which is used as ingess-nginx load balancer IP. Refer here it is similar setup used within single AKS cluster. 
• With host name of private DNS a record used in route setup for elastic kibana and elastic search access as shown below.

---

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: es-search-ingress

  namespace: elastic-stack

  annotations:

    nginx.ingress.kubernetes.io/ssl-redirect: "false"

    nginx.ingress.kubernetes.io/proxy-body-size: 4g

    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-send-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-read-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-max-temp-file-size: "0"

spec:

  ingressClassName: nginx

  rules:

    - host: es-search${sys_sh_svc_deploy_dns_zone}$

      http:

        paths:

          - path: /

            pathType: Prefix

            backend:

              service:

                name: es-search-es-http

                port:

                  number: 9200

---

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: es-kibana-ingress

  namespace: elastic-stack

  annotations:

    nginx.ingress.kubernetes.io/ssl-redirect: "false"

    nginx.ingress.kubernetes.io/proxy-body-size: 4g

    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-send-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-read-timeout: "30"

    nginx.ingress.kubernetes.io/proxy-max-temp-file-size: "0"

spec:

  ingressClassName: nginx

  rules:

    - host: es-kibana${sys_sh_svc_deploy_dns_zone}$

      http:

        paths:

          - path: /

            pathType: Prefix

            backend:

              service:

                name: es-kibana-kb-http

                port:

                  number: 5601

The plan for single AKS cluster tansition

1. Deploy nginx-gateway and route setup in release 1, while keeping ingress-nginx as is. See the next blog - part 2 and 3 of this series.
2. Deploy release 2 to switch private IP of nginx-gateway in private DNS zone A record so traffic starts to route via ngins-gateway.
3. Remove ingress-nginx with release 3. Step 2 and three is covered in Part 4 of this blog series.

The plan for true blue-green and new AKS clsuter to use nginx-gateway

• Replace ingress-nginx with nginx-gateway deployment. We will discuss this in Part 4 of this blog series.