F5 NGINX Ingress Controller (Premium Edition)

I use NGINX Ingress Controller  for reverse proxy, forwarding client requests while placing it in front of my backend servers. This removes my app from direct internet exposure. I also use it for load balancers to distribute incoming traffic across multiple backend instances using various strategies, which improves availability and throughput.

For example, we run multiple backend services in Docker  containers, each running on different internal ports. Instead of exposing each service directly, I place NGINX Ingress Controller  in front as a reverse proxy. It handles my SSL termination by managing HTTPS at the NGINX  layer using a Let's Encrypt certificate, so the backend containers only speak plain HTTP internally. This simplified the app code and centralized certificate management in one place. It also helps with routing by path, allowing a single domain to route to different services based on path prefix. Without NGINX Ingress Controller, I would have had to separate the domains or expose my ports to the outside. Additionally, it has helped with stability under load.

Since I work with Kubernetes , NGINX Ingress Controller is a natural extension of what the standalone version does. Instead of writing the config manually, I define Ingress resources in YAML files, and the controller reconciles them into NGINX  config automatically. The same concepts apply: reverse proxying, path-based routing, and SSL termination. However, it is now managed declaratively and integrates with Kubernetes ' native tooling.

I remember one instance when we had a Python Flask inference endpoint running behind NGINX Ingress Controller on Kubernetes. The service processed documents and returned structured data, with some requests taking thirty to sixty seconds depending on document size. The problem we faced was users were intermittently getting gateway timeout errors. The Flask service logs showed the request completing successfully, but clients were still getting the error before the response came back. We diagnosed it by pulling the NGINX Ingress Prometheus metrics into Grafana  and filtering by upstream response time per Ingress. This showed clearly that requests beyond sixty seconds were being dropped. The default proxy read timeout on NGINX Ingress Controller is sixty seconds, and nobody had changed it. The app was fine, but NGINX was cutting the connection first. The fix was one annotation on the Ingress resource to increase the timeout. We did not change anything on the app, no redeployment, and no global config map modifications. The timeout was scoped only to that specific Ingress. This resulted in zero timeouts from that endpoint. Since the fix was annotation-based, it did not affect any other services' timeout behavior in the cluster.

The path and host-based routing that NGINX Ingress Controller offers allows me to route traffic to different backend services based on URL path or hostname. There is SSL/TLS termination, which handles HTTPS at the Ingress layer. I pair it with cert-manager and Let's Encrypt for fully automated certificate provisioning and renewal with zero manual certificate management. There are annotations for fine-grained control, which allows me to customize behavior per Ingress without touching global config. Additionally, there is rate limiting, authentication, WebSocket support, and observability. NGINX Ingress Controller exposes Prometheus metrics out of the box.

In many ways, NGINX Ingress Controller has provided cost reduction by eliminating our per-service load balancers. Instead of each service having their own load balancer, we consolidated them behind NGINX Ingress Controller. There are faster deployments, as routing changes previously required infrastructure-level changes, updating DNS, and provisioning new load balancers. With NGINX Ingress Controller, we can apply all these changes in YAML files and reduce the deployment time drastically. There is centralized SSL management, which helped us centralize our certificate provisioning and renewal. Additionally, there is improved reliability with better observability across our services.

There is annotation overload. We could move toward a better API annotation work, though currently the annotations are stringy-typed YAML with no validation, making it easy to create typos. Better error feedback is needed, as when an annotation is wrong or unsupported, the controller often ignores it with no clear error surfaced back to the engineer. Observability  depth should be increased. Performance at very high scale should be improved. At extreme scale with hundreds of Ingress resources, the controller can experience reload latency.

Three specific things stand out. The reload problem is architectural, not fixable with a config tweak. The annotation model has no safety net, so if I type an annotation incorrectly, the controller silently ignores it. Configuration snippets are effectively disabled in serious multi-tenant clusters, as those are among the first things security-conscious platform teams turn off.

I have been using NGINX Ingress Controller for over a year.

NGINX Ingress Controller is stable.

NGINX Ingress Controller scales well in horizontal pod autoscaling. The controller itself scales horizontally, and you can run multiple replicas behind the cloud load balancer. There is solid connection handling.

I have had a pretty good experience with customer service. They respond when I reach out and help resolve whatever support issues we have.

I evaluated three main alternatives before settling on NGINX Ingress Controller: Traefik Ingress Controller, the AWS  ELB Ingress Controller, and Istio  Ingress Gateway.

The initial setup was very fair with no major complications and no overcharging.

The implementation was handled through a vendor relationship only.

For direct cost savings, after consolidating our services behind NGINX Ingress Controller, we were previously spending approximately twelve hundred dollars per year but have significantly reduced those costs.

Each service was previously using its own cloud load balancer. After consolidating every service behind NGINX Ingress Controller, this actually cut down our costs significantly.

I would give NGINX Ingress Controller a rating of six. I recommend starting with the community version. My overall review rating for this product is eight.

NGINX Ingress Controller  is my primary solution for managing traffic requests to my Kubernetes  workloads. Most of my projects are based on containerization, meaning the applications are completely built on Kubernetes  and require traffic routing from the external world to my Kubernetes infrastructure.

I worked on a project with more than 200 microservices where we needed a single entry point solution into the Kubernetes cluster. I deployed one NGINX Ingress Controller  and configured HTTP routes for multiple domains through which clients can browse the application. We also implemented some internal private NGINX Ingress Controller instances where internal applications communicate with each other based on domain names. NGINX Ingress Controller allowed us to set up path-based routing and traffic splitting.

In another interesting use case, we had multiple GCP  projects and used NGINX Ingress Controller as a single source of truth. We deployed a cluster in one common project with NGINX Ingress Controller and navigated requests to other Kubernetes clusters. All Kubernetes clusters were connected through a mesh called Anthos .

NGINX Ingress Controller offers several valuable features. Unlike other native ingress solutions, we get only one load balancer in the background, which means no matter how many ingresses we create, we receive only one IP address. This significantly saves costs. Additionally, we get all the native NGINX  features in NGINX Ingress Controller, including proxy functionality, upstream configuration, rate limiting, header passing, and header control capabilities. These are features that other ingress solutions do not provide to the same extent.

The cost-saving feature of NGINX Ingress Controller is excellent, and the rate-limiting and header control features work very well together. I use these three combinations frequently as they help me control costs and manage headers. Rate limiting also helps secure NGINX Ingress Controller by preventing DDoS and phishing attacks.

Cost was significantly reduced compared to launching another load balancer. We configured NGINX Ingress Controller to work as a gateway. When something breaks, we have a single point of truth for troubleshooting instead of investigating different load balancer stacks. These improvements helped my team troubleshoot issues more efficiently. The time to solve an issue was reduced from thirty to forty minutes to ten to twelve minutes. NGINX Ingress Controller is lightweight, which enhances performance and reduces network request latency.

Some ingress controllers are becoming outdated, and if the features that gateways offer nowadays could be integrated into NGINX Ingress Controller, it would be greatly beneficial.

The main feature I want to see included is the ability to reduce namespace specifications. Currently, gateways are not namespace-specific in Kubernetes, whereas ingresses are namespace-specific. If these namespace specifications could be reduced, it would be a great addition.

I have been using NGINX Ingress Controller for quite a long time because it is an ingress-based solution that works on top of Kubernetes.

NGINX Ingress Controller is stable in my experience. I have not faced many issues with NGINX Ingress Controller so far.

NGINX Ingress Controller is scalable because it is deployed in the form of pods. When additional traffic arrives and NGINX Ingress Controller cannot handle it, it scales based on CPU and memory percentage.

I have not experienced significant issues requiring customer service. When issues do arise, we go through the Marketplace and receive resolutions via email. Since we have not faced substantial issues, the customer service experience has been good.

We were using native cloud solutions and ingresses. We also used other ingresses such as Kong. We compared other ingress solutions in the market including Kong, Apigee , and cloud-native ingresses.

NGINX Ingress Controller is a truly good tool that has proven its capability in the market. I advise others who are looking for solutions to seriously consider NGINX Ingress Controller.

Concerning AI governance and security, there should be proper guardrails around AI capabilities so that I know what components NGINX Ingress Controller is accessing and what things are involved. I am more concerned about the guardrails surrounding NGINX  AI Controller capabilities.

Those AI capabilities are reliable because they are AI-based and would be faster than humans. However, I am more concerned about accuracy because all AI capabilities, including NGINX AI capabilities, are based on data. I am aligned with the idea that these are reliable, but sometimes they may produce false positives. This is the main thing that concerns me.

I gave NGINX Ingress Controller a rating of 8 out of 10.

I have used NGINX Ingress Controller  in a couple of projects as a controller that is supposed to route traffic to Kubernetes  clusters. One of the main reasons I chose it is because it is a free product with a lot of documentation that is very easy to set up. It has a great community around it to help with answering questions and providing feedback on architecture.

In one of the projects where I used NGINX Ingress Controller  to route traffic in Kubernetes  clusters, we have a cluster running in Azure  AKS with several services deployed as pods on a multi-node cluster. An F5 NGINX  controller routes the traffic that comes through the load balancer, the Azure  Standard Load Balancer, and then routes it using the ingress controller to the different pods. There is a lot of configuration involved, including whitelisting specific IP ranges and headers in order to add an additional security layer to the traffic routing mechanism.

NGINX Ingress Controller offers a lot of different configurations, making it very flexible in terms of how you can configure the routing and traffic steering. It supports all kinds of header-based routing, regex capabilities, canary releases, and TLS terminations. I have used it a few times as a reverse proxy as well, and many security controls can be configured.

Out of all those features, including flexible configurations, header-based routing, regex, TLS termination, and security controls, I find myself using the routing and security controls the most.

The obvious positive impact of NGINX Ingress Controller is the cost saving. I have seen those savings in terms of cost compared to other enterprise products which come with a cost to implement, maintain, and support.

I do not see anything that frustrates me about NGINX Ingress Controller or that I wish was different. There are a few gimmicks that need learning, such as annotations and precedence over annotations and config maps that could be a bit clearer at times, but other than that, I do not see a lot of other things that would annoy me in my work with NGINX Ingress Controller.

I have used NGINX Ingress Controller for approximately four to five years, give or take, in different projects.

NGINX Ingress Controller is stable.

NGINX Ingress Controller scales very effectively because it can be deployed on a cluster, so it performs pretty much the same as anything running on Kubernetes.

I have not used the customer support for NGINX Ingress Controller.

I have used different solutions before, but I have not switched between them. Those were different projects with different requirements.

NGINX Ingress Controller is very easy to set up, easy to deploy, and easy to maintain.

I did not purchase NGINX Ingress Controller through the Azure marketplace.

The only measurable thing I can say about return on investment is money saved in comparison to other commercial products.

I do not have any experience with pricing, setup cost, and licensing because I have used the open-source version.

I have evaluated other options before choosing NGINX Ingress Controller, including Traffic and Kong.

Regarding NGINX Ingress Controller's AI capabilities, I do not have any experience with its governance and security. I have not used NGINX Ingress Controller's AI capabilities, so I cannot speak to the accuracy and reliability of its output. My overall review rating for NGINX Ingress Controller is 9.

NGINX Ingress Controller  is primarily used for routing in my team's Kubernetes  cluster where we run multiple microservices. We deployed NGINX Ingress Controller  on a cluster with around 20 microservices and different endpoints that we wanted to route requests to, so we specified all the paths we wanted to route to in the YAML files.

Apart from my current projects, I have also used NGINX Ingress Controller in some open-source deployments where I needed to route requests.

The overall time and manual work have been reduced since we started using NGINX Ingress Controller. Earlier we used some other routing tools, but NGINX  fits quite well in our Kubernetes  cluster setup, making it easy to deploy and get running. NGINX Ingress Controller has helped my team reduce workload, particularly in the time saved.

The best part of NGINX Ingress Controller is how it works, particularly the annotation feature, which allows us to specify all our details through annotations, making it quite easy to integrate with our system.

The rewrite path is one of the annotations provided by NGINX Ingress Controller, which lets us route requests to a different path based on specified weights. For example, we can send 50% of the requests to one endpoint and 50% to another.

The annotation part of NGINX Ingress Controller is good, but it can be tedious when there are many features to specify in the annotation section, which sometimes gets messy and could be improved. However, there is a new project called Gateway APIs that has solved that problem.

The annotation part itself could be improved, as overall it was good but sometimes having everything in the annotation section can be a bit cumbersome.

Overall NGINX Ingress Controller is a good tool to use, but the main drawback is the annotation part, as managing many paths and features can get quite tedious and complicated.

I have been using NGINX Ingress Controller for more than three years now across my different projects.

NGINX Ingress Controller is stable in my experience.

The scalability of NGINX Ingress Controller is overall good for our needs.

The customer support for NGINX Ingress Controller is good. I would rate the customer support for NGINX Ingress Controller around a 7 or 8.

We were earlier using HAProxy  to route requests, but we found it quite confusing and complicated, which is why we switched to NGINX Ingress Controller.

The main advantage of NGINX Ingress Controller is the deployment and ease of use. The way we deploy NGINX Ingress Controller is quite easy, as we just need the Helm install command or we can directly apply the YAMLs, which makes it unique.

We have seen a return on investment from using NGINX Ingress Controller, specifically in needing fewer people.

The pricing for NGINX Ingress Controller is overall acceptable, and I would not say it is great. The setup cost was also acceptable, and the licensing was straightforward.

Before choosing NGINX Ingress Controller, we evaluated options such as F5 and HAProxy , but we eventually started with NGINX .

NGINX Ingress Controller's governance and security features of AI capabilities are good, with all the basic guardrails available.

The accuracy and reliability of NGINX Ingress Controller's AI capabilities are not 100%. Sometimes it hallucinates and requires more prompting to get what I want exactly, but overall it is a good feature that still needs improvements.

NGINX Ingress Controller is a good tool to use. If you have a Kubernetes cluster, then it is easy to deploy and use, though you might face issues with the annotation part. I would give this review a rating of 9.

My main use case for NGINX Ingress Controller  is load balancing as well as an API Gateway to perform reverse proxy for our backend applications.

A specific example of how I use it as a load balancer and API Gateway in my environment is that we have our own DNS resolver, which we use ACME with as a free DNS resolving service. We bind it to the Ingress Controller and add our own rules and hosts to specific Ingress resources to bypass and forward all requests to the specific backends. This helps balance the load by making replicas on-demand.

Regarding my main use case, we implement custom configurations as well as custom port mappings and annotations. We use specific server snippets and follow security best practices to drop SSL terminations at the Ingress level instead of in the backend.

The best features NGINX Ingress Controller  offers for my team include all of the commonly available features in the community version. The community version is now obsolete, and Kubernetes  wants to move users to something else like the API Gateway feature, but we are still using NGINX Ingress Controller. The features are excellent.

While the features are exceptional, ease of use is not as straightforward because certain configurations probably require the paid version. We are using the free version, and in some cases, features like DNS Route 53  are not available in the free version, so we have to address that use case with alternative solutions.

NGINX Ingress Controller has positively impacted my organization by allowing us to handle many requests from different applications and customers, serving as the frontier of all our backend applications. It performs very well and is both scalable and lightweight. It integrates easily with Kubernetes , so it can be configured and used effectively.

NGINX Ingress Controller can be improved with better documentation. Good documentation in the Bitnami Helm chart would have made implementation easier for us, as we had to search for many things back and forth. Most of the information we found was confused with the community version of NGINX Controller , which created confusion initially. I would appreciate an AI-based solution so that we could easily find the actual use case relevant to our situation.

I have been using NGINX Ingress Controller for five years.

In my experience, NGINX Ingress Controller is stable.

Scalability and lightweight design have helped my team greatly. We recently had issues when multiple backend applications were accessed simultaneously from the same client browser, which caused slowdowns after a certain number of requests, around four or five of the same backend application or different backend applications from the same client. We configured this using a custom annotation configuration with HTTP/2, which solved the overall slow performance easily. NGINX Ingress Controller scales well and is very lightweight. The product manager appreciated the solution because it requires just a simple configuration in the Ingress resource, so no backend application changes are needed. NGINX Ingress Controller scales effectively to support whole load balancing scenarios, routing everything to the specific backend services.

I have not previously used a different solution before NGINX Ingress Controller. Plain  NGINX  was my first experience, and we stick with it because it serves all our purposes.

I have seen a return on investment from using NGINX Ingress Controller, as I need fewer employees. I do not have to maintain a large DevOps team for this purpose. Any developer can set up and configure NGINX Ingress Controller if they have adequate knowledge on how to set up an Ingress Controller. It saves time because it is easier to set up, though I am uncertain how it translates to monetary savings.

My advice to others looking into using NGINX Ingress Controller is to review the documentation first and ensure it serves your purpose. On a scale of one to ten, I rate NGINX Ingress Controller overall as a nine. I chose nine because I do not know the complete use case of the product, so I do not give it a perfect ten. That is my opinion, and while I have encountered some problems and hurdles, I have overcome all of them. It has worked very well for my purposes.