October 25, 2019

13 Criteria for Choosing the Best Ingress Controller for Your Kubernetes Deployment

Written by Manuel Zapf, Solution Architect, Containous
Rate this item
(0 votes)

Selecting the right ingress controller is critical to the success of your Kubernetes deployment - but the choice can be challenging given that there are more than a dozen popular options listed in the Kubernetes documentation alone. Ingresses themselves provide the ability to define the way that external (as well as internal) traffic is routed to services in your cluster. For example, an ingress can be used to add externally-reachable URLs to services, load balance traffic, terminate SSL and TLS, and provide name-based virtual hosting.

That said, ingresses are simply metadata and cannot function without an ingress controller to do all the work. Implementing this controller requires a bit of effort; unlike some other system controllers that start with a cluster automatically and are managed by the Kubernetes control plane, you must install, configure, and manage your ingress controller yourself.

Another hurdle is that you may want to utilize multiple ingress controllers at once within the same cluster. Ingress class annotations make it possible to tell each ingress which ingress controller to listen to, enabling thoughtful reactions to myriad scenarios you might encounter. For instance, one ingress controller featuring SSL binding could handle external traffic to the cluster, while another without SSL binding could handle internal traffic.

The breadth of ingress controllers available naturally include a wide range of features, with some functioning purely as edge routers and others acting more akin to service meshes. These controllers vary in the levels of active support they receive as well, be them from open source communities or commercial entities.

Rather than comparing specific Ingress Controllers head-to-head (it's a well-trod topic, and at the same time there are too many controllers out there to cover them individually), I'll focus on 13 key features you should consider as you evaluate your options:

1) Traffic protocol support

Be sure to check that the ingress controller you choose supports the protocols you want to use. Whether you're simply routing HTTP(S), HTTP/2, or websockets (or want to route TCP/UDP or gRPC), ensure that your ingress controller accommodates those plans.

2) Resiliency

If you haven't already ingrained resiliency measures such as rate limiting, circuit breakers, and retries into your services, you can add these features at the edge (and spare your team from writing that code) by enlisting an ingress controller that includes them.

3) High availability

Not every ingress controller supports high availability. If the application your Kubernetes deployment supports has no tolerance for downtime, make sure to choose a controller that suits your availability requirements. 

4) Resource usage

Some ingress controllers use up more cluster resources than others. Also, controllers may or may not support scaling. If resource costs are important to your use case, a more lightweight controller may be your best option.

5) Dynamic configuration updates

Ingress controllers may be able to update configuration dynamically, with zero downtime. If this ability to perform so-called "hitless reloads" is important to your requirements, this feature can help narrow down your controller selection considerably.

6) Integration with external load balancers

If you use an external managed load balancer in the cloud, your networking team will appreciate the reduction in work and management overhead realized by choosing an ingress controller that integrates with it well.

7) Load-balancing algorithm support

Be sure to select an ingress controller that supports the algorithm-based routing you want to use. For example, most controllers will support round robin load balancing, but using least connection (ensuring that the load on services is considered as a factor) requires a controller that supports more complex algorithms and capabilities.

8) Sophisticated traffic shifting

While load balancers spread out a service's load, only some are able to split traffic in-line with advanced requirements. Be sure to select an appropriate ingress controller if your needs include performing more complex traffic shifting techniques, such as canary testing.

9) Service mesh

There are specialized ingress controllers available designed to function as a service mesh - observing or tracing internal traffic. Kubernetes uses the SMI Specification as its standard for ensuring service mesh interoperability. Selecting the most appropriate tool for your needs in this area will pay dividends later. 

10) API gateway

You may have requirements well-suited to using an API gateway, or an ingress controller, or a way to accomplish both tasks. In general, API gateways are used to integrate business logic, such as measuring customer traffic or transactions for accurate billing. In contrast, edge routers are usually business-agnostic, making an API gateway a better fit than an ingress controller if business logic is needed at the edge.

11) Monitoring and logging

Ensure that the ingress controller you use supports and easily integrates with any existing monitoring and log collection tools. 

12) Support

Be sure to find an ingress controller that aligns with the support you'll require. While generally open options save on cost while enterprise alternatives are better at providing support, plans are available for many open source ingress controllers as well. 

13) Kubernetes ecosystem support

Finally, any ingress controller you select should feature support from the Kubernetes partner ecosystem.

By performing a thorough evaluation of your ingress controller options and utilizing these criteria (and prioritizing which are must-have and which you can compromise on), you can ensure that you make the right decision in selecting this key piece of your Kubernetes infrastructure.

To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

##

About the Author

Manuel Zapf is Traefik Maintainer & Solution Architect working with Containous, creator of Traefik, the cloud-native edge router, and Maesh, the open source service mesh. His special interest is in deploying applications scalable by using cloud and container technologies. Gopher lover.

Last modified on October 25, 2019

Sponsors

Learn more about A10 Networks

Learn more about Alluxio

Learn more about Blameless

Learn more about Containous

Learn more about DivvyCloud

Learn more about Lacework

Learn More about MacStadium

Learn More about Mirantis

Learn More about Platform9

Learn More about Sauce Labs

Learn More about solo.io

Learn More about Stackrox

Learn more about Wallarm

Learn More about Weaveworks

Latest Tweets

Latest Videos