Upgrade Camel K

Camel K is delivering new features with each new release, so, you’ll be probably running the upgrade process quite often. OLM installation method gives you the possibility to even perform this operation automatically, selecting the auto-upgrade feature when installing. The upgrade operation will install all the required configuration for the new operator version, replacing the previous one. Mind that the Integration resources running won’t be affected, so they will keep running with the default runtime details provided in the previous operator version.

you must notice that the deployment resources linked to an Integration (ie, Deployment, Knative-Service or CronJob) can change, if the new operator is setting any new configuration. This would lead to a transparent Pod rollout for all the existing Integrations at their very first reconciliation loop cycle (when the new operator will takeover from the previous one).

Upgrade via Kustomize

If you want to upgrade via Kustomize you’ll need to execute the same installation procedure you did for the previous version and add the --force-conflicts flag which will take care to overwrite any conflicting configuration (ie, rewriting the CRDs). Here an example for a descoped (global) installation procedure:

$ kubectl apply -k github.com/apache/camel-k/install/overlays/kubernetes/descoped?ref=v2.4.0 --server-side --force-conflicts

Upgrade via Operator Hub

Upgrading via Operator Hub may be automatically done by the cluster if this option was set at installation time. If not, you need to follow the instructions in the Camel K Operator Hub page.

Upgrade via Helm

Generally, when upgrading a patch or a minor version, we may introduce slight non-breaking compatibility changes in CRDs. These changes should be onboard-ed with the installation procedure you’re using (CLI, OLM, Kustomize). However, you may want to control the upgrade of CRDs (for instance, upgrading in Helm, which, does not support CRDs upgrade out of the box). In this case, before doing the upgrade, you’ll need to manually upgrade the CRDs, in order to use the new parameters expected by the new operator you’re upgrading to. For Helm, this would turn in an operation like the following one:

# Upgrade the CRDs
$ curl -LO "https://github.com/apache/camel-k/raw/main/docs/charts/camel-k-x.y.z.tgz"
$ tar xvzf camel-k-x.y.z.tgz
$ kubectl replace -f camel-k/crds
# Upgrade the `camel-k` Deployment
$ helm upgrade camel-k/camel-k --version x.y.z
you may need to perform more configuration to reflect the same customization configuration done in the previous version installation.

Refresh integrations

Once the operator is up to date, you may want to refresh the Integration resources with the new default configuration provided by the upgraded operator (for instance, the default runtime). In such case you’ll need to run a kamel rebuild operation for each integration you want to update, or kamel rebuild --all if you want to upgrade all the Integrations at once.

we suggest a controlled approach and rebuild one integration after another.

Stick runtime version

Since Camel K version 2, we’re able to run any Camel K runtime version from the same operator. However, if you upgrade and you rebuild an Integration, this one will be rebuilt using the default runtime version of the new operator. In order to stick to a runtime fixed version you need to use the Camel trait and the runtime-version property, which pin the exact runtime version to use, regardless the default one used by the operator:

kamel run /tmp/Test.java -t camel.runtime-version=1.17.0
kubectl apply -k github.com/apache/camel-k/install/overlays/kubernetes/descoped?ref=v2.4.0 --server-side --force-conflicts //ie, version 2.4.0
kamel rebuild test
kamel logs test
[1] 2023-04-13 13:38:43,648 INFO  [org.apa.cam.k.Runtime] (main) Apache Camel K Runtime 1.17.0
Back to top