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.
