KNIME Documentation

Business Hub Upgrade Notes and Technical Changes ​

Notes for all versions ​

Updating CRDs ​

Some upgrades include changes to Custom Resource Definitions (CRDs).

If you are using the automated CRD updater tool bundled with the KNIME Business Hub application, CRDs are updated automatically during the upgrade.

If you have disabled the updater and installed CRDs manually, make sure to re-apply the latest CRDs from the public repository after each upgrade.

Outdated CRDs can cause issues such as executor errors or failed component deployments.

KNIME Business Hub version 1.18.0 ​

Migrating from Ingress-NGINX to Istio when updating to KNIME Business Hub 1.18.0 ​

Ingress-NGINX has been deprecated (see the Kubernetes blog post Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees). As of KNIME Business Hub 1.18.0, the default ingress controller is the Istio Ingress Gateway.

Installations that previously used the built-in Ingress-NGINX controller will automatically migrate to the Istio Ingress Gateway during the upgrade.

This change removes security exceptions and CVEs associated with Ingress-NGINX and simplifies integrations with external ingress controllers. However, depending on how your installation is deployed, the upgrade may require updates to networking configuration or infrastructure.

Important upgrade change

KNIME Business Hub 1.18.0 replaces the Ingress-NGINX controller with the Istio Ingress Gateway.

Before upgrading, review the migration playbook:

The guide describes upgrade scenarios, configuration changes, and troubleshooting steps.

Important considerations before upgrading ​

  • Perform the upgrade during a maintenance window.
  • Ensure verified backups exist before upgrading.
  • If TLS is enabled, keep Enable TLS enabled in the KOTS Admin Console regardless of where TLS is terminated.
  • If your previous ingress-nginx-controller service used the LoadBalancer type, the underlying load balancer may be removed during the upgrade. DNS records or load balancer configuration may need to be updated accordingly.
  • For existing cluster installations, node ports now default to 30080 and 30443 to improve compatibility with Kubernetes distributions that restrict low-numbered ports.

Need Help?

If you need assistance planning or performing the upgrade, contact support@knime.com.

Migrating the Secret Store to Postgres ​

The secret store now stores secrets in Postgres by default.

If the default Helm values have not been modified, the secret store service automatically migrates all existing secrets to Postgres during the upgrade.

After upgrading, Hub admin users should log in to the Hub WebUI and verify that the migration completed successfully. If the migration fails, the Hub WebUI displays a persistent error toast on all pages that cannot be dismissed. The toast includes information about the underlying error.

Upgrading Existing ArgoCD Installations ​

For ArgoCD-based installations, the migration is triggered automatically and no manual action is required.

During the migration, Hub secrets remain fully usable.

Be careful when changing Helm values during the Business Hub upgrade. Do not disable the old secret backend (knime-hub-vault or knime-hub-secret-store-minio) or modify the configuration in knime-hub-secret-store to access the old secret backend. Doing so prevents secrets from being migrated to Postgres.

Upgrading Existing Replicated Installations ​

Replicated-based installations require additional manual steps.

To start the migration, the Hub admin user must create a master key in the Hub WebUI.

Until the master key is set up:

  • Hub secrets remain usable.
  • Existing secrets cannot be edited or created.
  • The secret-store-kes Kubernetes service may be temporarily unavailable. This is expected and the service starts automatically once the master key is created.

While the master key has not yet been configured, the Hub admin sees a Set up secrets toast on all pages of the KNIME Hub WebUI.

To start the setup process:

  1. Click Go to secrets setup in the toast, or navigate to the Administration → Secrets page.
  2. On the secrets page, click Set up secrets.
  3. Follow the dialog instructions to complete the setup.

Important

The displayed master key is only shown once and must be stored in a safe location. It is required to restore secret keys from a backup.

Once the master key has been created, the migration from the legacy secret store starts automatically in the background. During this migration, Hub secrets remain fully usable.

KNIME Business Hub version 1.17.1 ​

  • Example command for specifying service account name in Execution Context resources (this must be done after the Execution Context is created in the KNIME Business Hub webapp):
    • Patching a single Execution Context: kubectl patch executioncontext ebddd3db-0ede-4dc5-a428-4f3fb57223fc -n knime --type=merge -p '{"spec":{"executor":{"serviceAccountName":"catalog-service"}}}'
    • Patching all Execution Contexts: kubectl get executioncontext -n knime -o name | xargs -I{} kubectl patch {} -n knime --type=merge -p '{"spec":{"executor":{"serviceAccountName":"default"}}}'

KNIME Business Hub version 1.17.0 ​

Important Notice

We are still assessing production readiness of KNIME Business Hub 1.17.0 for the OpenShift distribution. If you are deploying KNIME Business Hub into OpenShift, please do not install or upgrade to 1.17.0. KNIME will make an announcement or release a patch in the near future to ensure OpenShift compatibility.

Upgrade Notes / Technical Changes ​

  • In ArgoCD, Elasticsearch has been configured to be highly available by default. This provisions 3 replicas for the Elasticsearch StatefulSet which have anti-affinity.
    • By default, the anti-affinity is set to use “soft” (best-effort) scheduling. This is to ensure Elasticsearch comes online in smaller clusters.
    • If anti-affinity is set to “hard”, there must be 3+ schedulable nodes in the cluster for Elasticsearch to run on (based on kubernetes.io/hostname topology key).
    • If using “soft”, please note that there are a few risks:
      • HA risk: Both replicas of one ES shard could be scheduled on the same node; if that node fails, both replicas are lost.
      • AWS AZ issue: Pods can get "stuck" in a specific AZ even if you add nodes in other AZs, since EBS volumes (PVCs) are not automatically moved between AZs.
      • Changing from "soft" to "hard" in existing clusters may cause scheduling issues if there are insufficient nodes to satisfy the hard anti-affinity requirement.
    • The elasticsearch-master StatefulSet can be deleted (allowing ArgoCD to recreate it), both for the 1.17.0 upgrade and in general when changing Elasticsearch configuration. Please note that search and other functionality will be offline while Elasticsearch is provisioning.
  • ArgoCD customers upgrading from <1.17.0: Set knime-hub-secret-store-minio.config.s3.url = "http://secret-store-minio:9000" in your local-values.yaml overrides, to continue using the internal secret store because migration to offloaded S3 is not yet supported.
  • Notifications Service: Starting with 1.17.0, whitespaces at the beginning of lines in the configuration of the notification service are not allowed anymore. Such lines will be ignored.
  • Removal of X-Frame-Options, replaced with frame-ancestors in CSP.

Removal of the X-Frame-Options header ​

In previous releases, embedding Data Apps in iframes was controlled by the X-Frame-Options header. This header only has three options: allow embedding on the same domain, anywhere, or nowhere. The frame-ancestors directive in the Content-Security-Policy header allows for more control over which webpages can embed Data Apps, so we've removed the X-Frame-Options header from KNIME Business Hub.

  • If you've never allowed embedding Data Apps before: There is no change for you. We set a default that denies all embedding.
  • If you've allowed embedding Data Apps before: Configure the frame-ancestors directive in the Content-Security-Policy header to include your external webpages. See Configure Browser Security for more information.

KNIME Business Hub version 1.16 ​

Important notice for existing customers (32 GiB RAM instances) ​

Previously, a Hub instance with 32 GiB of RAM could host executors configured with up to 12 GiB of memory. After this update, the maximum executor size must be reduced to 8 GiB before starting the upgrade (Editing Executor Configuration). If executor memory is not adjusted, executors will fail to start until their configuration is lowered.

For customers on instances with more than 32 GiB RAM ​

In some cases, a large share of memory may already be reserved for execution. To ensure smooth operation, core services now require 24 GiB, leaving the remainder available for execution. Please adjust your executor memory accordingly before the update.

Updated KURL installer (KURL Installer), bringing the following updates and more:

  • Kubernetes update to 1.33.4 (from 1.30.7 compared to last KURL update)
  • KOTS installer update to 1.125.2
  • Velero update to 1.16.2

Updated RoleBinding for license validation ​

With this release the RoleBinding used for license validation has been updated with additional ServiceAccount references. If you’ve installed KNIME Business Hub with Minimal RBAC you need to apply the updated Cluster Roles as described here before updating.

Upgrading Existing Argo CD Installations ​

For clusters where KNIME Business Hub was previously installed and managed via Argo CD, ensure the following configuration adjustments before upgrading to this release:

  1. Navigate to Settings → Projects → knime-business-hub.
  2. Under Namespaces, set this resource to Denied in the project configuration.
  3. In the Cluster Resource Allow List, allow all resources (*).
  4. In the Cluster Resource Deny List, deny at least the Namespaces resource.
  5. In the Namespace Resource Allow List, allow all resources (*).

These settings ensure a safe and consistent upgrade path for existing deployments managed by Argo CD.

KNIME Business Hub version 1.15 ​

Istio upgrade ​

Istio has been upgraded to version 1.24.2.

  • For installations that have manually installed istio it is highly recommended to update istio to the same version. Instructions are available here.
  • For installations that install istio via KOTS, no other input is required. The upgrade will be automatic.

This upgrade will be mandatory in future releases when features only found in istio 1.24 are in use.