See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
4 MIN READ
We’re happy to announce the release of Kong Ingress Controller (KIC) 2.9, in which we’ve taken significant steps towards solution extensibility, deployment flexibility, and lowering the cost of ownership.
KIC now offers a number of features that we think you’ll be excited about:
Here are the details about each of these features.
The Gateway API is a collection of resources that model service networking in Kubernetes. It allows developers to define routing rules through interfaces that are implemented by multiple vendors with broad industry support.
Kong has been a driving force behind the Gateway API since its inception. In fact, our very own Shane Utt is the chair of the Kubernetes Network SIG. We believe that developers should be able to use the best tool for the job and not be tied to a technology just because the switching cost is too high.
The KIC 2.9 release brings Kong Ingress Controller in line with the most recent Gateway API release. We’ve implemented everything in the specification with the exception of one conflict resolution rule:
If everything else is equivalent (including creation timestamp), precedences should be given to the resource appearing first in alphabetical order (namespace/name). For example, foo/bar would be given precedence over foo/baz.
We need to make some changes to Kong Gateway’s routing engine to support this — but watch this space.
Most consumers of the Gateway API will be familiar with using the HTTPRoute resource to direct incoming traffic to a specific service. However, many companies are using gRPC today for communication between their applications. The Gateway SIG recognized this and added support for GRPCRoute to the experimental channel in version 0.6.0 of the Gateway API.
gRPC adds an abstraction on top of HTTP 2.0 to make developers’ lives easier. It can handle bi-directional streaming and is great for low-latency applications. gRPC servers and clients can be generated automatically to ensure that the messages being passed back and forth conform to a well-defined schema.
Today’s release adds support for this experimental feature, which means you can now proxy gRPC traffic to Kong Gateway using both Ingress and Gateway API resources.
You can learn more about GRPCRoute in the Kong Ingress Controller docs. Or check out the demo video.
We’re all familiar with browsing through logs to diagnose why things aren’t working. With this release we’ve added the KongConfigurationApplyFailed which means you can see all of your problem resources with a single kubectl query:
kubectl get events -A --field-selector='reason=KongConfigurationApplyFailed'
Check out the demo video for more. Or if you’d like to try it yourself, you can find an example broken configuration in the documentation.
Historically, both the Kong Ingress Controller and Kong Gateway have been deployed to the same pod. This means that each Kong Gateway has its own Ingress Controller that receives incoming requests and passes them on to internal services.
Today’s release adds the capability to run the Ingress Controller and the Kong Gateway data planes separately in different pods.
This feature enables KIC to scale cost-effectively as it removes the overhead of running the KIC sidecar with every single Gateway instance. Apart from memory savings, users should also see a significant decrease in CPU usage.
There are two ways to tell the Ingress Controller where to direct incoming requests:
Option #1 works, but if you’re dynamically scaling Gateway instances up or down, it will get out of sync very quickly. Instead, we’d recommend using the new --kong-admin-svc flag. This flag accepts the namespaced name of a Gateway Admin API service, e.g. “kong/kong-admin” and will dynamically respond to any changes in your deployment.
Gateway Discovery allows KIC to dynamically detect spawning Gateways while it’s running. This allows users to scale Gateway deployment based on their requirements and lets KIC do the rest (instance discovery) for them.
Finally, you may be wondering about stability if you’re only running a single ingress. Don’t worry! You can still scale your Ingress deployment horizontally, and our leader election mechanism will ensure that only one instance propagates changes to your data planes while the others wait to take over in case the leader goes away.
To get started, check out our Gateway Discovery guide.
For a full list of features, fixes, and updates please see the CHANGELOG.
If you want to try out KIC 2.9, it’s available for free or you can install the Ingress Controller into an existing Kubernetes cluster yourself.
Learn how to make your API strategy a competitive advantage.