It’s here! The Kong Gateway Operator release we teased at API Summit is now available for you all to use. KGO 1.4 allows you to configure Kong Konnect using CRDs, attach your DataPlane resources to Konnect with minimal configuration, and even manage the deployment of custom plugins using Kubernetes CRDs. Keep reading to find out more.

Configure Konnect with Kubernetes CRDs

We announced the ability to configure Konnect with Kubernetes CRDs at API Summit, and the Kong Gateway Operator 1.4 release enables you to try it yourself. There is extensive documentation that covers all available resources. Look how easy it is to create a new control plane in Konnect using CRDs:

echo '
kind: KonnectAPIAuthConfiguration
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: konnect-api-auth
  namespace: default
spec:
  type: token
  token: kpat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  serverURL: us.api.konghq.com
---
kind: KonnectGatewayControlPlane
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: gateway-control-plane
  namespace: default
spec:
  name: gateway-control-plane # Name used to identify the Gateway Control Plane in Konnect
  konnect:
    authRef:
      name: konnect-api-auth # Reference to the KonnectAPIAuthConfiguration object
' | kubectl apply -f -

You can get started today by following the Konnect Kubernetes CRDs documentation. Make sure you set the GATEWAY_OPERATOR_ENABLE_CONTROLLER_KONNECT environment variable with --set env.ENABLE_CONTROLLER_KONNECT=true to enable the feature, as this is a new feature that you need to opt in to.

Konnect CRDs currently supports all Kong Gateway entities, such as Service, Route, Consumers and Plugins. As we continue development on Konnect CRDs, we’ll be adding support for managing other products such as Dev Portal, Service Catalog and even team and user management for the Konnect platform itself.

Simplified Konnect DataPlane deployments

You’ve always been able to attach your Kong Gateway Operator–managed data planes to Konnect, but honestly, it was painful. You needed to know the exact combination of environment variables to set, and which values to use. If you want to see what it looked like previously, you can see it in the KGO 1.3 documentation.

I’m pleased to share that all of this pain has gone away in KGO 1.4 thanks to the KonnectExtension resource. KonnectExtension allows you to define your Konnect control plane details once, and attach them to any number of data planes.

The KGO 1.4 documentation shows how simple it is, but I’ll share the new resource here too to save you a click. All you need to provide is your Konnect control plane ID and region, then make sure the TLS secret exists:

echo '
 kind: KonnectExtension
 apiVersion: gateway-operator.konghq.com/v1alpha1
 metadata:
   name: example-konnect-config
   namespace: kong
 spec:
   controlPlaneRef:
     type: konnectID
     konnectID: <CP_ID>
   controlPlaneRegion: <REGION>
   serverHostname: konghq.com
   konnectControlPlaneAPIAuthConfiguration:
     clusterCertificateSecretRef:
       name: konnect-client-tls
 ' | kubectl apply -f -

Now you can use this KonnectExtension when creating a DataPlane resource to automatically generate the correct environment variables:

apiVersion: gateway-operator.konghq.com/v1beta1
 kind: DataPlane
 metadata:
   name: dataplane-example
   namespace: kong
 spec:
   extensions:
   - kind: KonnectExtension
     name: example-konnect-config
     group: gateway-operator.konghq.com

This is a brand new feature just like Konnect CRDs, so you’ll need to opt in by enabling the ENABLE_CONTROLLER_KONNECT feature gate.

Manage custom plugins with ease

Kong Gateway Operator 1.4 has been heavily Konnect focused so far, but we couldn’t ship without a feature for our on-prem users too. KGO 1.4 adds support for deploying custom plugins for Kong Gateway from an OCI registry.

Using the new KongPluginInstallation CRD, you can point the operator at any OCI compliant registry and it will download the custom plugin from the registry, mount the custom plugin as a volume and roll out new Gateway pods. Any time your plugin is updated, update the referenced version in the KongPluginInstallation resource and the operator will download the new code and roll out new pods with the updated plugin.

If you want to see the KongPluginInstallation CRD in action, you can watch the latest user call.

Define a PodDisruptionBudget

Last, but by no means least, KGO 1.4 allows you to specify a PodDisruptionBudget to ensure that a minimum number of pods are always available. You can configure the spec.resources.podDisruptionBudget field in your DataPlane spec with a valid PodDisruptionBudget object and the operator will respect the values provided.

Try Kong Gateway Operator 1.4

You can try out the new Konnect-related functionality by logging in to your Konnect account and generating a personal access token. You can use this token to try both Konnect CRDs and the new KonnectExtension capabilities. If you don’t have a Konnect account, it takes under 60 seconds to sign up with social login.

We’d love for you to try it out and provide feedback by posting on our GitHub discussion forum. We’re looking for feedback on bugs of course, but we also want to hear about your use cases and how the current CRD design feels to use.

If you have any questions or feedback for us, our product and engineering team are monitoring GitHub discussions for the operator daily.

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