Adopt existing entities from Konnect

Incompatible with
on-prem
Related Documentation
Minimum Version
Kong Operator - 2.1
TL;DR

Create a resource for each entity you want to manage and configure the spec.adopt parameters:

  • Set spec.adopt.konnect.id to the entity’s Konnect ID.
  • Set spec.adopt.mode to:
    • override if you want to change the entity’s configuration.
    • match if you want to keep the existing configuration.

Prerequisites

If you don’t have a Konnect account, you can get started quickly with our onboarding wizard.

  1. The following Konnect items are required to complete this tutorial:
    • Personal access token (PAT): Create a new personal access token by opening the Konnect PAT page and selecting Generate Token.
  2. Set the personal access token as an environment variable:

    export KONNECT_TOKEN='YOUR KONNECT TOKEN'
    
  1. Add the Kong Helm charts:

    helm repo add kong https://charts.konghq.com
    helm repo update
    
  2. Install Kong Operator using Helm:

    helm upgrade --install kong-operator kong/kong-operator -n kong-system \
      --create-namespace \
      --set image.tag=2.1.0 \
      --set env.ENABLE_CONTROLLER_KONNECT=true
    
    helm upgrade --install kong-operator kong/kong-operator -n kong-system \
      --create-namespace \
      --set image.tag=2.1.0
    

    If you want cert-manager to issue and rotate the admission and conversion webhook certificates, install cert-manager to your cluster and enable cert-manager integration by passing the following argument while installing, in the next step:

    --set global.webhooks.options.certManager.enabled=true
    

    If you do not enable this, the chart will generate and inject self-signed certificates automatically. We recommend enabling cert-manager to manage the lifecycle of these certificates.

    Kong Operator needs a certificate authority to sign the certificate for mTLS communication between the control plane and the data plane. This is handled automatically by the Helm chart. If you need to provide a custom CA certificate, refer to the certificateAuthority section in the values.yaml of the Helm chart to learn how to create and reference your own CA certificate.

This tutorial doesn’t require a license, but you can add one using KongLicense. This assumes that your license is available in ./license.json.

echo "
apiVersion: configuration.konghq.com/v1alpha1
kind: KongLicense
metadata:
 name: kong-license
rawLicenseString: '$(cat ./license.json)'
" | kubectl apply -f -
kubectl create namespace kong --dry-run=client -o yaml | kubectl apply -f -
echo '
kind: KonnectAPIAuthConfiguration
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: konnect-api-auth
  namespace: kong
spec:
  type: token
  token: "'$KONNECT_TOKEN'"
  serverURL: us.api.konghq.com
' | kubectl apply -f -

This example requires an existing Konnect control plane and entities that we’ll then connect to our Kubernetes cluster. Let’s create these entities with the Konnect API.

Run the following command to create a control plane and save its ID to your environment:

CONTROL_PLANE_ID=$(curl -X POST "https://us.api.konghq.com/v2/control-planes" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN" \
     --json '{
       "name": "gateway-control-plane"
     }' | jq -r ".id"
)

Create a Gateway Service:

SERVICE_ID=$(curl -X POST "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/services" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN" \
     --json '{
       "name": "demo-service",
       "protocol": "http",
       "host": "httpbin.konghq.com",
       "path": "/anything"
     }' | jq -r ".id"
)

Create a Route:

ROUTE_ID=$(curl -X POST "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/routes" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN" \
     --json '{
       "name": "demo-route",
       "paths": [
         "/anything"
       ],
       "service": {
         "id": "'$SERVICE_ID'"
       }
     }' | jq -r ".id"
)

Create a Rate Limiting plugin:

PLUGIN_ID=$(curl -X POST "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/plugins" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN" \
     --json '{
       "name": "rate-limiting",
       "config": {
         "second": 5,
         "hour": 1000,
         "policy": "local"
       }
     }' | jq -r ".id"
)

To manage adopt entities, you first need to create a KonnectGatewayControlPlane resource that references our Konnect control plane:

echo '
kind: KonnectGatewayControlPlane
apiVersion: konnect.konghq.com/v1alpha2
metadata:
  name: gateway-control-plane
  namespace: kong
spec:
  source: Mirror
  mirror:
    konnect:
      id: "'$CONTROL_PLANE_ID'"
  konnect:
    authRef:
      name: konnect-api-auth
' | kubectl apply -f -

You can verify the KonnectGatewayControlPlane was reconciled successfully by checking its Programmed condition.

kubectl get -n kong konnectgatewaycontrolplane gateway-control-plane \
  -o=jsonpath='{.status.conditions[?(@.type=="Programmed")]}' | jq

The output should look similar to this:

{
  "observedGeneration": 1,
  "reason": "Programmed",
  "status": "True",
  "type": "Programmed"
}

Adopt a Gateway Service

To adopt entities directly referencing a control plane, such as Services, make sure you’ve created the KonnectGatewayControlPlane resource to manage the Konnect control plane.

In this example, we’ll adopt the Service we created in the prerequisites in match mode. This mode is useful if you want to adopt an entity without making any changes to it yet.

Specify the Service’s parameters to match the ones we defined when creating it, and add the Service’s Konnect ID and the reference to the control plane:

echo '
kind: KongService
apiVersion: configuration.konghq.com/v1alpha1
metadata:
  name: adopt-service
  namespace: kong
spec:
  controlPlaneRef:
    type: konnectNamespacedRef
    konnectNamespacedRef:
      name: gateway-control-plane
  adopt:
    from: konnect
    mode: match
    konnect:
      id: "'$SERVICE_ID'"
  name: demo-service
  protocol: http
  host: httpbin.konghq.com
  path: "/anything"
' | kubectl apply -f -

You can validate that the Route was successfully adopted by fetching its configuration using the Konnect API:

curl -X GET "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/services/$SERVICE_ID" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN"

You should see k8s-* tags, which indicate that the Service is managed with Kubernetes.

Adopt a Route

To adopt entities that are attached to another entity, such as a Route attached to a Service, make sure you’ve created the KonnectGatewayControlPlane resource and the parent resource.

Let’s adopt the Route we created in the prerequisites, and this time we’ll use override mode to change its configuration.

Specify the Route’s new parameters, and add the Route’s Konnect ID and the reference to the Service:

echo '
kind: KongRoute
apiVersion: configuration.konghq.com/v1alpha1
metadata:
  name: adopt-route
  namespace: kong
spec:
  serviceRef:
    type: namespacedRef
    namespacedRef:
      name: adopt-service
  adopt:
    from: konnect
    mode: override
    konnect:
      id: "'$ROUTE_ID'"
  name: demo-route
  paths:
  - "/new"
' | kubectl apply -f -

You can validate that the Route was successfully adopted by fetching its configuration using the Konnect API:

curl -X GET "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/routes/$ROUTE_ID" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN"

You should see the updated configuration and the k8s-* tags.

Adopt a plugin

To adopt a plugin, we need to create two different resources:

  • A KongPlugin resource to specify the configuration of the plugin.
  • A KongPluginBinding resource to adopt the plugin by ID and specify the relationship between the plugin and other entities.

In this example, we’ll modify the configuration of the Rate Limiting plugin we created in the prerequisites.

First, create the Rate Limiting KongPlugin resource:

echo '
kind: KongPlugin
apiVersion: configuration.konghq.com/v1
metadata:
  name: rate-limit
  namespace: kong
config:
  second: 3
  hour: 300
  policy: local
plugin: rate-limiting
' | kubectl apply -f -

Create the KongPluginBinding resource to link the KongPlugin to the plugin we created in Konnect and associate it to our Service:

echo '
kind: KongPluginBinding
apiVersion: configuration.konghq.com/v1alpha1
metadata:
  name: plugin-binding-kongservice
  namespace: kong
spec:
  controlPlaneRef:
    type: konnectNamespacedRef
    konnectNamespacedRef:
      name: gateway-control-plane
  pluginRef:
    name: rate-limit
  adopt:
    from: konnect
    mode: override
    konnect:
      id: "'$PLUGIN_ID'"
  targets:
    serviceRef:
      name: adopt-service
      kind: KongService
      group: configuration.konghq.com
' | kubectl apply -f -

You can validate that the plugin was successfully adopted by fetching its configuration using the Konnect API:

curl -X GET "https://us.api.konghq.com/v2/control-planes/$CONTROL_PLANE_ID/core-entities/plugins/$PLUGIN_ID" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN"

You should see the updated configuration and the k8s-* tags.

FAQs

Immutable entities only support adoption in match mode and can’t be modified after adoption. This is the case for:

  • Cloud Gateway resources: Networks, data plane group configurations, and transit gateways.
  • Data plane client certificates.

You must adopt these entities in match mode and configure the resource to match the existing entity in Konnect.

Here’s an example of network adoption:

echo '
kind: KonnectCloudGatewayNetwork
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: adopt-konnect-network
  namespace: default
spec:
  adopt:
    from: konnect
    mode: match
    konnect:
      id: "'$NETWORK_ID'"
  name: network1
  cloud_gateway_provider_account_id: "'$CLOUD_GATEWAY_PROVIDER_ID'"
  availability_zones:
  - use1-az1
  - use1-az2
  - use1-az4
  - use1-az5
  - use1-az6
  cidr_block: 10.0.0.1/24
  region: us-east-1
  konnect:
    authRef:
      name: konnect-api-auth
' | kubectl apply -f -
Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!