This guide contains the information needed to update KNIME Business Hub.
Three different types of updates can be performed:
-
Update the Business Hub instance - when a new version of KNIME Business Hub is released you might need to update to a newer version. To update your Business Hub instance follow the instructions here.
-
Update an Executor - when a new version of the KNIME Analytics Platform is released you might need to update the executors to a newer version. To update executors follow the instructions here.
-
Update the Kubernetes version - when support is added by KNIME for a newer Kubernetes version you might need to update the underlying Kubernetes version. To update Kubernetes follow the instructions here.
KNIME Business Hub and executor updates happen independently of each other, meaning that updating Hub will not necessitate updating the executors and vice versa. Also, in the case in which your license allows you to have multiple Execution Contexts you can decide to have different executor versions for each Execution Context. This means that you might need to update only some of the executors and not necessarily all of them.
Update the KNIME Business Hub instance
To update the KNIME Business Hub instance go to your KOTS Admin Console.
If there is a new version available it will show up here. Click Deploy to initiate the update.
| If you have to update an airgapped (offline) installation you will first need to download a new airgap bundle. |
Depending on the services that are going to be updated, as well as the installation type, there might be some downtime. Consult the release notes to learn about possible downtime for each version update. To read more about downtime go to the Downtime section.
We recommend, before the update, doing a backup by using the built-in backup tool Velero.
Downtime for Hub instance updates - FAQ
Is it necessary to schedule a maintenance window during which a Hub update is performed?
-
For single node installations: yes
-
However, this depends on which services are updated (some updates will work without downtime). We will address this in every release note.
-
-
For multi node installations:
-
If High Availability is enabled for all services, one instance of a service can be updated while anotherone remains operational, so no downtime is expected.
-
If High Availability is not enabled, a maintenance window should be scheduled, unless stated otherwise in the release notes.
-
-
If a maintenance window is necessary, we recommend scheduling it for 2 hours.
Will my workflow deployments still run during a Hub update?
-
For typical updates, yes. If not, this will be stated explicitly in the release notes.
-
Only High Availability installations can ensure that an update does not affect deployments.
Update the executors
To update executors you will need to update the execution context by pointing it to a new Docker image. The Docker image will contain an installation of KNIME Analytics Platform that is configured to be used as an executor, including all needed extensions. Switching to a new image is done separately for each execution context, by the team admin of the respective team.
To do so go to the Execution resources overview page, click the three dots icon corresponding to the execution context you want to modify, and select Edit from the menu that opens. In the side panel that opens you can point the execution context to the new Docker image, as shown here.
Updates of executors are independent of any other parts of the installation so an update of one execution context will not affect any other execution contexts, or the Hub instance itself.
Testing executor updates
-
For Standard and Enterprise editions, we recommend first creating a new execution context to test an update.
-
This execution context exists alongside the "old" version. I.e., this does not interfere with existing operations.
-
In case you have already used up all the licensed vCores, you can shift over some vCores from an existing execution context to be able to start a new one. This is done by editing the existing execution context.
-
After creating this new testing execution context, you can run all the needed workflows and make sure they still produce the expected results.
-
After testing is completed, the new execution context can be deleted, and vCores can be shifted back to the original execution context if necessary.
-
If testing was successful, you can proceed with the update of the original execution context.
-
-
For the Basic edition, this is currently not possible since there is only a single execution context available.
-
For all the editions, the recommended rollback strategy is to point the execution context to the previous Docker image again. There is no need to do a restore from a backup, as the executor containers are not expected to hold valuable data.
Downtime for executor updates
There are two basic strategies for updating execution contexts:
-
Recreate
-
Executor containers of the old version are terminated when an update prompt is received. New containers are started only when old containers are gone.
-
This strategy involves downtime but is easy on cluster resources since no old and new containers exist in parallel.
-
Downtime depends on the time needed to pull the image from where it is hosted (the image is ~5GB in size) plus ~30s to start a new executor container.
-
-
-
Rolling Update
-
Executor containers of the old version keep running until the pods of the new version are ready and terminate soon after.
-
This strategy presents no downtime but is heavy on resources as there is a short period where both old and new containers are running in parallel. Also, you will need to provide enough spare resources in the cluster.
-
-
Recreate is the default for all Hub installations since version 1.2.0.
However, it is possible to change the default executor update strategy from the Replicated portal. If you want zero downtime during executor updates and can provide the necessary resources, you can switch executor updates to Rolling Update.
Update Kubernetes
Kubernetes is the infrastructure component inside which KNIME Business Hub runs. There are regular releases from Kubernetes, each with a fixed support lifecycle (see here). We do not have a fixed cycle in which we require Kubernetes version to be updated but it is not something that is requested with every Business Hub release. In fact, every Hub version supports a range of Kubernetes versions that are listed in the KNIME Business Hub Installation Guide.
A Kubernetes update is required only if you want to use a new feature that requires a newer Kubernetes version, or if your current Kubernetes version is not supported by KNIME Business Hub anymore.
The installer will check before each Hub update if the current Kubernetes version is supported during the preflight-check. In case it is not, the update won’t start.
In case an update of Kubernetes needs to be performed you will need to run the Kubernetes installer script again.
-
For single node installations: the update will result in downtime since the node itself is restarted. We recommend scheduling a maintenance window of 30 minutes.
-
For multi node installations: the downtime, in this case, is reduced since one node at a time is drained and then updated. However, since there might still be moments in which the Kubernetes control plane is temporarily not reachable we still recommend scheduling a maintenance window, unless you are running an installation that has High Availability enabled for all services.
Update KOTS
KOTS is the application managing the Replicated installation itself. A fresh installation of a KNIME Business Hub instance will automatically use the latest KOTS version. However, when updating to a newer version of KNIME Business Hub it might happen, on some occasions, that an update of KOTS needs to be forced. This will be stated explicitly in the release notes together with instructions on how to update KOTS.