Matt’s tweet from a Twitter conversation I had with him recently motivated me to get cracking on my to‑do list:
- Get myself to Seattle for KubeCon + CloudNativeCon North America 2018! Waiting til the week before the event meant the hotels were full, but I booked a sweet Airbnb. I’m behind on planning my unconference activities too – any recs?
- Corner our VP of Product Management to ask him “dumb questions” about Kubernetes Ingress controllers
- Write up my annual blog post for NGINX. So thanks, @Mierdin, for inspiring someone from NGINX to come right out and say…
There are two NGINX Ingress controllers for Kubernetes hosted on GitHub – one maintained by the Kubernetes open source community, kubernetes/ingress-nginx, and one maintained by NGINX, Inc., nginxinc/kubernetes-ingress.
I can see why there may be some confusion, as these projects started around the same time, have really similar names, and essentially just deploy NGINX in front of Kubernetes. But yes, there are two NGINX Ingress Controllers for Kubernetes, and they are very different.
What’s a Kubernetes Ingress Controller, Anyway?
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 NGINX Ingress controller you are using? And what are the differences between the two? (Well, actually there are three, when you include NGINX, Inc.’s version for NGINX Plus.)
To see which Ingress controller you are using, check the container image of the running Ingress controller (docker ps). For nginxinc/kubernetes-ingress, the Docker image is published on DockerHub as nginx/nginx-ingress.
What Are the Differences?
Now, with the basics out of the way, we can dig into the actual differences. Here’s how nginxinc/kubernetes-ingress differs from kubernetes/ingress-nginx, straight from NGINX’s VP of Product Management, Sidney Rabsatt:
- Development philosophy – nginxinc/kubernetes-ingress aims for a stable, reliable, and high‑quality feature set. We make every possible effort to avoid changes in behavior between releases, particularly any that break backward compatibility. kubernetes/ingress-nginx seems to prioritize rapid development of new features without as much concern for stability and backward compatibility.
- Production readiness – As a result of the philosophy behind nginxinc/kubernetes-ingress, it’s built and maintained to a supportable, production standard, and that applies to both the version for NGINX Open Source and the version for NGINX Plus.
- Integrated code base – nginxinc/kubernetes-ingress doesn’t rely on third‑party modules, which can introduce instability because they’re governed by their own priorities rather than a concern for interoperability with projects that rely on them. kubernetes/ingress-nginx relies on Lua for some functionality native to NGINX Plus.
- Security – Because we maintain all the code, we can quickly resolve and patch any security issues that affect nginxinc/kubernetes-ingress as soon as they are identified.
- Support – nginxinc/kubernetes-ingress is fully supported for NGINX Plus customers, and users of NGINX Open Source who have a paid support contract.
And while we’re here, let’s review some of the key benefits you get from NGINX Plus when using it with nginxinc/kubernetes-ingress:
- Additional capabilities – Real‑time metrics, additional load‑balancing methods, session persistence, active health checks, JWT validation
- Dynamic reconfiguration – Faster, non‑disruptive reconfiguration ensures you can deliver applications with consistent performance and resource usage
- Commercial support – it’s like having an NGINX developer on your DevOps team!
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 G7 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 NGINX Ingress Controllers for Kubernetes at our GitHub repo.