Live AMA: Transitioning to the Open Source NGINX Ingress Controller from ingress-nginx - Dec 10, 11

Announcements
,
1

:rocket: NGINX is hosting our first AMA, right here on our community forum, right here on this thread!

Two live sessions to accommodate for global timezones:
:spiral_calendar: December 10th, 2025 from 10:00-11:30 PT
:spiral_calendar: December 11th, 2025 from 14:00-15:30 GMT

We’re clearing our calendars, grabbing a comfortable seat, and sitting down together to answer any of your questions about our open source NGINX Ingress Controller, Gateway API implementation through NGINX Gateway Fabric, and alternatives for migrating from ingress-nginx. Our product and engineering experts will be available to answer your questions in real time to help you make the right decision for your Kubernetes workload.

The Kubernetes ecosystem is evolving, and with ingress-nginx retiring in March 2026, many teams are planning their next steps. We’ve heard a lot of questions so we’re here to help and to clear up the confusion. As highlighted in our recent blog post, we hope you will consider the (open source!) NGINX Ingress Controller for your migration.

Join the AMA to Ask Us About

  • The open source roadmap for NGINX Ingress Controller and future plans

  • Migration options from ingress-nginx to the NGINX Ingress Controller or NGINX Gateway Fabric (Gateway API)

  • Choosing Ingress vs. Gateway API for your Kubernetes workloads

  • Our Gateway API implementation through our open source NGINX Gateway Fabric

  • Technical details, and best practice, and tips

  • Anything else related (within reason!)

How To Participate

:one: Ask your questions in advance or in real time, right here in this thread
:two: Leave a :heart: or :rocket: react to questions you’d like us to prioritize
:three: Join a live session (or both) for the real-time conversation
:four: Come back and catch up if you missed it

Anyone can view the AMA, but you must have an account on this forum to interact with the posts.

The AMA is now open for questions. Go ahead and drop your questions below! Use the :heart: or other reacts to the other questions you want answered, too. We’re prioritizing the questions based on interest, so this helps us gauge community priorities.

Please keep your questions here on the AMA instead of starting new topics. We are saving our answers for the live sessions! (That being said, if you need technical help now for your migration, head over to the Projects > NGINX Ingress Controller and Projects > NGINX Gateway Fabric categories to get sorted.)

We’re looking forward to the hard questions. See you there!

8 Likes
NGINX Gateway Fabric Community Meeting
Nginx Ingress controller proxy headers set
3

Thanks for doing this! Great timing :slight_smile:

My current ingress-nginx config has two ingresses, one with SSO which uses oauth2-proxy, and another that uses mTLS for the API based endpoint.

For the SSO-based one, these are my annotations:

  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/app-root: /opennms/
    nginx.ingress.kubernetes.io/auth-signin: "https://oauthproxy.myprovider.com/oauth2/start"
    nginx.ingress.kubernetes.io/auth-url: "https://oauthproxy.myprovider.com/oauth2/auth"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "240"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "240"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "240"
    nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-email, x-auth-request-user"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_clear_input_headers "x-auth-request-preferred-username";
      more_clear_input_headers "x-auth-request-user";
      more_clear_input_headers "x-remote-roles";

And for the mTLS one:

  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "240"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "240"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "240"
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "opennms/client-ca"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_clear_input_headers "x-auth-request-preferred-username";
      more_clear_input_headers "x-remote-roles";

Which of the two (NGINX Ingress controller of NGINX Gateway Fabric) would you recommend to manage the above?

3 Likes
4

Hi @dxiri ,
thanks for commenting.

We’ll get back to you shortly with the recommended approach.

2 Likes
5

I’ve noticed recent pull requests in the nginx/kubernetes-ingress repository that appear to be adding annotation support for directives that have long been available in the community kubernetes/ingress-nginx project.

For example, PR #8548 introduces support for nginx.org/client-body-buffer-size as both an Ingress annotation and a ConfigMap key—functionality that mirrors what ingress-nginx has offered through its own annotation scheme.

Is achieving feature parity with the community ingress-nginx annotations part of your roadmap? If so, is there a tracking issue or documentation outlining which annotations are planned for implementation?

1 Like
7

Is there any migration tips for external authentication? Annotations - Ingress-Nginx Controller

We have multiple teams who use these annotations for their Ingresses.

2 Likes
9

Hi Benjamin! You can use snippets to enable auth_request. You can use the nginx.org/location-snippets annotation or nginx.org/server-snippets depending if you want it in the server context or location context.

3 Likes
10

For the mTLS one, we recommend using our CRDs. Those annotations specifically configure ingressmTLS. This can be configured from our docs here – Policy resources | NGINX Documentation

3 Likes
12

Thanks Amir. We’re a bit concerned about using snippets – we wouldn’t really want to open ourselves to the risk where our users can create a snippet that can potentially bring down our cluster-wide ingress controller. Is there something more built in by chance or can such a feature be prioritized to be built in?

1 Like
13

Hi Diego.

Thanks for the question!

You are correct. We actually just released 5.3.0, and added support for the following annotations, with more to come in later release.

More info on the release: Changelog | NGINX Documentation

Let us know if there are any specific annotations that are missing.

Micheal

4 Likes
14

Is ssl passthrough supported ?

What is the use of virtual server crd?

2 Likes
15

Question from Reddit that did not make it over to this thread:

My question in advance: Do you have any plan to replace the .conf files with more readable format like yml or toml.
I find the conf format very messy, especially when you have multiple of them.

16

Additionally to what @Amir_Rawdat said, NGINX Ingress Controller also has a few authentication schemes implemented as policy resources:

Some of these are in the commercial version of NIC (OIDC, JWT, JWKS).

We do have plans to add / implement more external auth methods. If you’d like to help us shape how we implement these, you can start a discussion on our GitHub repository, and we can go from there: nginx/kubernetes-ingress · Discussions · GitHub

2 Likes
17

I’m also curious - what does the migration path from the Ingress Controller to the Gateway Fabric look like (i.e. migrating from Ingress API to Gateway API)? Are there feature parity between the two? I’m aware of Migrate from NGINX Ingress Controller to NGINX Gateway Fabric | NGINX Documentation but taking a quick look at ingress2gateway/pkg/i2gw/providers/nginx/README.md at 162caab61d37ad1fb568fdf544a3366d4b017a85 · kubernetes-sigs/ingress2gateway · GitHub seems like only a handful of annotations are compatible for migration.

1 Like
18

Is it possible to deploy f5 ingress controller without crd ?

We use a lot of tcp udp apps and depend on configmap approach of open-source ingress-nginx, which was easier to configure.

2 Likes
20

I can take part of this: per the docs, the Virtual Server resource:

VirtualServer and VirtualServerRoute resources are load balancing configurations recommended as an alternative to the Ingress resource.

They enable use cases not supported with the Ingress resource, such as traffic splitting and advanced content-based routing.

1 Like
21

Hello bmv126!
Yes, you can opt out of installing CRDs passing in a command line argument during install.
You can find the command line argument to disable located on our docs page here:

Hope that helps!

Jason

3 Likes
22

So, an alternative to the Ingress resource.

3 Likes
23

Hi @B-L-R, there isn’t quite 100% feature parity between the two. This is partly because the Gateway API itself hasn’t yet added all of the features to the API, as well as NGINX Gateway Fabric still making progress on all of the various features.

The ingress2gateway tool is a great starting point for what can be converted from Ingress to base Gateway API configuration. You’re correct, not everything has a direct translation right now, and some translation for NGINX Gateway Fabric specific policies is not supported in that tool, so some manual work is required for some translations.

5 Likes
24

We have a command line argument -enable-tls-passthrough for tls passthrough. You can also use the argument -tls-passthrough-port<int> to specify the port you want to use for it.

1 Like