Advisory / Further Guidance on Community Ingress-NGINX Retirement and Self-Managed Runtime Fabric (RTF)

Runtime Fabric on Self-Managed Kubernetes continues to offer support for Ingress Templates and has added support for Kubernetes Gateway API starting v2.9.2 released on January 25, 2025. This offers customers the freedom to choose an alternate Ingress Controller or a Gateway API controller. Here are a the details of the level of support we offer:

• Compatibility: Runtime Fabric supports any Ingress/Gateway API controller that adheres to standard Kubernetes specifications.

• Responsibility: The selection, installation, configuration, and lifecycle management of the Controller (including migrating away from deprecated solutions) are the sole responsibility of the customer. 

The following section provides guidance to the customers on possible migration paths. 

Migration Paths Summary

Customers currently utilizing the community ingress-nginx controller should plan to migrate to a supported alternative. Starting March 2026 EOL, ingress-nginx controller would stop getting regular fixes and security patches. However, this would not impact your running applications and would not cut your application connectivity. Still, you would not want to run a deprecated solution for long. So, you must plan your migration path now.  

As Runtime Fabric offers full support for Ingress resource and GatewayAPI resource, you have both possible migration paths fully supported by Runtime Fabric. Let’s look at them one by one. 

Option A: Replace with different Ingress Controller

You can swap NGINX Ingress Controller for any compliant alternative that meets your organization's architectural and security standards. 

• The primary benefit of this option is that you would not have to extensively rework your Ingress or HTTP Route templates. However, we do want to caution you that annotations and regex expressions may work differently for your alternate controller than nginx-ingress controller, which could require deeper investigation to ensure everything works as expected. 

• The downside of this option is that GatewayAPI is considered the long-term path. It offers many benefits over Ingress as highlighted in the official Kubernetes documentation. Choosing option B gives you those benefits right away. 

Option B: Replace with GatewayAPI and compatible controller

You can move to Gateway API and a controller that supports it. Note that NginX has a GatewayAPI controller that is not impacted by this EOL announcement.   

• The primary benefit of this option is that it is more future-proof. While there is no announcement that Kubernetes would end support for Ingress templates, they have been positioning GatewayAPI as the long-term solution. 

• The downside of this option is that it is a more extensive migration path. You would have to convert your Ingress templates to Mulesoft provided HTTP Route templates. This is a Kubernetes Custom Resource that allows you to use GatewayAPI specifications for HTTP/HTTPS routes. You would have to translate the annotations into the native functionalities offered by GatewayAPI, and deploy a new Controller that manages the GatewayAPI resources. 

Verdict

• If you already have expertise of running GatewayAPI and Controllers or even Istio that has its own APIs for defining “Ingress” (called Virtual Services) in your wider organization, then directly migrating to it would get you ready for the future now. 

• If not, then replacing NginX with a different Ingress Controller would be the safer choice, given the time-crunch. You may choose HAProxy, another open source solution similar to NginX, or choose a paid third-party solution such as F5/NginX or Terrafik.  

Make Migration Seamless

Whether you can have a zero-downtime migration depends on the option you choose, your current architecture, and the approach you take during the migration. 

Option A: Replace with different Ingress Controller

With this option, you need to make sure that the annotations and paths are converted as per your chosen alternate Ingress Controller in the Ingress template.You would have to restart the applications that would trigger RTF to identify the change in Ingress Class Name defined in your revised Ingress Template. Your existing Ingress configuration on Runtime Manager should work as is. 

While Mulesoft cannot provide prescriptive guidance, here is the high-level description of what different migration options are available to you. 

• For one-shot migration, you deploy a new Ingress Controller, rewrite Ingress Templates that reflect the Ingress Class Name,and restart your applications. This would automatically allow RTF agent to create new Ingress Resources for your applications. You can then terminate the older Ingress Template and controller. 

• For a Canary style migration, you need to keep both controllers running in parallel, and manage traffic-shift between them, for example using DNS record names or Load Balancer routing depending on your architecture. To do this, you need to adopt the Mulesfoft CRD for HTTP Route templates. As part of this template, you would define the Ingress specification for both your nginx and new Ingress Controller, as shown below:

apiVersion: rtf.mulesoft.com/v1

kind: HTTPRouteTemplate

metadata:

  name: example-template-ingress

  namespace: rtf

spec:

  baseEndpoints:

    - https://*.example.com

    - https://example.com

  resources:

    - |

      apiVersion: networking.k8s.io/v1

      kind: Ingress

      metadata:

        name: {{ .ResourceName }}

        namespace: {{ .Namespace }}

        labels:

        annotations:

      spec:

       ingressClassName: nginx

       tls:

       - hosts:

         - {{ .Host }}

         secretName: testsecret-tls

       rules:

       - host: {{ .Host }}

         http:

            paths:

            - pathType: Prefix

              path: {{ .Path }} 

              backend:

                service:

                  name: {{ .Service.Name }}

                  port:

                    name: {{ .Service.PortName }}

    - |

      apiVersion: networking.k8s.io/v1

      kind: Ingress

      metadata:

        name: {{ .ResourceName }}

        namespace: {{ .Namespace }}

        labels:

        annotations:

      spec:

       ingressClassName: nginx-replacement

       tls:

       - hosts:

         - {{ .Host }}

         secretName: testsecret-tls

       rules:

       - host: {{ .Host }}

         http:

            paths:

            - pathType: Prefix

              path: {{ .Path }} 

              backend:

                service:

                  name: {{ .Service.Name }}

                  port:

                    name: {{ .Service.PortName }}

Option B: Replace with GatewayAPI based controllers

With this option, you would have to create Mulesoft CRD for HTTP Route template, and restart your applications. 

• For one-shot migration, you deploy the Gateway API controller, restart your applications, and shift traffic to the new controller. Post that, you can terminate the existing Ingress Template and controller. 

• For a Canary style migration, you keep both controllers running in parallel, and manage traffic-shift between them using DNS record names or Load Balancer routing. The specific option would depend on your architecture. For this, when creating your HTTP Route templates, you would have to write both Kubernetes Ingress specs and Kubernetes GatewayAPI’s HTTP Route spec in a single HTTP Route Template. You then delete your current Ingress Template and restart your applications. Once you have shifted the traffic to new controller, you can terminate the Nginx controller from your cluster.  

Here is an example:

apiVersion: rtf.mulesoft.com/v1

kind: HTTPRouteTemplate

metadata:

  name: example-template-ingress

  namespace: rtf

spec:

  baseEndpoints:

    - https://*.example.com

    - https://example.com

  resources:

    - |

      apiVersion: networking.k8s.io/v1

      kind: Ingress

      metadata:

        name: {{ .ResourceName }}

        namespace: {{ .Namespace }}

        labels:

        annotations:

      spec:

       ingressClassName: nginx

       tls:

       - hosts:

         - {{ .Host }}

         secretName: testsecret-tls

       rules:

       - host: {{ .Host }}

         http:

            paths:

            - pathType: Prefix

              path: {{ .Path }} 

              backend:

                service:

                  name: {{ .Service.Name }}

                  port:

                    name: {{ .Service.PortName }}

    - |

      apiVersion: gateway.networking.k8s.io/v1

      kind: HTTPRoute

      metadata:

        name: {{ .ResourceName }}

        namespace: {{ .Namespace }}

      spec:

        parentRefs:

          - kind: Gateway

            name: cluster-gateway #name of the Gateway resource

        hostnames:

          - {{ .Host }}

        rules:

          - matches:

              - path:

                  type: PathPrefix

                  value: {{ .Path }}

            backendRefs:

              - name: {{ .Service.Name }}

                port: {{ .Service.Port }}

Feeling Unsure about the migration?

If you need deeper engagement, we recommend you contact your MuleSoft Account Team or Customer Success Manager (CSM) to coordinate an engagement with  MuleSoft Professional Services.