13 Key Considerations When Selecting an 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.
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.
Conclusion
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.
