We know that a lot of you are all in on Kubernetes as your source of declarative configuration. You have CI/CD pipelines set up already to review and approve your Kubernetes manifests.

Not only that, but you’re using everything the Kubernetes ecosystem has to offer when it comes to managing resources. You’re inspecting the Status field of resources to understand the reconciliation status. You’re using Kubernetes RBAC to add some governance to your configuration. You’re using ReferenceGrant to allow teams to conditionally allow access to their systems. 

Kubernetes is a strategic tool for you, which makes it a strategic tool for Kong. That’s why we’ve invested in making sure that you can configure Konnect using CRDs.

The initial release is focused on managing Konnect Gateway control planes and all associated entities, but we’ll continue to ship new entities in every release of the operator until you can manage every part (yes, that means API Products, Portal, Teams, Roles, and a whole lot more) of Konnect with CRDs.

Announcing konnect.konghq.com/v1alpha1

We’re working hard on Kong Gateway Operator 1.4 (which will be released in November), which includes a new Konnect controller and a set of CRDs in the konnect.konghq.com/v1alpha1 apiVersion. As indicated by the version, this is an early access preview that we’re continuously adding new capabilities to.

Today, you can create a Kong Gateway control plane in Konnect and manage all of the Gateway entities within that control plane. Each entity is a separate CRD, including KongService and KongRoute. We intend to support Ingress and HTTPRoute in the future, but for now, we’re focused on providing the fine-grained building blocks so that people can meet all of their use cases as quickly as possible.

How does it work?

You can get started with Konnect CRDs in just four quick steps:

1. Install Kong Gateway Operator
2. Configure your authentication credentials
3. Create a KonnectGatewayControlPlane
4. Create a KongService

Install Kong Gateway Operator

You’ll need to ensure that you’re running version 1.4 of the Kong Gateway Operator before trying out the new Konnect CRDs functionality. That means that you won’t be able to test this out yourself until early October when KGO 1.4 is released.

However, if you’re reading this in November, the good news is that you can get started today!

Configure authentication credentials

The operator needs to know which Konnect region you’re using, and what API token to use to authenticate. The token can either be a personal access token or a system access token with the correct permissions.

To configure credentials, create a KonnectAPIAuthConfiguration entity:

Create a KonnectGatewayControlPlane

The first Konnect entity we’re going to create is a new Gateway control plane. It defaults to a hybrid mode control plane, but you can set the cluster_type under the spec field to create a KIC in Konnect or Control Plane Group control plane.

The spec.konnect.authRef is what tells the operator which API credentials to use when syncing this configuration.

Create a KongService

Finally, you can create a KongService that lives inside the control plane that was just created.

You might spot that there's a controlPlaneRef in the manifest. This references the control plane that was created in the last step by name, allowing the operator to figure out which control plane this KongService should be published to.

At this point, you should be able to log in to Konnect and see your new control plane and service created. You can try deleting the service and waiting a few seconds. The operator will notice that the service no longer exists in Konnect and recreate it automatically.

Try it out

Once KGO 1.4 is available, 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 (even before the release), our product and engineering team are monitoring GitHub discussions for the operator daily.