Last Updated on May 12, 2019

Reading Time: 4 minutes

As far as I know this is the complete list of Ingresses available for Kubernetes. Technically ambassador isn’t an ingress but it acts like one which is good enough. As you can probably see I’ve made quite a large table comparing features.

For those who struggle with reading the image there’s a link to open the google sheet directly below. Feel free to leave comments and I’ll update this blog post with corrections.

View the full Google sheet here.

Based on the features, my own experience and anecdotal blog evidence I’ll attempt to provide my usual unbiased opinion on each.

This is probably the most commonly installed ingress. Safe, boring and reliable. Supports http, https and does ssl termination. You can also get TCP and UDP working but from looking at the Github issues I think I’d try to avoid it. You get quite a few nice load balancing options as well as powerful routing, websocket support, basic authentication and tracing.

It’s quite common to use this ingress in conjunction with cert-manager for generating SSL certs and external-dns for updating cloud based DNS entries.

The lack of dynamic discovery is a bit of a downer. There is a config generator that you can use to automate this but apparently it’s terrible.

Note: There’s the official Kubernetes ingress which is what we’re talking about here. There’s also the Ingress from Nginx corp which has different settings.

Most people will use Kong when they want an API gateway. Kong includes a plugin system that extends the features to beyond what a normal Ingress would do. I wouldn’t use this as a generic http load balancer but if you want API management features then Kong is definitely a good choice.

At previous companies I’ve always put an ingress in front of Kong and routed /api/ requests to it. However, more recently the developers of Kong have been making a lot of progress turning Kong into an Ingress.

This one surprised me with just how many features it has. The resiliency features look awesome and from reading a broad selection of tech blogs it seems quite stable. Supporting dynamic configurations is a big upgrade if you’re currently using ingress-nginx.

One downside is it only supports http, https and grpc. If you need TCP load balancing then you’ll need to choose something else. TCP is now in the Alpha release.

Another consideration is minimizing server reloads because that impacts load balancing quality and existing connections etc. Traefik doesn’t support hitless reloads so you need NGINX or Envoy Proxy for this. For a lot of people this is a big deal.

This is the king of the ingresses when it comes to load balancing algorithms. It’s also the best choice for load balancing TCP connections. HAProxy has a track record of being extremely stable software. You can also get a paid support subscription if you want one.

Another ingress based on HAProxy under the covers. Voyager is packaged up nicely and the docs look good. I couldn’t see where the load balancing algorithms were configured so assumed it’s just defaulting to round robin. If that’s wrong let me know in the comments and I’ll update.

Based on Envoy this has some more modern features like supporting Canary deploys. It also has a good set of load balancing algorithms and support for a variety of protocols. Unlike some of the others listed I got the impression from Github that this is under pretty rapid development still. There are discussions about adding more features which seems promising.

As mentioned above this one isn’t technically an ingress if you go by the strict Kubernetes definition. With Ambassador you simply annotate your services and it acts like an ingress by routing traffic. Ambassador has some very cool features that none of the other ingresses have like traffic shadowing which allows you to test services in a live production environment by mirroring request data.

Ambassador integrates nicely with both Opentracing and Istio.

If you’re already running Istio then this is probably a good default choice. It has some of the more modern features that Ambassador has. It also has fault injection which looks like it might be fun to play with. However, Istio is currently doing a lot of work in this area and is moving away from Ingress towards Gateways. So if you’re looking for something that’s not changing every 5 seconds you may want to still consider Ambassador.

Istio ingress also doesn’t support things like redirect from cleartext to TLS & authentication which are common features you want in your edge.

Gloo has some unique features like function based routing and service discovery across multiple IaaS, FaaS and PaaS providers. This is definitely the Ingress you should evaluate if you’re moving heavily in a serverless direction.

Summary

There’s no clear winner in this one because you’re going to need to pick the ingress based on your requirements. No single ingress currently does it all.

The safest choice is ingress-nginx. This is the one that most people use and it’s extremely reliable. The problem with ingresses is that when there’s a problem literally everyone complains. Ingress-nginx will cover 99% of use cases, so start here and then test others in a dev environment for a while before switching. Before you begin I’d recommend you read this blog to get ahead of some of the problems you may encounter.