helm upgrade --install kong-operator kong/kong-operator -n kong-system \
--set image.tag=2.2 \
--set env.ENABLE_CONTROLLER_KONNECT=trueUpgrade Kong Operator with Helm
Uses:
Kong Operator
Deployment Platform
Related Documentation
Related Resources
TL;DR
Apply the updated CRDs with kubectl apply --server-side, then run helm upgrade against the kong-operator release.
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'
An existing Kong Operator installation
This guide requires an existing Kong Operator installation with the kong/kong-operator Helm chart. See Install Kong Operator if you haven’t installed it yet.
Review the changelog and complete pre-upgrade checks
Read the changelog for every version between your current version and the target, and complete the before-you-upgrade checks (version compatibility and resource backups).
Refresh the Helm repository
Pull the latest chart metadata so Helm can see new versions:
helm repo add kong https://charts.konghq.com
helm repo updateNote your current version
Record what’s running now so you can compare after the upgrade and roll back if needed:
helm list -n kong-system
kubectl -n kong-system get podsTo see which chart versions are now available:
helm search repo kong/kong-operator --versionsUpgrade the CRDs
Do this before upgrading the release. Helm does not update CRDs on
helm upgrade, so new fields your target version depends on will be missing until you apply them manually.
Apply the Kong Operator CRDs for the version you’re upgrading to. The command below uses the latest operator version (v2.2); if you’re upgrading to a different version, replace the ref:
kustomize build "github.com/Kong/kong-operator/config/crd/gateway-operator?ref=v2.2" | kubectl apply --server-side -f -If the release also bumps the Gateway API version, apply the matching Gateway API CRDs (this repo currently targets Gateway API 1.5.1):
kustomize build "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.5.1" | kubectl apply --server-side -f -Upgrade the release
Run helm upgrade against the kong-system namespace, setting image.tag to your target version. Because the command uses --install, it’s safe to re-run:
helm upgrade --install kong-operator kong/kong-operator -n kong-system \
--set image.tag=2.2Preserve any
--setflags or-f values.yamlfiles you used at install time (for exampleenv.ENABLE_CONTROLLER_*toggles).helm upgradereplaces the release configuration, so flags you drop are reset to their chart defaults. To reuse your existing values without re-listing them, add--reuse-values.
Validation
Wait for the controller manager to become available again:
kubectl -n kong-system wait --for=condition=Available=true --timeout=120s deployment/kong-operator-kong-operator-controller-managerThen confirm the release and pods report the new version:
helm list -n kong-system
kubectl -n kong-system get podsYour DataPlane gateways continue serving traffic during the upgrade; only the Kong Operator control plane restarts.
FAQs
How do I roll back an upgrade?
If something goes wrong, roll the release back to the previous revision:
helm history kong-operator -n kong-system
helm rollback kong-operator REVISION -n kong-systemA Helm rollback restores the operator Deployment, but it does not remove CRD fields you applied when upgrading the CRDs. CRDs are additive and backward-compatible within a major version, so leaving them in place is safe. For a major-version rollback, follow the relevant migration guide (for example 1.6.x to 2.0.0) in reverse.