Configure your HTTPRoute with one entry in backendRefs for each Service version, and assign a weight to each version to define how to split the traffic.
If you don’t have a Konnect account, you can get started quickly with our onboarding wizard.
Set the personal access token as an environment variable:
export KONNECT_TOKEN='YOUR KONNECT TOKEN'
Add the Kong Helm charts:
helm repo add kong https://charts.konghq.com
helm repo update
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 -
Add the Kong Helm charts:
helm repo add kong https://charts.konghq.com
helm repo update
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 -
Create the kong namespace:
kubectl create namespace kong
Create the GatewayConfiguration, GatewayClass, and Gateway resources with basic configuration:
echo '
apiVersion: gateway-operator.konghq.com/v2beta1
kind: GatewayConfiguration
metadata:
name: gateway-configuration
namespace: kong
spec:
dataPlaneOptions:
deployment:
podTemplateSpec:
spec:
containers:
- image: kong/kong-gateway:3.13
name: proxy
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: gateway-class
spec:
controllerName: konghq.com/gateway-operator
parametersRef:
group: gateway-operator.konghq.com
kind: GatewayConfiguration
name: gateway-configuration
namespace: kong
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: kong
namespace: kong
spec:
gatewayClassName: gateway-class
listeners:
- name: http
port: 80
protocol: HTTP' | kubectl apply -f -
Traffic splitting, also known as canary releases or blue/green deployments, allows you to shift traffic between multiple versions of your service.
With Kong Operator and the Gateway API, traffic splitting is managed natively using HTTPRoute weights.
Deploy two versions of the same Service:
echo '
apiVersion: v1
kind: Service
metadata:
name: echo-v1
spec:
selector:
app: echo-v1
ports:
- name: http
port: 80
targetPort: 1027
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: echo-v1
spec:
replicas: 1
selector:
matchLabels:
app: echo-v1
template:
metadata:
labels:
app: echo-v1
spec:
containers:
- name: echo
image: kong/go-echo:latest
env:
- name: NODE_NAME
value: "v1"
---
apiVersion: v1
kind: Service
metadata:
name: echo-v2
spec:
selector:
app: echo-v2
ports:
- name: http
port: 80
targetPort: 1027
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: echo-v2
spec:
replicas: 1
selector:
matchLabels:
app: echo-v2
template:
metadata:
labels:
app: echo-v2
spec:
containers:
- name: echo
image: kong/go-echo:latest
env:
- name: NODE_NAME
value: "v2"
' | kubectl apply -f - -n kong
Define an HTTPRoute resource that references both Services in the backendRefs section. Each reference includes a weight.
In this example, we’ll configure a 50/50 split between the Services:
echo '
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: canary-route
namespace: kong
spec:
parentRefs:
- name: kong
rules:
- matches:
- path:
type: PathPrefix
value: /echo
backendRefs:
- name: echo-v1
port: 80
weight: 50
- name: echo-v2
port: 80
weight: 50' | kubectl apply -f -
Weights are relative. If you have two backends with weights 50 and 50, traffic is split 50/50. If weights are 90 and 10, traffic is split 90/10.
Get the Gateway’s external IP:
export PROXY_IP=$(kubectl get gateway kong -n kong -o jsonpath='{.status.addresses[0].value}')
Send multiple requests to the Route:
for i in {1..10}; do curl -s http://$PROXY_IP/echo; done
You should see an even split between v1 and v2:
Welcome, you are connected to node v1.
Welcome, you are connected to node v2.
Welcome, you are connected to node v1.
Welcome, you are connected to node v1.
Welcome, you are connected to node v2.
Welcome, you are connected to node v1.
Welcome, you are connected to node v2.
Welcome, you are connected to node v1.
Welcome, you are connected to node v2.
Welcome, you are connected to node v2.