Here is a quick overview of F5 NGINX Ingress Controller for Kubernetes.
How is the NGINX Ingress Controller different that reverse proxy or otherwise known as a standalone proxy?
They are cousins of each other and based on the same core code. However, ingress is especially built to be run within a kubernetes cluster, and work within the framework of kubernetes. It’s configured and managed via api where standalone is configured through a .conf file.
A quick overview of NGINX use cases or functionality that are supported in multiple environments including onPrem (private cloud) and a multitude of public cloud environments as well as many kubernetes flavors. And in this presentation i’ll be referencing how this would apply in an RHEL Openshift.
OK, so what is an NGINX Ingress controller?
It’s essentially a specialized load balancer for the kubernetes environment so think of it as a front door for entering the kubernetes cluster and the the job of the ingress controller is to accept the traffic from the outside and then connect to the pod that you want to connect to. So you want to be like the air traffic control tower and connect to the right pods and all this (including manage and configure) can be done via the kubernetes api as an object called the ingress resource.
What’s nice about the NGINX plus is it adds the ability to monitor the pods that are running kubernetes, automatically updating load balancing rules, for example, if you needed some action to be done based on certain health metrics.
You also have heard of Nginx Open source (the free version), which is perfect for non-critical apps. It’s actually a very popular option for most folks using kubernetes. It’s very popular for one app, a single team and not a lot of silo functions needed.
However, as you know in Kubernetes, there is often a shared environment and you have multiple teams multiple apps with different roles and the recommendation from F5 in that scenario is to utilize NGINX Ingress Controller commercial version (aka NGINX plus) because it is more suited for multiple apps in one cluster and helps you kind of delineate with leveraging kubernetes RBAC creating those silos
An example I can show you is in this diagram displaying many different roles, and each role can focus on their own YAML or piece of configuration that segmented away, but they can still work together to configure the same service and route. For example NetOps operator can only be responsible for setting up the routes whereas DevOps person can say, hey you know I want to have a service in mind or a pod in mind that I want to map it to, but I don’t wanna step on anyone else, so folks have the freedom to do that. That silos we talked about earlier that you get with the plus or commercial version that you don’t get in the free open source version.
If you are utilizing RedHats Openshift I find it relevant to mention that NGINX plus is a certified operator in the Redhat Openshift ecosystem which means there’s a strict review and then there’s full support as it’s part of a partnership program so you know your Openshift ecosystem is fully compatible as well so NGINX Ingress Controller is not an alien in that environment.Â
I’d like to also point out that what’s coming soon is an offering called NGINX one. NGINX one is two fold.
On one hand it’s a rebrand of all F5 NGINX data plains into one family or umbrella
On the other hand it’s exciting that there will be a SaaS console which something that will provide is an ability to centrally manage configuration across all environments of NGINX core sitting in the environments as well as telemetry of performance and as well as configuration. And oh yea, the best part is it’s free for all F5 paid commercial data plan users so if you subscribe to NGINX ingress, you have that free access to NGINX one SaaS console which is coming soon for all data planes, including NGINX ingress.
So here we are zooming out and we’re looking at the architecture outside of open shift but more of a hybrid approach where we’re kind of connecting all the dots together.
On the right you see the NGINX Ingress Controller with App Protect in the open shift container platform. That’s specialized LB that is specifically designed to run in Kubernetes cluster like open shift environment in this case and as you scale services up and down.
(lets say for an example when you scale a service up and down the Ingress controller will automatically recognize those things and they will essentially manage all of the inbound traffic and route them to the appropriate services.
NGINX also has the app protect WAF that could be also compiled or attached onto that Ingress controller for additional Layer7 protection. Developers can use/leverage in CRDs and open shift objects to actually configure those WAF policies so they don’t have to depend on other external ops to do so.
On the left side you see traditional applications as you know you could run NGINX plus on RHEL you can also install app protect on RHEL instances as well, so you can protect monolithic traditional services so they both apply with this being containerized or traditional.
What see you at the top is the NGINX plus ADC.
In an on-prem environment there might not be a LB so they need some kind of automation there to say OK I need an external LB and that’s where NGINX plus ADC comes because it routes all that traffic.
What you see on the left is the NGINX controller that’s what we were talking about with NGINX one (the SaaS offering). so what it’s gonna do is actually its gathering an aggregate of all that telemetry that the systems are generating and your gonna be able to see that in central SaaS console (NGINX One).
What you see in the middle is NGINX Plus API gateway, you can think about but that as NGINX Plus but really for a different use case so really depends on the case. We’ll talk more about that in a minute.
So that was like an umbrella view of the NGINX one Family and how all the components connect together.
Here is a comparison of performance between RedHats Openshift open router which is HAproxy under the hood and NGINX plus controller installed
if you just sent traffic and kept the environment static, which is not a typical environment, you would probably get the same performance between the two products.
so what these test results are from is more real world use which is elastically scale up and down the upstream Deployment in the cluster to see how well it performs when things are changing and configurations are changing constantly and reloading.
as that type of environment was being emulated and sending a constant throughput to these systems the latency distribution of HAproxy got up to 25 seconds and so what happens there is the system under test in this case of proxy reloads, there are some connections that are open and they stay in queue, which kind of has a ripple effect on other connections that are trying to connect and load other pages. It’s fetching CSS or PNG or HTML file and it creates that 25 second delay where in NGINX plus it leverages API so a lot of things get dynamically changed on the fly so you don’t have to reload the configuration so no delay.
NGINX plus and open source has an option to add on later App Protect which is a WAF as well as a DOS protection ability so this helps prevent not only top 10 OWASP for API vulnerabilities, but a bunch more as well if you are familiar with the BIG-IP Security products AWAF/ASM you know that the campaigns and the Intel that’s gathered is via F5 labs where they can probe for malicious activity throughout the world all the time, and that helps shape campaigns and signatures.
what’s a little bit different from the Big-IP versions obviously NGINX App Protect is light weight so better for micro services based architecture, but in addition to that it’s better suited for API because you can see in the app protect and open API spec or swagger file and will create a policy from that automatically so this is perfect for if you wanna create a kind of a pipeline as part of dev ops release to create it automatically as well. It’s just bolts onto the same binary.
There’s a bunch more use cases for NGINX ingress.
Things that are aligned with API authentication, rate limiting, split routing, conditional routing and even NGINX snippet which brings NGINX configurations.
This isn’t on plan for cloud 2.0 but feel its worth mentioning.
The F5 Ingress link for Big-IP environments.
How this comes into play is you do need something to bring your traffic to the Ingress Controller in front of the kubernetes cluster.
Here we demonstrate having the big-ip as external load balancer but in that set up an ideal goal from an operation standpoint is to be able to configure and control that big IP external using native kubernetes API.
That’s possible through Ingress link and what makes up Ingress link is something called CIS container ingress services is what it stands for.
It is a big IP product however it’s installed in the cluster as a kind of controller, listening for changes to Kubernetes API via the ingress and then that informs the Big-IP
so for example you need a new Virtual Server or a new service you can do that via kubernetes native API and then CIS under the covers will bubble that up and then make that change under the covers for you so it’s a nice way to kind of glue external load balancer needs with your kubernetes cluster especially if you would like to manage everything via kubernetes API
As stated before separation of duty and helping with making sure that folks are enable to do their role, for example net ops and dev ops can be easier to keep separated with this solution.
