A recent Twitter conversation I had with Matt motivated me to get cracking on my to‑do list:
There are two popular Kubernetes Ingress controllers that use NGINX – both are open source and hosted on GitHub. One is maintained by the Kubernetes open source community (kubernetes/ingress-nginx on GitHub) and one is maintained by NGINX, Inc. (nginxinc/kubernetes-ingress on GitHub). For ease of reading in this post, we’re referring to them as the community’s Ingress controller and NGINX’s (or our) Ingress controller respectively.
I can see why there may be some confusion, as these projects started around the same time, have really similar names on GitHub, and implement the same function: providing an Ingress controller based on NGINX. But yes, there are two Ingress controllers for Kubernetes that use NGINX, and they are very different.
Before we go into the differences, let’s back up a bit and ask: what is a Kubernetes Ingress controller?
By default, applications running in Kubernetes pods are not accessible from the external network, but only from other pods within the Kubernetes cluster. Kubernetes has a built‑in configuration object for HTTP load balancing, called Ingress, that defines rules for external connectivity to the pods represented by one or more Kubernetes services.
When you need to provide external access to your Kubernetes services, you create an Ingress resource that defines the connectivity rules, including the URI path, backing service name, and other information. The Ingress controller then automatically configures a frontend load balancer to implement the Ingress rules.
So let me ask a couple more “dumb questions”. How do you tell which of the Ingress controllers based on NGINX you are using? And what are the differences between the two? (Well, actually there are three, if you separately count NGINX, Inc.’s version for NGINX Plus.)
To see which Ingress controller you are using, check the container image of the running Ingress controller. For NGINX’s Ingress controller, the Docker image is published on DockerHub as nginx/nginx-ingress. The answer to the second question follows.
Here’s how the goals of NGINX’s Ingress controller differ from the community’s Ingress controller, straight from NGINX’s VP of Product Management, Sidney Rabsatt:
And while we’re here, let’s review some of the key benefits you get from NGINX Plus when using it with NGINX’s Ingress controller:
Of course NGINX and NGINX Plus can be deployed on any platform including bare metal, containers, VMs, and public, private, and hybrid clouds.
Like Sidney always says, would you rather see a cover band, or the real thing?!
NGINX is at booth G12 at KubeCon + CloudNativeCon North America 2018 in Seattle, December 11–13, giving demos of NGINX Controller for managing load balancers, the new API Management Module, and explaining, over and over again, that you gotta go stable, lightweight, and production ready. Hope to see you there!
Read more about the differences between the Kubernetes Ingress controllers that use NGINX at our GitHub repo.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."