F5 NGINX Ingress Controller (Premium Edition)

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.

My main use case for NGINX Ingress Controller  is as a single point of entry in a public exposed service. I have a service exposed with a public IP through the internet with NGINX Ingress Controller .

NGINX Ingress Controller has positively impacted my organization since I have been using it in production for over three to four years. The positive impact of NGINX Ingress Controller is that it has simplified the configuration at scale for multiple teams.

It has simplified things for multiple teams by creating templates so that each team could use basic Ingress templates, allowing this to be scaled.

The best features NGINX Ingress Controller offers include TLS termination and some annotations. TLS termination and annotations help my workflow or setup because I don't need to create certificate objects, and I could use NGINX Ingress Controller along with cert-manager to do it.

I think NGINX Ingress Controller can be improved by not being deprecated. Better documentation could be an improvement as well.

I have been using NGINX Ingress Controller for six years.

NGINX Ingress Controller is stable.

NGINX Ingress Controller's scalability is acceptable with HPA.

The setup process was straightforward.

My advice to others looking into using NGINX Ingress Controller is to evaluate other options, perhaps with Gateway API instead.