Since our last Kong Ingress Controller release, we've been working hard, and today we’re pleased to announce the immediate availability of Kong Ingress Controller 2.11.

KIC 2.11's standout feature is "last known good configuration", which allows you to scale your data planes out even if you have a broken configuration on your Kubernetes API server. That's a strange sentence to write, but it happens more than you'd think.

Imagine this: Engineering team X manages the product catalog service and has applied a rate limiting plugin to the service. Team Y wants to give a partner a higher rate limit to the catalog service, so it configures a rate limit plugin against the service and a consumer.

This would work fine, except for the fact that Team Y forgot to associate the plugin with a consumer. Now there are two rate limiting plugins targeting the same service, and you have a broken configuration on your Kubernetes API server until Team Y fixes its configuration to target a service and a consumer.

In previous versions of KIC, any new pods wouldn’t be able to proxy traffic as KIC would send them invalid configurations. In KIC 2.11, "last known good configuration" ensures that new pods get a valid configuration when they start up.

In addition to "last known good configuration", we've improved KIC's monitoring capabilities, added support for even more Kong Gateway features, and we're now compliant with version 0.7.1 of the Kubernetes Gateway API.

To learn more about each of these features, read on! To see the complete list of changes, please visit the Kong Ingress Controller CHANGELOG.

Operator robustness

Kong Ingress Controller 2.11 makes Kong Gateway on Kubernetes even more robust. We heard from users that scaling out or bouncing pods was a real pain point for them if the K8S API server wasn’t available, or it contained an invalid configuration.

Last known good configuration is a new feature that caches the most recent configuration accepted by a proxy container in the ingress controller itself. If a pod restarts and the state from the Kubernetes API server can’t be applied, KIC will send the last configuration that it could apply to the new container.

We could have stopped there . . . but we didn't!

Not only will KIC cache the last known good config, but if your ingress controller pod restarts for any reason, KIC will fetch the current config from a running proxy container and cache that on startup. This allows you to restart your controller and proxy pods independently without sacrificing durability.

Keeping Kong Gateway running is only half the battle. We also need to alert you that something is wrong. KIC 2.11 adds new Prometheus metrics that you can monitor to understand the status of your environment.

In KIC 2.11 we now expose the:

• Number of successful configuration pushes (ingress_controller_configuration_push_count)
• Time of the last successful push (ingress_controller_configuration_push_last_successful)
• The number of resource translation errors (ingress_controller_translation_broken_resource_count) and more.

Your SRE team can feed these metrics into their alerting tool to be notified when any of those metrics exceeds a threshold.

Finally, we've added support for Kong Gateway's new /status/ready endpoint. Prior to KIC 2.11, there is a small chance that new pods come online and start handling traffic without any routes loaded. The /status/ready endpoint allows us to understand if the proxy container has received a configuration and is ready to handle traffic. To take advantage of this new endpoint, upgrade to KIC 2.11 and Kong Gateway 3.3+.

Kong Gateway parity

Kong Gateway is adding new features in every release. We have to do some work on the Kong Ingress Controller to allow you to configure them using CRDs for every Kong Gateway release.

KIC 2.11 adds two new Kong Gateway features:

1. The KongPlugin resource now accepts an instance_name field when configuring plugins. This can be used to identify specific instances of a plugin when reviewing configuration
2. A brand new custom resource definition (CRD) — KongConsumerGroup — which allows you to configure consumer groups in Kong Gateway. Consumer groups allow you to share plugin configuration across multiple consumers, reducing the maintenance burden of keeping configurations in sync.

Consumer groups are compatible with Kong Gateway 3.4+ so you'll need to wait a week or two for that release, but you can get started with KongPlugin instance_name configuration today!

Kubernetes Gateway API

Finally, we're now compliant with version 0.7.1 of the Kubernetes Gateway API. Kong is heavily involved in the development of the Gateway API specification, and we make sure that we're compliant with the latest draft in every release. This allows us to test drive the standard and provide useful feedback to the Kubernetes networking SIG.

We're working on revamping all of our examples to use Gateway API rather than Ingress. Keep an eye on https://docs.konghq.com/kubernetes-ingress-controller/latest/ to be the first to know when we make the change.

Try Kong Ingress Controller 2.11

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

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