The evolving contributions and increased adaptation of Kubernetes have resulted in huge growth of its ecosystem. When creating a new cluster or maintaining an existing cluster, choosing the right ingress controller will be an important decision.
Due to the vast number of potential options available, making the right choice can be overwhelming. In this article, we will cover the top considerations which you should factor into your decision-making process to avoid making any costly mistakes.
A default ingress resource is designed to support HTTP based traffic. If your application requires support for additional protocols such as TCP and/or UDP ensure the ingress controller supports the protocol(s) required for your specific use case.
There is no point in reinventing the wheel - if your application requires client management functionality such as rate limiting, throttling, and blocking there are ingress controllers available that support these features.
Ingress controllers will route traffic based on a hostname and path. However, for those use cases which require routing using something else such as headers or query parameters will require an ingress controller that supports this functionality.
Is availability a critical factor? Make sure the ingress controller has the appropriate mechanisms to handle those inevitable sticky situations you might encounter. For example, some ingress controllers support circuit breakers which can take unhealthy services offline.
Traditionally, round-robin is the default algorithm used for load balancing and supported by the majority of ingress controllers. However, if a different option is required you should factor this within your decision.
Some ingress controllers support authentication management which enables all services exposed in the traffic flow to obtain the benefits of authentication management without incurring the complexity of implementing this functionality at the individual service layer.
Ensure your third-party software used for monitoring and logging is supported by the ingress controller that is being considered. Without this, there will a lack of visibility over metrics and logging.
Should service meshing be required in the future ensure it should be vital that the ingress controller supports it. In addition, if you are planning on making use of the Service API (Ingress v2) ensure this is also supported by the controller of your choice.
Some ingress controllers support different mechanisms for traffic distribution. If your specific use case requires traffic distributed using A/B testing or canary deployments ensure the controller you are considering supports the distribution method that is required.
Having a graphical interface can be useful if for debugging issues with your ingress resources or to provide developers with useful information and metrics about the application’s live status.
A single ingress controller might not be enough to cover all the different use cases within the same cluster. In this case, it is possible to use a combination of Ingress controllers. For example, you may have one ingress controller for handling external traffic routed to the cluster and have another ingress controller that handles in-cluster traffic.
Every Ingress Controller must only handle Ingress resources for its particular class.
< 1.18, Ingress resources should be annotated with the
kubernetes.io/ingress.class annotation set to
the class of the controller you want to use. When using versions of Kubernetes
>= 1.18, Ingress resources should
ingressClassName field set to the class of the controller you want to use.
There are many factors that need to be taken into consideration before selecting the appropriate ingress controller for your clusters. Avoid selecting a hype-driven or popular option and be deliberate about your requirements when evaluating ingress controllers according to the criteria we have listed.
Finally, we have put together a comparison table comparing a variety of ingress controllers and their respective features.