The numbers on the adoption of Kubernetes vary from report to report, but there can be no argument that the trust organizations have with Kubernetes is increasing year to year and the percentage of containers running in production is growing rapidly. While Kubernetes has established the necessary trust, organizations are quickly finding gaps in this solution that need to be filled.
When it comes to ingress controllers for Kubernetes, there are a plethora of choices all providing some level of application delivery functionality. Whether offered as open-source or from a load balancing vendor, nearly all these are designed to run the ingress controller role as a containerized component, therefore, restricting the full capabilities that can be delivered and should be available to meet customers’ expectations. As a load balancing vendor, we believe customers should have access to all the functionality and performance expected from their ADC:
- Application Delivery Controller (ADC) features
- Native WAF functionality
- Pre-Authentication/ SSO
- Advanced health checking
- Global Server Load Balancing
- Advanced content switching
- Performance – Ability to run in the kernel-space
- Coexist with legacy systems – Enhance migrations and support from legacy to microservices
- Direct route to pods – Reduce east-west traffic
Providing Functionality
Talking to customers and discussing the challenges with the ingress controllers of today, Kemp took this approach to provide ingress functionality outside of the Kubernetes cluster (therefore providing customers will all the rich features they require to provide the performance, availability, and security for their containerized applications.
In addition to these key features, there is the challenge of how to properly align the teams in the organization against the microservices ecosystem. Kubernetes is built with the assumption that every organization has adopted a cross-functional DevOps model which could not be further from the truth and up until now, ingress controllers have not addressed this challenge. The Kemp Ingress Controller (KIC) tackles this by operating in two modes supporting the individuality of how organizations operate. (see https://kemptechnologies.com/blog/netops-and-dev-for-microservice-load-balance/ )
Service Mode: This mode is unique to Kemp Ingress Controller and allows NetOps teams to own the network infrastructure including the ingress controller / ADC for publishing these containerized apps to the outside world. The NetOps team can delegate the publishing of services to the AppDev team using a constrained API, therefore, avoiding the pitfalls a shared ingress controller introduces to this kind of shared ownership.
Ingress Mode: For those organizations that adopted DevOps, where cross-functional teams manage the publishing of applications and the underlining network infrastructure to support the apps, the standard ingress mode of KIC can be leveraged.
If your organization is struggling with the challenges of today’s ingress capabilities or if you are just starting to plan for a migration to microservices or a greenfield deployment, the Kemp Ingress Controller is now available allowing customers access to these latest capabilities.
