NGINX Ingress Controller Reviews

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.

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.