Kong Inc. released Kong for Kubernetes version 0.8, a Kubernetes Ingress controller that works with the Kong API Gateway. The release adds Knative integration, a new cluster level Custom Resource Definition, and annotations to minimize configuration.
The Kong Gateway is an open source API gateway built on top of NGINX. The Kong for Kubernetes product is composed of two parts: "a Kubernetes controller, which manages the state of Kong for K8S ingress configuration, and the Kong Gateway, which processes and manages incoming API requests", according to the announcement blog post. Most managed Kubernetes deployments on public clouds utilize the cloud-vendor provided Ingress controllers. These controllers work off the vendor's load balancer and other compute abstractions. Kubernetes deployments also have the option of using other controllers - NGINX and HAProxy being among them.
InfoQ reached out to Reza Shafii, VP of Products at Kong Inc., to find out more about this release as well as Kong for Kubernetes' capabilities in general.
Shafii explains that Kong for Kubernetes adds all the features that the Kong API Gateway has to the Ingress. These are API management features - capabilities that "enable dynamic policy management of API traffic such as application of OIDC-based authentication, advanced rate limiting, request caching, or streaming of logs and metrics to different analytic providers at the same time". Shafii elaborates further on the performance aspects:
These include things such as a high performance profile (e.g., sub-millisecond latency and 25K+ transactions per second) and support for multiple protocols and interaction patterns (REST, graphQL, gRPC, TCP, etc.) – while providing all of the operations of Kong Gateway through Kubernetes CRDs. This last point is important because that is what then makes the operational aspect of the ingress consistent across all cloud providers and on-premises.
Although Kong is built on top of NGINX, its ingress controller has marked differences compared to the default nginx-ingress-controller as well as NGINX's own commercial controller, according to Shafii. These differences lie in the API management features that Kong has, as well as the fact that for users of Kong Gateway, it offers a "consistent API management lifecycle" across Kubernetes and non-Kubernetes workloads.
Image courtesy : https://konghq.com/blog/kong-for-kubernetes-0-8-released/ (used with permission)
The 0.8 release adds Ingress support for Knative. Knative is a serverless platform for container-based workloads on Kubernetes that provides "higher-level abstractions for common app use-cases". The default Ingress for Knative is based on Istio, and there are alternatives like Gloo also available. Shafii explains the differences between Knative's default Ingress and the one provided by Kong:
What we have learned from our community and customers is that most use cases don’t require the weight of Istio to run serverless workloads. And in fact, the heavy weight of Istio is one of the reasons that prompted us to initiate the Kuma service mesh project. Kong Gateway’s plugin architecture and focus on extensibility helps keep Knative workloads focused solely on business logic.
It is also possible to use a cloud vendor's load balancer with Kong's ingress controller. Shafii fills in the details:
Cloud load balancers provide a way to balance traffic across multiple Kong Gateway nodes, and Kong Gateway nodes help manage traffic to multiple services within a cluster. In fact, for most users, we recommend the use of load balancers such as those of AWS or GCP to front Kong Gateway's. This provides an endpoint inside the virtual private network in the cloud, which can then be exposed to other networks (different AWS accounts), other partner networks or directly on the internet.
Similar to network traffic metrics provided by cloud vendors like GCP and AWS, and gateways like Istio and Gloo, Kong for Kubernetes can collect "metrics such as HTTP status and error codes, traffic throughput/latency, and (ingress/egress) bandwidth consumed on a per route and services level". Health-related metrics for the Kong Gateway itself such as "connections served, connection currently in use, shared memory usage and cache hit ratio" are also available, according to Shafii. He adds that these metrics can be integrated with Prometheus, Data Dog, StatsD, Zipkin and Jaeger.
The 0.8 release has breaking changes for path-based routing and some annotations are deprecated. The changelog has the complete list of changes.
