Just under one year ago, we launched version 1.0 of our Kong Ingress Controller (KIC). That was a huge milestone for us here at Kong, and we know it was for you - Kong Nation - as well. Since then, with the help of our community, we've merged over 300 new features and bug fixes and have started to enter a new era of KIC: version 2.0.
Prior to releasing KIC 2.0, we want to make sure to incorporate community and customer feedback, so we are announcing the KIC 2.0 Beta. We'd love for you to try out the beta and to give us feedback!
Exciting New Features
Before we get any further into some of the core of KIC 2.0, let's talk about some of the exciting new features that KIC 2.0 brings!
UDP Support
The big feature that kicked off the development of KIC 2.0 initially was UDPIngress support. KIC has supported TCPIngress since 0.8.0, but Kong Gateway 2.2 introduced support for UDP proxying as well, and we needed to figure out a way to handle that in KIC. If you're interested in learning why UDP support is important, have a read over the Kong Gateway 2.2 release blog. Long story short, there were none.
Importantly, the reason why there were no good options touched upon something we'd also been thinking about for about half a year: that the architecture of KIC was limited in what it could allow us to build out quickly. That is, since we first launched our ingress controller back in 2018, the broader Kubernetes ecosystem has added tons of new capabilities, and the existing code structure of KIC was fairly difficult to add those new features into. With the KIC 2.0 redesign, we should be able to add features much faster in the future, and the first big feature in KIC 2.0 is UDPIngress support.
Watch Multiple Namespaces
One of the more common requests we hear is that users want to watch a specific set of Kubernetes namespaces. However, in KIC 1.x that is not possible; you either have to watch all namespaces or one specific namespace. KIC 2.0 includes a new flag, –watch-namespace, which allows you to specify a comma-separated list of namespaces to watch for Kubernetes resources on.
Prometheus Metrics
One thing we've heard from our users is that improvements are needed to enable monitoring of the ingress controller 1.x for performance and failures - things like the time it takes to apply the configuration to KIC. We wanted to make that better.
KIC 2.0 introduces a native Prometheus integration for KIC metrics. With this integration, you can easily measure and act on how long it takes KIC to apply its configuration. This way, you can investigate and be alerted on any significant performance issues and do more investigations on high-load setups.
Breaking Changes
- We removed support for classless resources that have been opt-in and discouraged since KIC 0.10.
- Structured logging has been revamped, with an impact on some of the flags that control logging.
- The admission webhook now requires TLS 1.2 or higher.
- In DB-less mode, the controller only marks itself ready once it has successfully applied the configuration at least once. This ensures that proxies do not start handling traffic until they are configured.
- The disabled-by-default debug feature –dump-config now has a different (HTTP-based) interface on the management port and has some flag changes.
- We renamed RBAC roles and bindings to reflect their association with Kong.
- Flags that control the API versions in use by KIC when communicating with the Kubernetes API server have changed.
For an authoritative list of breaking changes, see the KIC changelog.
2.0: A New Beginning
The upstream Kubernetes project has made enormous progress in support for third-party controllers since the inception of KIC in 2018. Tooling such as Kubebuilder and controller-runtime can take a lot of Kubernetes API heavy-lifting off of maintainers’ shoulders, while providing performance benefits and superior experience to the users of controllers built upon them.
When we started KIC 2.0, we decided to adopt Kubebuilder as the emerging/cutting-edge controller technology that Kubernetes had to offer. In doing so, we were striving for operational robustness and well-known operational patterns that feel familiar to most Kubernetes DevOps. In general, our goals were to provide centralized mechanisms for monitoring, controller lifecycle management, better logging, Kubernetes API caching and resource reconciliation.
So what comes with this new beginning? KIC 2.0 specifically comes with the exact same user-facing APIs as KIC 1.3 (plus some additions listed above, like UDPIngress) and mostly unchanged pre-existing operational knobs (such as flags) but implemented on top of Kubebuilder. The upgrade KIC 2.0 is documented under "Guides > Upgrading from 1.3.x to 2.0.x" in the KIC 2.0 beta documentation. It is seamless for users of our Helm chart with the exception of a few minor changes in flags that may affect some highly customized deployments.
Yet another facet of KIC 2.0 is that the built-in monolithic reconciliation loop in KIC 1.x didn’t meet our needs for the ambitious plans we have going forward. This new architecture positions us very well for making KIC’s configuration updates incremental (thus greatly raising the scalability ceiling). It will allow us to bring the Kubernetes Gateway API to our users in the future for a more expressive ingress configuration language - and also an added ability to orchestrate gateways seamlessly as described by the Gateway resource. Finally, it will enable us to treat the service mesh as a first-class citizen within Kong Ingress Controller.
We are excited for the new opportunities that the KIC 2.0 technology leap unlocks!
For the installation and configuration steps, please refer to our KIC 2.0 beta documentation.