13 Key Considerations When Selecting an Ingress Controller for Kubernetes

key considerations for selecting ingress controller for kubernetes

Ingresses are critical to any successful Kubernetes deployment. Ingresses allow you to define how external (and/or internal) traffic is routed to services within your cluster. The Kubernetes documentation states that:

“An Ingress can be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.”

However, Ingresses themselves don’t do anything — they’re just metadata. The heavy lifting is performed by ingress controllers. An Ingress without an ingress controller won’t do anything.

There’s one more catch: while there are a number of system controllers (like ReplicaSet controller, endpoints controller, namespace controller, and others) that are managed by the Kubernetes control plane, ingress controllers are not automatically started with a cluster. You have to install, configure and manage your own ingress controllers.

It’s also possible to have multiple ingress controllers in the same cluster. You can divide the routing space by using ingress class annotations so that each Ingress knows which Ingress controller should be handling it. You could end up using a combination of ingress controllers for different scenarios within the same cluster. For example, you may have one ingress controller for handling external traffic coming into the cluster, including bindings to SSL certificates, and have another internal ingress controller with no SSL binding that handles in-cluster traffic.

There are scores of ingress controllers to choose from. The Kubernetes documentation has a list of popular Ingress controllers here.

These controllers have varied feature sets and varying levels of community or commercial support. Some are pure edge routers, while others have features more akin to service meshes.

See the API Gateway Cloud Natives TrustWant to simplify the discovery, security, and deployment of APIs and microservices? Explore Traefik Enterprise today.Learn More

Selecting the right ingress controller

So how do you choose the right ingress controller? There are several criteria that are important to consider when doing so. In this post I’m not going to do a feature comparison between specific ingress controllers, since there are many head-to-head comparisons on the internet already, and because there are so many ingress controllers. Rather, I’m going to discuss what features you should be weighing when selecting an ingress controller.

1. Traffic protocol

Are you just routing HTTP(S), HTTP/2, or websockets? Do you want to route TCP/UDP or gRPC? Not all ingress controllers support all these protocols, so you’ll have to check which protocols an ingress controller supports.

2. Dynamic configuration updates

Do you require zero-downtime configuration changes — often called “hitless reloads”? Some ingress controllers require downtime in order to update configuration, while others update dynamically without downtime.

3. Resiliency

Do you need rate limiting, retries, or circuit breakers at the edge, or have you built this functionality into your services yourself? Some ingress controllers support these features, which means you won’t have to code them yourself.

4. External load balancer integration

Are you integrating with an external, managed cloud-based load balancer? Make sure the ingress controller you select integrates well with your external load balancer in order to reduce work and management for your networking team.

5. Service mesh

Ingress controllers can be configured to handle external traffic (traffic originating outside the cluster),  internal traffic, or both. If you need to observe or trace internal traffic, you may need a special breed of ingress controller — a service mesh. Kubernetes provides standards for service meshes through the SMI Specification for interoperability. If you do require a service mesh, make sure you pick the right tool for the right job. Ingress controllers and service meshes are not mutually exclusive.

6. API gateway

Do you need an ingress controller or an API gateway, or something that does both? Typically API gateways integrate business logic, while edge routers are typically business agnostic. For example, API gateways let you monitor traffic per customer, or measure transactions for billing purposes. If you require business logic at the edge, you should probably look at an API gateway instead of an Ingress controller. Just as with service meshes, ingress controllers and API gateways are not mutually exclusive.

7. High availability

Can you afford downtime when a server restarts for either planned or unplanned maintenance? If so, you need high availability for your Ingress controller. Not all ingress controllers support high availability.

8. Load balancing algorithms

What sort of algorithm-based routing do you need? Most ingress controllers support Round Robin, but if you want least connection so that the load on your services is taken into account, you’ll need an ingress controller that supports more advanced load balancing algorithms.

9. Advanced traffic shifting

Do you need to perform canary testing (shifting a percentage of traffic to different services for progressive exposure)? Load balancing lets you spread the load of a service, but not all load balancers can split traffic using more sophisticated rules. If you’re testing in production using techniques like canary testing, make sure the ingress controller you select supports traffic shifting.

10. Resources constraints

Are you cost-sensitive as far as resources in your cluster are concerned? Ingress controllers can be resource-intensive, so if you are cost-sensitive, you’re going to be better off with a lightweight ingress controller. Some ingress controllers support scaling up and down, while others do not.

11. Monitoring

Do you need to integrate with existing metrics and log collection systems? Some ingress controllers offer limited monitoring and logging and may not support your specific monitoring and logging tooling.

12. Support

Do you need enterprise support? Open source ingress controllers are easy on the checkbook, but what happens when you need support in the middle of the night? Remember, some open source Ingress controllers offer enterprise support plans.

13. Ecosystem

Make sure the ingress controller you are considering has support in the Kubernetes partner ecosystem.


As you can see, there are many factors that require thought before you can select the right ingress controller for your clusters. Don’t just select a hype-driven, popular option — be deliberate about your requirements and then evaluate ingress controllers according to the criteria listed above. If you do, you’ll have made an informed decision about a very important part of your infrastructure.

For enterprises deploying microservice architectures at scale, powerful networking solutions are a necessity. Traefik Enterprise combines API management, ingress control, and service mesh all together in one simple control plane. It’s ecosystem agnostic, highly available, highly automated, and comes with dedicated support. So if you’re evaluating ingress controllers, consider starting a free 30-day trial of Traefik Enterprise or request a demo.

Try the API Gateway Cloud Natives TrustWant to simplify the discovery, security, and deployment of APIs and microservices? Try Traefik Enterprise free.Start Your Free Trial

Latest from Traefik Labs

The API Gateway Model: Centralizing Control in Complex Microservices Architectures

The API Gateway Model: Centralizing Control in Complex Microservices Architectures

Read more
5 Qualities All API Gateways Need in 2024

5 Qualities All API Gateways Need in 2024

Read more
Seamlessly Add Advanced Capabilities to Traefik OSS

Seamlessly Add Advanced Capabilities to Traefik OSS

Watch now

Traefik Labs uses cookies to improve your experience. By continuing to browse the site you are agreeing to our use of cookies. Find out more in the Cookie Policy.