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:

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](https://docs.konghq.com/kubernetes-ingress-controller/latest/guides/high-availability/fallback-config/)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:

apiVersion: configuration.konghq.com/v1alpha1
kind: KongCustomEntity
metadata:
  namespace: default
  name: degraphql-route-example
spec:
  type: degraphql_routes
  fields:
    uri: "/contacts"
    query: "query{ contacts { name } }"
  controllerName: kong
  parentRef:
    group: "configuration.konghq.com"
    kind: "KongPlugin"
    name: "degraphql-example"

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](https://docs.konghq.com/kubernetes-ingress-controller/latest/guides/services/custom-entity/)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 expressions routes to Konnect when enabled in KIC
• - KongPlugin instances sourced from Kubernetes secrets no longer fail Konnect validation
• - KongConsumer now 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 error messages. Subsequent messages about the sync process’ backoff implementation have been dropped to warning level.

## Try Kong Ingress Controller 3.2

For a full list of features, fixes, and updates please see the [CHANGELOG](https://github.com/Kong/kubernetes-ingress-controller/blob/main/CHANGELOG.md#320)CHANGELOG.

As always, the [quickest way to get started](https://konghq.com/products/kong-konnect/register)quickest way to get started with KIC 3.2 is with Kong Konnect thanks to our [KIC in Kong Konnect](https://konghq.com/blog/product-releases/kic-in-kong-konnect)KIC in Kong Konnect functionality.