Comparison of Kubernetes Top Ingress Controllers

By Juan Ignacio Giro
Kubernetes Top #IngressControllers

Ingress is a necessary component in all Kubernetes deployments and a topic that we’ve covered in some detail before. As discussed in depth in line with their management here, ingresses connect external traffic to Kubernetes services, allowing the app you run in Kubernetes to be accessed by users. The ingress abstraction is also treated uniquely in Kubernetes. Unlike some other components, objects or services, for example, your ingress controller doesn’t start automatically when a cluster is launched.

Choosing the right ingress controller becomes important when you start considering traffic and load coming to your Kubernetes cluster. There is even a way to use multiple ingress controllers within a cluster with the help of annotation and class. A typical example is to provision two ingress-controllers:

  • One to handle the external traffic (a public-facing ingress).
  • The other to manage the private traffic (all internal traffic within the VPC—allowing services and hosts in the same network to access internal services running in Kubernetes).

They are each selected by the use of annotations as stated. The tricky part is choosing the appropriate ingress controller to use in the first place, but that’s a challenge we are going to consider in this article.

The tricky part is choosing the appropriate ingress controller to use in the first place, but that’s a challenge we are going to consider in this article.


Yes, this is a review and comparison of the top ingress controllers for Kubernetes, and we’re starting with Kong. Kong wasn’t initially developed to function as a standalone ingress controller, but the developers behind this controller have added so much that it is now capable of holding its own. More importantly, Kong is very developer-friendly.

This is the ingress controller to use if you want an API gateway. There are also plenty of modules and add-ons for Kong, which means the basic features can be extended to better suit your specific needs. The only downside is the lack of optimization when Kong is used as a load-balancer for HTTP traffic, but you can tweak the settings or use add-ons to make it work.


Traefik has become incredibly popular in the developers’ community, and there are some great reasons for its sudden fame. For starters, it is very easy to use and integrate with any Kubernetes environment. You get dynamic backend service and full support for TCP, HTTP, HTTPS, and GRPC. It even supports round-robin and weighted round-robin for load balancing.

Traefik can deal with multiple instances of your programs (with multiple load balancing capabilities), and use a services configuration to work out how to reach an actual program.

I personally love using Traefik for HTTP traffic. It supports Let’s Encrypt out of the box, so all traffic can be directed via the more secure HTTPS. It also handles HTTP/2 really well and can be optimized to handle heavy loads without breaking a sweat. If you ever run into problems when using Traefik, you can rely on premium support offered for this ingress controller.


Next, we have HAProxy, which is considered the most capable ingress controller when it comes to load balancing. HAProxy has been improved with each iteration released to the market, so it is not surprising to see its load balancing algorithms being as capable as they are today. Even better, you don’t have to dig deep into the configs to fully utilize these algorithms.

It also has a great reputation for being stable, which is why many production Kubernetes environment s use HAProxy as the ingress controller of choice. With some tweaking, you can run a capable Kubernetes cluster that can handle everything from HTTP traffic to TCP load balancing. To complete the set of features offered by HAProxy, use Grafana or Datadog for advanced monitoring.

Istio Ingress Gateway

Last but certainly not least, we have Istio Ingress Gateway. This is considered the best Kubernetes ingress controller by most developers because of its straight out of the box performance. If you already use Istio, Istio Ingress is the logical choice. You get guaranteed compatibility and all the features you wouldn’t expect from a controller.

A couple of downsides to using Istio Ingress is how the controller now offers more features that make it a capable Gateways rather than an ingress. Also, we have to use Istio service mesh to deploy Istio ingress. It is based on Envoy though and supports all types of traffic. Plus, Istio has sufficient load balancing features, including passthrough and random load balancing. It also supports tracing when you use Jaeger or Zipkin UI.


As an honorable mention, we have the default ingress-nginx. This ingress is the safest choice if you don’t want to worry about configuring your own ingress controller. You miss out on the advanced features – like the algorithm-based load balancing – but you also don’t have extra headaches to worry about.

However, something to consider with Nginx, via the ConfigMaps we can do a lot of tuning to the Nginx web server running inside the pod, such as enabling powerful and detailed Virtualhost Traffic Stats (VTS) and different headers options, etc. There are also two versions of the Nginx controller; the community supported one, and the one supported by NGNX Inc here which offers some additional features.

Nginx tends to be opted for as a ‘default’ ingress controller, but you can look into other controllers in the development environment for more extensive features. Any of these top ingress controllers are very useful, although some may suit certain production environments better than the others.


Ambassador is a recent addition to the ingress controller market which has become super popular. As well as acting as an ingress controller, Ambassador also functions as a strong API gateway. It’s a dynamic open source Kubernetes-native microservices API gateway built on the Envoy Proxy.

Ambassador essentially serves as an Envoy ingress controller but with many more features including:

  • Istio and Consul integration
  • Self-service configuration through Kubernetes annotations
  • Support for  WebSockets, gRPC and HTTP/2, and TCP

One last thing to know about choosing an ingress controller: stick to what you need. I know how tempting it is to go with the popular, most marketed option, but the better way is to choose an ingress controller whose features you can actually use and optimize; always.

Once you have an ingress controller you like the most, the rest will be easy from there. Implementing the new controller—or even going further and adding multiple controllers—will be easy with the kind of compatibility offered by these top controllers.

Read more about managing ingress controllers on Kubernetes here.

Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.