F5 NGINX Ingress Controller (Premium Edition)

I have worked on NGINX Ingress Controller  with an on-premises deployment model. There is an option for cloud as well, and SaaS solutions are also available. The recent project I completed was NGINX Ingress Controller  in Google Cloud  for one of our clients.

I have utilized NGINX Ingress Controller SSL and TLS termination feature. We have done extensive SSL offloading on NGINX Ingress Controller and made the TLS configurations to match security requirements, allowing certain TLS versions while disabling others such as 1.0, 1.1, and 1.2, and allowing 1.3. The choice depends upon the application requirement.

The reverse proxy capabilities of NGINX Ingress Controller in managing distributed applications is central to its main concept. We need to configure it to allow the server to access the outside world and the internet. That is achievable, and we can install and configure NGINX Ingress Controller as a reverse proxy. It can work as a load balancer, but the main part is NGINX Ingress Controller's role as a reverse proxy. If any applications need to be accessed through the proxy to the outside world, then NGINX Ingress Controller is a good product for you.

I employ the IP whitelisting feature in NGINX Ingress Controller, which helps secure my application environment. In IP whitelisting, there are several options available. You can determine which IPs to block, for example, if you do not want to give access to specific regions. You can find the list of IP addresses registered in those regions and blacklist them. There is also the web application firewall (WAF ) where you can create policies to identify the type of traffic trying to access the application.

I have not integrated NGINX Ingress Controller with solutions such as Prometheus or Grafana . We have not received any projects of that nature yet.

Integrating capabilities with third-party tools are mostly about monitoring or sending logs. Working with the upper layer, such as upper layer firewalls, depends on what kind of integration you are looking for.

I have worked with NGINX Ingress Controller for only a couple of years, and I recently started working on it. I do not have extensive experience with it, but with other F5 products, I have more than fifteen to twenty years of experience.

I have not seen any issues integrating NGINX Ingress Controller with other security products, such as firewalls. We have implemented it in AWS , using NLB and the AWS  product firewall. For the WAF , we have used Akamai  products. For WAF solutions, we have integrated with NLB on the AWS side and the internal AWS firewalls. Sending logs and integrating with firewalls has not presented any issues. It may depend on the kind of software; sometimes older software may not integrate properly, and we might need upgrades or patching. Normally, when issues arise, I reach out to the vendor; they provide patches to fix those issues. After that, I upgrade the software, and the issues usually go away.

Implementing NGINX Ingress Controller and installing the instance requires a few hours. After that, depending on what applications you are going to deploy and how many applications you are going to deploy, it might take time. If you are going to deploy one hundred or two hundred applications, then it is going to take a considerable amount of time. If you have only a few applications, such as five or ten, or you are planning for only a single application, then it is not going to take much time. So, within a day, you can bring up the devices and make them active.

My experience with F5's technical support was excellent around ten years ago, with very good response rates. Nowadays, the quality has been degrading, and I do not expect the same level of service. While they have improved their ticketing system, allowing online submissions and status checks, the skill levels of the technical staff seem to have reduced. That is what I am observing day by day, as I have worked with many highly skilled professionals in the past, and I notice a difference now.

I would rate their technical support somewhere around a three on a scale of one to ten.

The deployment process of NGINX Ingress Controller is not complex, I would say, because as a network engineer, I may not be able to know all those HTML coding aspects. That is a challenge I faced, because the coding part is new for me. I need to learn and do it. Other than that, I have not seen any other challenges. It is similar to a normal server installation; after that, you need to do the configurations such as network configuration to make the system available in the network. Then, you can implement the load balancer concept, such as installing web in the backend servers. If there is any SSL offloading, that may be the challenging part I faced.

There are a couple of options available for purchasing NGINX Ingress Controller. You can buy your own license, or you can use it based on the usage. It is similar to AWS coming up with their own license, and based on the usage, they will charge you. Another option is to buy a license directly from F5 or a vendor, which is a bring your own license (BYOL) option, and use that license to install it on the AWS Marketplace . You can install your instance, use this instance, and make use of that. Several options are available.

Regarding licensing costs for NGINX Ingress Controller, if you are talking about costs, F5 is always very costly. The license is very costly compared to other vendors such as VMware or AWS inside load balancer or other Akamai  load balancers. However, the response, throughput, and solid performance we receive after implementation are often worth it. Most of the time, I have not seen any issues, and the systems run very smoothly. This is just my experience, and opinions may vary per person. I have not encountered significant issues; the feedback from end users and clients has been very positive.

NGINX Ingress Controller is functional, but it is achievable and may take some extra time. The major issues typically relate to vulnerabilities, which F5 addresses with patches that require timely software upgrades to mitigate. I would rate this review a nine overall.

The simplest and most common use case in my country is somebody adopting microservice technology who was using Ingress Controller community edition and wanted to move to enterprise level. Someone wanting to have microservices and containerization applications desired commercial, enterprise-grade Ingress Controller, so they moved to F5 Ingress Controller, which is NGINX Ingress Controller .

The performance and stability are what I like about NGINX Ingress Controller . The more important concern is that it can apply App Protect and DDoS protection within NGINX Ingress Controller Plus. Security and performance are better, and all customers love it because of these options.

The main benefit is that it is better in performance, provides security with App Protect and WAF  and DDoS, and delivers high performance and high stability. However, there is still a major limitation in GUI capability to manage and observe. That is one of the major limitations.

NGINX Ingress Controller is doing better than the community edition for sure and works well when replacing Ingress Controller for OpenShift router. It is doing fine, but it is easy for the developer to develop and not easy for the other teams to work with. It is not something designed for a network security team anyway, so they cannot apply App Protect and other items. It is just for the developer. The drawback is that it is not targeting or is not easy for other non-developers to work with.

The capability to manage and observe should be better for NGINX Ingress Controller. We should not rely on Prometheus and Grafana  so much. The management is still in Kubernetes  Master, but there is a better way for managing it.

I have been using NGINX Ingress Controller for one year and a half. Coming from a background in network security and information security, it was not easy to recognize the deep involvement without having extensive reading about it.

NGINX Ingress Controller is working fine with both NGINX  community edition and NGINX Plus . We cannot see a difference when using NGINX Plus instead of community edition in SSL/TLS terminations. The stability in SSL for NGINX Ingress Controller Plus, which is the commercial one, is better than the open source. However, I do not have comparison data with other vendors as I have never seen a comparison between NGINX Ingress Controller and other Ingress Controllers in SSL/TLS.

NGINX Ingress Controller is perfect for scaling. NGINX is really awesome in scaling.

I have had one or two cases open with them. They are fast in response, but they are at an average level. The F5 team, which is the BIG-IP team, is faster in response and resolving issues.

NGINX Ingress Controller as a reverse proxy itself, which I have already tested as a software as a standalone server and not just as an Ingress Controller, is perfect. As an Ingress Controller, it is doing fine. NGINX Ingress Controller must perform reverse proxy functions, path-based routing or host-based routing, and target which container to route traffic. It is deep technical work, but it is doing fine overall.

Configuration is simple to start. To get deeper, I need to be a developer.

Prometheus and Grafana  are definitely necessary. The metrics I find really important is latency and request latency. That is one of the major metrics we love.

I have configured a new use case once in my life when something required it to work. I did not test it again after that, just once in my life.

Deployment works at small, medium, and large scales. I am working with different deployments.

For the sales and pre-sales, I simplify the message as much as possible. The message for NGINX Ingress Controller is always complicated when delivered, and it requires simplification.

I would rate this product 9 out of 10.

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.

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.