What's New in Kong Ingress Controller 3.2?
Kong Ingress Controller (KIC) 3.2 is here, and it’s an incredible release. It contains features related to graph theory, features that mean you’ll never need a database again, and a whole host of quality-of-life fixes.
Isolate configuration issues with Fallback Configuration
If you’ve been using KIC for a long time, you might remember that it was technically possible to get into a state on the Kubernetes API server where new configurations could not be loaded by Kong Gateway, leading to downtime when pods cycled.
We fixed this in KIC 2.11 with LastKnownGoodConfiguration. As a reminder, here’s what we had to say about it:
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.
LastKnownGoodConfiguration was a great first step toward preventing downtime, but it still had one major flaw. Your Gateway configuration could not be updated until the broken configuration was resolved. That means that one small, broken config from a single team could block a whole company.
We’ve shipped a capability called FallbackConfiguration in KIC 3.2 to solve exactly this issue. It builds on top of LastKnownGoodConfiguration to automatically identify any invalid subgraph of your configuration and replace it with the last known good configuration for that section specifically.
This means that if a team breaks their configuration, only the entities that they configured are affected. Routes and plugins managed by other teams can be updated independently, preventing a single team from blocking a whole department.
For more information about fallback configuration and a step-by-step guide that walks through the rate-limiting example above, see the fallback configuration documentation.
Configure plugin entities using KongCustomEntity
The KIC documentation contains a note that says, "Database-backed deployments should only be used in a small set of circumstances." This is a small list of reasons, and with KIC 3.2 we’ve removed one of the biggest reasons to use a database with Kong on Kubernetes.
Kong Gateway plugins have the ability to define custom entities using a daos.lua file. These entities can be managed using generated Admin API endpoints and consumed by the plugins themselves. The degraphql plugin is a great example — it defines a degraphql_routes entity to help map routes to GraphQL queries.
These custom entities could not be managed using KIC before KIC 3.2. If you needed to use a plugin with custom entities, you could use KIC to manage all your services, routes, etc. but also needed to use the Kong Admin API to configure these custom entities in a database.
KongCustomEntity allows you to define arbitrary custom entities as a CRD and they’re sent to the Kong configuration endpoint with the rest of your configuration. Anything under the fields key is translated into the custom entity:
You can see that the CRD contains the type of custom entity (degraphql_route), a set of parameters under fields and a parentRef which tells KIC which plugin the custom entity should be attached to.
For more information, see the custom entities documentation.
More Gateway API Goodness
At Kong, we're core contributors to the Kubernetes Gateway API, which means when GRPCRoute went GA we knew that we needed to support it and pass conformance tests in our next release.
Well, that next release is here, and we support the v1 API for GRPCRoute. This means that you no longer need the experimental Gateway API CRDs installed to work with GRPCRoute and Kong. GRPCRoute support has also been moved out of the GatewayAlpha feature gate and is generally available for all consumers by default.
As well as GRPCRoute GA support, we’ve added support for the URLRewrite filter. This allows you to manipulate the request URL in a vendor-independent way.
KIC in Konnect
It wouldn’t be a KIC release without some KIC in Kong Konnect-related changes. This release contains some quality-of-life changes for those of you using KIC in Konnect:
- Sync
expressionsroutes to Konnect when enabled in KIC KongPlugininstances sourced from Kubernetes secrets no longer fail Konnect validationKongConsumernow supports multiple credentials without triggering a uniqueness validation error in Konnect due to secret values being sanitized.- Only log messages related to Konnect sync failure are
errormessages. Subsequent messages about the sync process’ backoff implementation have been dropped towarninglevel.
Try Kong Ingress Controller 3.2
For a full list of features, fixes, and updates please see the CHANGELOG.
As always, the quickest way to get started with KIC 3.2 is with Kong Konnect thanks to our KIC in Kong Konnect functionality.