中文
A recent Twitter conversation I had with Matt 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 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.
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 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.
What Makes NGINX’s Ingress Controller Different?
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:
- Development philosophy – NGINX’s top priority for our Ingress controller is to deliver long‑term stability and consistency. We make every possible effort to avoid changes in behavior between releases, particularly any that break backward compatibility. We promise you won’t see any unexpected surprises when you upgrade.
- Continual production readiness – NGINX provides commercial support for every release of our Ingress controller, so every release is built and maintained to a supportable, production standard. You benefit from this “enterprise‑grade” focus equally whether you’re using NGINX Open Source or NGINX Plus.
- Integrated codebase – NGINX’s Ingress controller uses a 100% pure NGINX or NGINX Plus instance for load balancing, applying best‑practice configuration using native NGINX capabilities alone. It does not rely on any third‑party modules or Lua code that have not benefited from our interoperability testing. Furthermore, the community’s Ingress controller relies on slower Lua code for some functionality native to NGINX Plus.
- Security – We don’t assemble our Ingress controller from lots of third‑party repos; we develop and maintain the load balancer (NGINX and NGINX Plus) and Ingress controller software (a Go application) ourselves. We are the single authority for all components of our Ingress controller.
- Support – NGINX’s Ingress controller 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 NGINX’s Ingress controller:
- 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 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.
