F5 NGINX Ingress Controller (Premium Edition)

NGINX Ingress Controller  serves as the front door into our Kubernetes  clusters that we use for databases. We run a bunch of internal, facing customer APIs and we need something that would do reliable routing without us handling configs and reloading them ourselves. We also lean on it for TCP and UDP load balancing through Transport Server. We have a couple of database-adjacent things like Postgres connection endpoints, a Redis  service, and we want to expose them through it rather than standing up separate entities.

The decision to use NGINX Ingress Controller  for those database-adjacent services, like the Postgres connection endpoints, is actually a big part of why I care about this working well. Transport Server is what we use to expose data services that are not HTTP. We have Postgres read-replica endpoints and Redis  cache that we front through Transport Server for load balancing and TCP load balancing. The thing I always keep in mind is the connection draining and long-lived connections. Databases do not behave the same way as when you have a stateless server like stateless HTTP. A web request is done in fifty milliseconds; a Postgres connection might be open for hours. For example, MySQL  has about eight hours for connections to be open until the engine kills them.

My main use case with NGINX Ingress Controller is focused on the connection side, where most of my scar tissue with this thing is. The core NGINX  Ingress is fundamentally built around the HTTP request-response model. For connection pooling placements, I never let NGINX Ingress Controller manage database connection concurrency. We do have other connection poolers and load balancing. NGINX Ingress Controller is not a connection pooler; it does not understand the database protocol, transaction boundaries, prepared statements, or any of those sorts of things that a connection pooler manages. So in front of Postgres, we always run pgBouncer between the app and the database. The ingress is just doing some TCP load balancing to get to the pooler or the right replica. I think the mistake people make is thinking the ingress can take the place of a pooler, which it really cannot. It can, but it will just pass through every connection, and you will exhaust the max connections of the DB, even if you have set it to ten thousand.

The best feature that NGINX Ingress Controller offers for my use case is the Transport Server CRD and the dynamic reconfiguration offered with NGINX Plus . This is the number one feature by a wide margin for me. On Plus, endpoint changes update the upstream through the API without a config reload. For anything fronting a database or a connection pooler, this is the difference between rock-solid, long-lived connections and mysterious resets that you have every time a pod reschedules. Another thing is the policy CRD, rate limiting, and access control. This acts as protection for the data tier. You can put a rate limit at the ingress, so one misbehaving client cannot stampede a service and blow up the connection count, just trying to keep things managed and optimal.

This shift away from manual config management has made my team's productivity and efficiency much easier. There was real improvement, but I will be specific about where the speed came from because it is not where people usually assume. Before, exposing a new service or changing a route meant human editing NGINX config, getting it reviewed by whoever owned the edge, and a careful reload during a safe window. That was a ticket and wait process, realistically a day or more of latency for something trivial because it is queued behind whoever owned the config. For databases and data services, it is slower to stand up. Exposing a new Postgres endpoint or a pooler through Transport Server is not just a merge-it thing. It is deliberately so. It involves proxy protocol being wired end-to-end so we keep client attribution. Timeout settings are tuned way up so idle pooled connections do not get ripped. Health check semantics that actually mean something for a database rather than just a TCP connection, and capacity-wise, considering connection counts hitting max connection, it is just more complex with more things involved. The honest summary is that deployment of routing changes got much faster, mostly by removing the human bottleneck rather than any technical speed-up. Deployment of database exposure intentionally did not get faster, and should not, but it got reproducible, reviewable, and instantly revertible. So when you make them, you are able to take them back. For the data tier, the reliability gain mattered far more than raw speed ever would have.

NGINX Ingress Controller can be improved, and my team's concern would be database protocol-aware health checks for Transport Server since that is what NGINX is more focused on. Right now, even on Plus, a Transport Server health check is essentially a TCP connect or maybe a basic send-expect. For a database, that is a weak signal. The listener being up tells you almost nothing about whether Postgres is actually serving, whether a replica is lagging, or whether it is in recovery. I would love a way to define a health check that does something protocol-aware, even something as simple as you open a connection, run a SELECT one, which is the most popular test, and expect a row for Postgres or a PING for Redis. Without that, I am relying on the database's own infrastructure to pull bad replicas, and the ingress will happily continue routing to a replica that answers TCP but is serving stale reads. Better idle connection management for long-lived stream connections can also be improved. A pooled database connection sitting idle between transactions is healthy in my opinion, but the proxy's instinct is to reap idle connections. You can crank timeouts way up, but that is a blunt instrument.

I would like to add that specifically for databases, the need for improvement becomes clearer. Every client connection through NGINX becomes a backend connection, one-to-one. A client connection through NGINX and a client connection through a connection pooler are sitting because they are going to get sent to the backend connection. It does not multiplex; it does not understand transaction boundaries. It cannot reuse a connection across clients. If you put it in front of Postgres without a real pooler behind it, you have just built a very efficient way to exhaust the max connection. The architecture is always client, ingress, connection pooler which is either pgBouncer or ProxySQL, then the actual engine which is Postgres or MySQL . Never let it be clients straight to the database. NGINX Ingress Controller's mode is one client connection to one backend connection with no multiplexing and no protocol awareness, which would be an issue for you.

I have been using NGINX Ingress Controller for three years now.

NGINX Ingress Controller is stable, and I would say there are different stability stories when talking about how it behaves in front of databases. NGINX Ingress Controller is stable itself. NGINX's data plane is rock solid. I do not really experience any reliability issues.

For scalability, HTTP scales very well horizontally. It is straightforward. More controller pods behind the LB, and NGINX handles higher requests and connection volumes per pod efficiently. It scales really well.

For NGINX Ingress Controller's customer support, I experience community support for the open-source side which means GitHub  issues, project documentation, Slack, and community channels. On NGINX Plus side, there is paid commercial support. They are obviously available to help with issues that I have, and I have encountered great engineers. Overall, it is a great experience.

I have seen a return on investment, but I do not have the actual numbers. The return is an avoided cost story, not a revenue or savings line. The clearest return is incidents that stopped happening. We used to have multiple incidents, but they stopped happening before we moved data tier parts to NGINX Plus. We had a recurring category of incidents. I would not say fewer employees; I would push back on that being the sense of it. NGINX Ingress Controller's ROI is real, but that is all I have to say, to be honest.

I do not have much to say on the pricing, setup cost, and licensing front. There is a different functional team for managing costs and licensing in the environment. I can say a few things from my experience, though. The core dynamics and core features for databases involve the paywall. The paywall is what concerns me. I am not really sure about every other cost, but the decision lies with the other functional team.

Before NGINX Ingress Controller, we came off community ingress NGINX, and before that, plain HAProxy  managed by hand for the database parts. We evaluated a few solutions such as HAProxy , ingress, Traefik, and Envoy . The decision came down to CRD-based config ownership plus a paid escape hatch for the reload problem on the database parts. This is purely a review based on its interaction with databases. The platform engineering team uses NGINX Ingress Controller for various important aspects of covering all of the tech platform and services that we manage.

My advice for others looking into using NGINX Ingress Controller, especially for the database side of things, is to be aware that the ingress is deliberately a stateless system. Every problem you will have comes from forgetting something. Internalize that the ingress does not understand the database. Never let it act as a connection pooler. Always put a real pooler behind it. The architecture is always client, ingress, your connection pooler which is either pgBouncer or ProxySQL, then your actual engine which is Postgres or MySQL. Never let it be clients straight to the database. NGINX Ingress Controller's mode is one client connection to one backend connection with no multiplexing and no protocol awareness, which would be a major issue for you. I have given this product a rating of seven out of ten.

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.

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.