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:

• Kubernetes Gateway API Conformance: We’re 99% conformant with Gateway API 0.6.1. (There’s just one pesky edge case that we’re working on. You can follow along here.)
• gRPC Routes: Expose gRPC endpoints using the Gateway API’s GRPCRoute type.
• Enhanced Visibility Using Kubernetes Events: Provide visibility into configuration conflicts. Kubernetes Events will now provide information that will help you better understand the root cause of Kubernetes configuration from propagation into Kong in DB-less mode.
• Independent Ingress / Data Plane Scaling: The ability to have a single Ingress Controller in front of multiple DB-less Kong Gateway nodes.
• Gateway Discovery: Last but not least, you can now have KIC auto-discover your data planes based on the name of your Kubernetes service.

Here are the details about each of these features.

Kubernetes Gateway API

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.

gRPC Routes

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.

Kubernetes Events

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.

Independent Ingress / Data Plane Scaling

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.

Gateway Discovery

There are two ways to tell the Ingress Controller where to direct incoming requests:

1. Use the --kong-admin-url flag. This flag has existed for a long time, but as of KIC 2.9 you can now provide multiple, comma-separated URLs.
2. Use our brand new Gateway Discovery feature, which uses the Kubernetes API to keep track of running Gateway instances.

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.

Try Kong Ingress Controller 2.9

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.