Today, we’re thrilled to announce the general availability of Kong Ingress Controller 2.0 (KIC) – the most robust, scalable, and extensible version of our Kubernetes Ingress Controller to date. This is a major milestone both for the KIC product as well as for the Kong community as a whole. In addition to KIC 2.0’s new features, it also sets the foundation for us to more rapidly improve the user experience and add more capabilities. 

By releasing KIC 2.0 as GA we are taking a major architectural leap forward. Our objective is always to bring familiarity, ease of use, and a robust experience for DevOps. This dictated the major changes we made with utilizing Kubebuilder as the controller technology underpinning KIC. With the upgrades in 2.0, we’re able to provide better controller lifecycle management, greater observability, superior Kubernetes API caching, and resource reconciliation along with many other enhancements. Below we’ll describe some of the updates in KIC 2.0 and how they will help users better operationalize Kubernetes deployments at scale.

UDP Support for Speed-sensitive Use Cases 

For use cases where being lightweight and fast are the most important requirements (e.g. audio, video, and gaming), UDP is preferable to TCP.  While KIC has provided support for TCPIngress for a long time, it did not provide support for the UDP proxying debuted in Kong Gateway 2.2. With KIC 2.0 we’ve added UDPIngress support, which will enable the use of Kong’s critical API management capabilities for observability, security, and traffic management within KIC for UDP.

Enhanced Monitoring and Observability of the Ingress Controller 

Observability is critical to ensuring that all of the constituent components of an end application are healthy and performing well. When organizations don’t have visibility into the full picture of inputs and outputs impacting their application, it’s difficult to efficiently isolate a given issue. The magnitude of the observability challenge in Kubernetes was one of the primary drivers that led us to create the ingress controller in the first place. 

Another set of observability challenges we’ve frequently heard from customers is in how we enable monitoring of the ingress controller. To alleviate this challenge, KIC 2.0 provides a native Prometheus integration for KIC metrics. This new integration allows users to more easily observe how long it takes KIC to apply its configuration and respond accordingly. This way, you can investigate and be alerted on any significant performance issues and do more investigations on high-load setups.

Simplified Operations Across Multiple Kubernetes Namespaces and Teams

We’ve heard from our enterprise customers and community that being able to efficiently and effectively monitor Kubernetes and the ingress controller remains a challenge. With KIC 2.0, we’ve provided the ability to specify a set of Kubernetes namespaces to watch instead of the all-or-nothing approach that was available in previous versions. 2.0 brings a new “in-between” option where you can specify watching more than one Kubernetes Namespace as a comma-separated list.  This will allow teams spanning multiple Kubernetes Namespaces to manage individual ingress controllers tied to their relevant Namespaces instead of having a single controller across all Namespaces. By adding this capability organizations will be able to more easily control access across Kubernetes Namespaces and simplify the management of multiple Kubernetes ingress controllers. 

Same Kong Ingress Controller Interface, More Opportunities

As mentioned previously most of the changes in KIC 2.0 should feel natural for users. KIC 2.0 ships with the same APIs as KIC 1.3 and does not materially change the existing interface other than to implement them on top of Kubebuilder. Additionally, previous iterations of KIC (1. x) had a built-in monolithic reconciliation loop that was not compatible with our long-term vision for KIC. By solving this in 2.0, we’re better positioned to execute priority initiatives like bringing Kubernetes Gateway API to users and treating service mesh as a first-class citizen within KIC. Despite this, there should not be any major disruptions in upgrading from 1.3.x to 2.0.x except for highly custom deployments.

For a full list of all breaking changes, please check out the KIC changelog.

The Path Forward for Kong Ingress Controller

One of our biggest reasons to move to 2.0 is to accelerate development, and we are committed to continuing to build the features you need. There are many known features and improvements that we’ll be working on, and we’d love to get any additional contributions or ideas you have. We’re excited to grow with you all and the Kubernetes community – it’s going to be an exciting journey!

Be sure to try KIC 2.0 today and let us know what you think!