helm upgrade --install kong-operator kong/kong-operator -n kong-system \
--create-namespace \
--set image.tag=2.3 \
--set env.ENABLE_CONTROLLER_KONNECT=true
kubectl -n kong-system wait --for=condition=Available=true --timeout=300s deployment/kong-operator-kong-operator-controller-managerCreate an Upstream and Target
Uses:
Kong Operator
TL;DR
Define a KongUpstream and associate one or more KongTarget resources with it to distribute traffic across backend services.
Prerequisites
Kong Konnect
If you don’t have a Konnect account, you can get started quickly with our onboarding wizard.
- 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.
-
Set the personal access token as an environment variable:
export KONNECT_TOKEN='YOUR KONNECT TOKEN'
Kong Operator running
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=trueIf 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.
Create a KonnectAPIAuthConfiguration resource
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 -Create a KonnectGatewayControlPlane resource
echo '
kind: KonnectGatewayControlPlane
apiVersion: konnect.konghq.com/v1alpha2
metadata:
name: gateway-control-plane
namespace: kong
spec:
createControlPlaneRequest:
name: gateway-control-plane
konnect:
authRef:
name: konnect-api-auth
' | kubectl apply -f -Create a KongUpstream
Use the KongUpstream resource to define a load balancing group for backend services. Your KongUpstream must be associated with a KonnectGatewayControlPlane object that you’ve created in your cluster.
echo '
kind: KongUpstream
apiVersion: configuration.konghq.com/v1alpha1
metadata:
name: upstream
namespace: kong
spec:
name: upstream
controlPlaneRef:
type: konnectNamespacedRef
konnectNamespacedRef:
name: gateway-control-plane
' | kubectl apply -f -Create KongTargets
Use the KongTarget resource to register two individual backend Targets for the Upstream.
First, create target-a:
echo '
kind: KongTarget
apiVersion: configuration.konghq.com/v1alpha1
metadata:
name: target-a
namespace: kong
spec:
upstreamRef:
name: upstream
target: 10.0.0.1
weight: 30
' | kubectl apply -f -Next, target-b:
echo '
kind: KongTarget
apiVersion: configuration.konghq.com/v1alpha1
metadata:
name: target-b
namespace: kong
spec:
upstreamRef:
name: upstream
target: 10.0.0.2
weight: 70
' | kubectl apply -f -Validation
You can verify the KongUpstream was reconciled successfully by checking its Programmed condition.
kubectl get -n kong kongupstream upstream \
-o=jsonpath='{.status.conditions[?(@.type=="Programmed")]}' | jqThe output should look similar to this:
{
"observedGeneration": 1,
"reason": "Programmed",
"status": "True",
"type": "Programmed"
}You can verify the KongTarget was reconciled successfully by checking its Programmed condition.
kubectl get -n kong kongtarget target-a \
-o=jsonpath='{.status.conditions[?(@.type=="Programmed")]}' | jqThe output should look similar to this:
{
"observedGeneration": 1,
"reason": "Programmed",
"status": "True",
"type": "Programmed"
}You can verify the KongTarget was reconciled successfully by checking its Programmed condition.
kubectl get -n kong kongtarget target-b \
-o=jsonpath='{.status.conditions[?(@.type=="Programmed")]}' | jqThe output should look similar to this:
{
"observedGeneration": 1,
"reason": "Programmed",
"status": "True",
"type": "Programmed"
}Cleanup
Delete the resources created in this guide
Deleting the KonnectGatewayControlPlane also deletes the control plane the Kong Operator created in Konnect:
kubectl delete -n kong --ignore-not-found \
kongtarget/target-a \
kongtarget/target-b \
kongupstream/upstream \
konnectgatewaycontrolplane/gateway-control-plane \
konnectapiauthconfiguration/konnect-api-authDelete the namespaces
helm uninstall kong-operator -n kong-system
kubectl delete namespace kong kong-system