What’s New in Kong Ingress Controller 2.10?

We’ve just shipped Kong Ingress Controller (KIC) 2.10! This release makes KIC easier to use. In this blog we’ll cover:

• Expression Router: KIC 2.10 provides an early access preview to a new Rust-based router that has been available since Kong Gateway 3.0. The router enhances efficiency by offering increased performance and the capability to configure complex routes.
• Kubernetes Events: Enhanced event handling provides greater operational insight by identifying unexpected errors and generating events when a config is successfully applied in addition to errors.
• Gateway Discovery DNS: Provides robust security for your admin API by enabling DNS names for gateway discovery. This allows users to verify the CommonName in their TLS certificates.
• Simplified Deployment: Deploying KIC and Kong Gateway with gateway discovery involves setting the correct values.yaml fields and managing two separate deployments. Until now, that is. We’ve added a new combined Helm chart to help deploy KIC with Gateway Discovery as a single “batteries included” deployment that just works.

You can read the CHANGELOG for full details, but for now, let’s focus on the highlights.

Expression Router

KIC 2.10 adds limited support for Kong Gateway 3.0’s new expression-based router. If you’re not familiar with the expressions router, read this from the Kong Gateway 3.0 announcement:

Not only is the new router more expressive, it’s also more performant! Large routing configurations can now be reloaded incrementally instead of rebuilding the whole router each time there is a configuration change. This has reduced P99 time from 1.5s to 0.1s in our testing.

More functionality and higher performance. The expressions router delivers some of the capabilities we need for full Gateway API conformance, so this is a huge step towards being 100% interoperable with the whole Kubernetes ingress controller ecosystem.

The expression router is currently an alpha release with support for Ingress and HTTPRoute only. It’s turned off by default and has shipped behind a feature gate. To try it out, enable the ExpressionRoutes gate on KIC and set router_flavor to expressions in your Kong Gateway deployments.

Kubernetes Events

In KIC 2.9 we introduced the `KongConfigurationApplyFailed` and `KongConfigurationTranslationFailed` events to enable users to debug their configuration faster than ever before. If you’re not familiar with these events, here’s an example of an event raised when a certificate expires:

NAMESPACE   LAST SEEN   TYPE      REASON                               OBJECT                         MESSAGE
default     12s         Warning   KongConfigurationTranslationFailed   kongplugin/michael-test-mtls   invalid CA certificate: expired
default     15s         Warning   KongConfigurationTranslationFailed   secret/my-ca-cert              invalid CA certificate: expired

KIC 2.10 adds two new features to the events system. The first is an enhancement for KongConfigurationApplyFailed where an event will be emitted even if Kong Gateway does not return an error message (if you manage to trigger a HTTP 500, for example). This allows you to be notified that something went wrong, even if we can’t tell you exactly what it is.

The second is a feature driven by feedback we’ve received from users like you! Users told us that KongConfigurationApplyFailed is great, but they wanted to invert their logic and assume that a deploy has failed and halt any future deployments until they receive an acknowledgment. This is how the KongConfigurationSucceeded event was born.

This event enables teams using a merge queue to ensure that each manifest applies cleanly before moving on to the next change. Users can pause the pipeline automatically after each deployment and re-enable it when they receive a KongConfigurationSucceeded event.

You can learn more about the available Kubernetes events in the KIC documentation.

Gateway Discovery DNS

Kong Ingress Controller 2.9 introduced Gateway Discovery, which allows you to run a separate Ingress Controller deployment to manage all of your Kong Gateway instances. The communication between the controller and the gateway admin API can be secured with TLS certificates to ensure that only authorized services can make changes to the configuration.

Our Gateway Discovery implementation in KIC 2.9 generated IP addresses rather than DNS names, which made it impossible to verify that the CommonName in the certificate was valid. KIC 2.10 adds two new address methods using the --gateway-discovery-dns-strategy flag. You can set the discovery strategy flag to one of the following options:

• `service` (pod-ip-address.service-name.my-namespace.svc.cluster-domain.example),
• `pod` (pod-ip-address.my-namespace.pod.cluster-domain.example)
• `ip` (which is the old behavior, and is the default).

Simplified Deployment

Finally, we’ve published a new Helm chart that simplifies your deployment. Instead of having two separate deployments, one for the Ingress Controller and one for Kong Gateway, you can use a single deployment and values.yaml file.

To try this feature, run helm install kong kong/ingress. That’s all it takes. This will deploy Kong Ingress Controller and Kong Gateway with gateway discovery. The new chart uses the existing kong/kong chart under the hood, so all of the configuration options you have used in the past are still valid.

In fact, we also fixed an issue in the kong/kong chart which prevented you from using external certificate issuers with CertManager when running Kong in Hybrid mode and your own PKI infrastructure. This fix (and more) are all available in the kong/ingress chart.

To learn more about the new chart, check out the README in the kong/charts GitHub repo.

Try Kong Ingress Controller 2.10

For a full list of features, fixes, and updates please see the CHANGELOG.

As always, the quickest way to get started with KIC 2.10 is with Kong Konnect thanks to our new KIC in Konnect functionality.