NGINX Ingress Controller Reviews

Our main use case for NGINX Ingress Controller is that we are using it in our EKS and our open source Kubernetes as a controller where it handles our traffic.

A specific example of how we use NGINX Ingress Controller to handle our traffic is that we are configuring the Kubernetes cluster as a private endpoint only, so it will not be accessible through the internet for anyone. We are securing it through a private endpoint only, so we are using NGINX Ingress Controller for handling the traffic. We are configuring NGINX Ingress Controller as pods, and then we are configuring the Ingress rules for that to serve which traffic is coming from the load balancer and to where the traffic will be routed. We are configuring the Ingress rules based on the rules, and it will route to the different services, and from the services, it will route to the different pods and deployments. Using that, we will configure the SSL certificate for the security, and in NGINX Ingress Controller only, it will handle the certificate termination. SSL termination will happen within the controller. It is very reliable for us.

The best features NGINX Ingress Controller offers include SSL termination, where it handles the certificate terminations, and if I had to pick a favorite feature, that would be it.

NGINX Ingress Controller has positively impacted our organization by improving security when it comes to the certificate. As I mentioned, SSL termination is one of the points where it improves. When it comes to handling the traffic, where we are configuring the Ingress rules, we can say that it is very highly improved for us. Even though the traffic is very high, it will be handled very well, routing the traffic based on the Ingress rules to the particular service and to the particular pod.

When it comes to how NGINX Ingress Controller can be improved, I think we can add documentation as one of the points. We can improve it so that everyone can directly refer to the particular document in a precise way, and we will be getting very specific information. When we have any specific issues, it will be much easier for us to troubleshoot things. Documentation is one of the points, and everything is so far good for me.

We are using NGINX Ingress Controller for the past two to three years.

NGINX Ingress Controller is stable and has been reliable for me over time.

NGINX Ingress Controller's scalability is good and can handle increased load easily.

The customer support for NGINX Ingress Controller is good; I have reached them a few times, and it was good.

I did not evaluate other options before choosing NGINX Ingress Controller.

The advice I would give to others looking into using NGINX Ingress Controller is that we are using this for the past three to four years, and it is very reliable for us and it can handle the traffic based on our load as well. So I can suggest it to them when they are starting with new clusters and thinking to opt for any controllers for their cluster. I can directly suggest it. I would rate this product an 8 out of 10.

I am currently working with NGINX Ingress Controller but in a different perspective than before. We haven't used App Protect anymore, but as an implementer, we use it as a front end for an AI gateway to do some mapping for certain information before sending the LLM request to the AI gateway.

NGINX Ingress Controller itself is a reverse proxy, so we manipulate some requests. We utilize NGINX Ingress Controller to manipulate some requests prior to the AI gateway.

My use case has changed because nowadays the main focus for use cases are for AI and AI security that mainly focuses on LLM security.

A third-party solution would be better for that. NGINX Ingress Controller is a software, so its capability of working is fitting inside the organization, not facing the internet. The one that faces the internet is something else, for example, the firewall or Big-IP, so normally we do the whitelisting at those levels, not the NGINX Ingress Controller layer.

Most customers are satisfied with the reverse proxy capability, but the main issue is that the Ingress NGINX, the one that is most widely used, will be deprecated this month. I think that is the main concern from the customer side, but normally NGINX Ingress Controller just works well and is reliable.

From my experience, I think the main benefit NGINX Ingress Controller provides to the end user is the reliability of NGINX Ingress Controller itself. The customer can rely on this service that it will work well, and there will be no problem or issue that they need to concern.

In my opinion, NGINX Ingress Controller can make better improvements for ingress control, and I think they are already the leader in the Ingress and Gateway API. The Gateway API has the capability to separate the gateway responsible for the FQDN and certificate management. They separate this part within the gateway, and another part is the HTTP route which will load balance to the backend service. F5 has this kind of deployment for many years before the announcement of the Gateway API itself.

Currently, there is no suggestion about complexities or functions that can simplify my life with NGINX Ingress Controller.

I have been working with NGINX Ingress Controller for approximately seven years.

I think the initial setup process for NGINX Ingress Controller is simple.

I would like to see some AI capabilities, in-built AI capabilities in NGINX Ingress Controller to help with the load balancing.

Normally, customers just use the normal load balancer, and that is fine. The advanced features we try to introduce include many advanced features, for example, a blue-green deployment, load balancing to service based on header values, and many things, including JWT, but normally customers just use the basic load balancer. Most customers use TLS termination. Most customers use it, and they terminate the certificate at NGINX Ingress Controller level. NGINX Ingress Controller can do whitelisting, but they usually use a different product. For example, a Big-IP to do whitelisting instead of NGINX Ingress Controller.

We have some projects integrating NGINX Ingress Controller with Prometheus including Grafana. The integration is working well, and there is no problem about that.

Currently, there is no suggestion about complexities or functions that can simplify my life with NGINX Ingress Controller. I am totally satisfied with NGINX Ingress Controller if we talk about the functionality part.

I think the price is acceptable, but the issue is not about the price. The issue is about the commonness. Load balancing and Ingress is some kind of generic use case, so there are no exciting features, such as an AI feature or something of that nature.

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.

My main use case for NGINX Ingress Controller is managing the traffic that comes through our application. If the server is down or if clients are unable to access our app, then we manage NGINX Ingress Controller. We check if the pod is healthy or not and if the traffic is routing properly or not.

A specific example of when NGINX Ingress Controller helped me solve a problem is when it routes people accessing our applications. For instance, if users try to access example.com/a, then NGINX Ingress Controller routes them to service A, and if they try to access example.com/b, it sends the traffic to service B.

The best features NGINX Ingress Controller offers include helping to expose our applications, such as the front end and back-end API, and allowing us to manage multiple services behind just one IP address. It also handles HTTPS requests in production and performs load balancing automatically. If you want to scale the pods from two to five or two to six, we can configure that. NGINX Ingress Controller automatically distributes the traffic with no manual configuration needed.

In my day-to-day life, we debug and troubleshoot frequently by checking ingress rules, NGINX logs, and service endpoints. It provides good security features, allowing us to block some IP addresses, rate-limit APIs, and implement basic authentication or AuthO.

NGINX Ingress Controller has positively impacted my organization by helping us with exposing our applications and managing security and auto-scaling. All of these aspects have been very beneficial as we are using Google Cloud Platform in our organization.

A specific outcome regarding NGINX Ingress Controller is that it has definitely helped us reduce the downtime of our applications.

I do not think any improvement is required for NGINX Ingress Controller.

I have been using NGINX Ingress Controller for the last four years.

NGINX Ingress Controller is stable.

NGINX Ingress Controller's scalability is good. We can scale it for multiple applications effectively.

The customer support for NGINX Ingress Controller, specifically from Google, is decent. It is not that excellent, but it is fine and you can rely on them.

While I have not compared NGINX Ingress Controller with other solutions, I find all of its features, such as load balancing, security, and exposing multiple services behind one IP, to be the best facilities NGINX Ingress Controller is providing. We check all those aspects whenever we encounter any issues in production related to NGINX Ingress Controller.

My advice for others looking into using NGINX Ingress Controller is that if you are using Google Cloud Platform, then you should definitely go with it as it is good.

My main use case for NGINX Ingress Controller is that I commonly use it as a reverse proxy.

I have used NGINX Ingress Controller for SAP API calls, so whenever I am using these API calls on my frontend application, I don't want to expose the SAP server details. Therefore, I normally ingress it through NGINX Ingress Controller, mapping all these APIs to the SAP APIs, and from the frontend, I have access to it as a local post, effectively hiding all the SAP server URLs. A specific use case includes sales order APIs and posting something into SAP to get the business partner details from SAP, and similar actions.

NGINX Ingress Controller offers primarily reverse proxying capabilities, and the proxy feature stands out for me due to some performance benefits, definitely security as the first thing, and also the load balancing aspect and the ability to route traffic to multiple servers.

NGINX Ingress Controller has positively impacted my organization by definitely improving my team's efficiency in terms of multiple load balancers and complex routing rules we can configure there, resulting in a single, easy-to-manage layer. Hence, routing, SSL termination, and rate limiting contribute to making us much faster and efficient.

NGINX Ingress Controller can be improved by implementing faster deployment of new services, simplifying SSL or TLS management, and enhancing faster troubleshooting by providing more logs. While I have debug logs, using more techniques to reduce the mean time to resolution would be beneficial.

I have been using NGINX Ingress Controller for ten years.

NGINX Ingress Controller is stable.

In the Kubernetes environment, NGINX Ingress Controller scales very well.

As a developer, I can definitely say that NGINX Ingress Controller improves performance in terms of load balancing, especially in a microservices environment with many APIs. I don't have closely related metrics, but in a past microservices environment where I had fifty or more services, maintaining around one thousand to one thousand five hundred APIs was very hard without ingress. However, with ingress, it is easier to maintain them, and I think it doesn't charge more than thirty dollars a month for usage.

NGINX Ingress Controller is pretty standard and very lightweight, making it highly recommendable to use in local development environments, and it is especially useful in test environments for enabling SSL and rate limiting.

On a scale of one to ten, I would rate NGINX Ingress Controller around eight point five, near to nine, due to the ease of setup, although there is a slight learning curve with some advanced features. The documentation is good and reliable, and it performs well as it is lightweight and handles traffic loads sufficiently. While debugging, the logs are generally helpful, debugging complex routing can sometimes be tricky, so I may need to have more NGINX internals to be logged. Overall, scalability, performance, and upgrades are all good, and using it in Kubernetes integrates very well.

NGINX Ingress Controller is my main tool for managing access in our Kubernetes clusters, where we have multiple clusters, and for the access of different microservices, we use NGINX Ingress Controller.

For a specific example of how we use NGINX Ingress Controller with our services, we have multiple front-end and back-end services, including back-end APIs, and some services need to be exposed publicly through an ingress resource, so we use NGINX Ingress Controller to expose those services publicly by applying an ingress resource on that service.

In addition to my main use case with NGINX Ingress Controller, we also use custom resource definitions, CRDs for Transport Server and Transport Servers mainly, and Virtual Routes.

The best features NGINX Ingress Controller offers for my use cases include ingress resources and different annotations that allow us to expose a publicly accessible URL by whitelisting IPs and so on.

The annotations that we utilize with NGINX Ingress Controller help our team by allowing us to block or whitelist IPs for certain publicly accessible services, ensuring that only specific public IPs can access those ingress URLs while blocking others.

NGINX Ingress Controller has positively impacted my organization in that all my ingress resources, services, and internal and external communications between different services are quite smooth, and we can control our service exposure and service access easily using NGINX Ingress Controller, which makes my organization really happy.

I think NGINX Ingress Controller could be improved by adding many features and functions regarding firewalls, similar to what a professional API gateway offers, so those functionalities can be integrated with NGINX Ingress Controller.

I gave it a rating of 9 out of 10 because I noticed that there are some things that need improvement or additional features and functionalities, such as more firewall-related options that can be added.

I have been using NGINX Ingress Controller for almost three years or more.

In my experience, NGINX Ingress Controller is stable; so far, it has been quite good.

NGINX Ingress Controller demonstrates quite good and straightforward scalability.

Over the last couple of years regarding customer support for NGINX Ingress Controller, I have not encountered any scenarios where we needed customer support, so I have not felt any requirement for customer support so far.

Previously, we used Istio for service mesh, and we decided to switch to NGINX Ingress Controller due to the complexity of Istio and version conflicts between the Kubernetes cluster and Istio.

I have seen a return on investment with NGINX Ingress Controller since the time saved is considerable, especially because it is simple to use.

My experience with pricing, setup cost, and licensing is good, but I am not sure about those aspects since I am using the community edition.

Before choosing NGINX Ingress Controller, I evaluated other options such as Traefik.

My advice for others looking into using NGINX Ingress Controller would be that it is easier to use and anyone can explore and use it. I would rate this product 9 out of 10.

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.