Operations

This page covers ongoing operational topics: upgrades, secret management, and generating support bundles.

Upgrades

Important: Do not roll back any KNIME services to a prior release version unless instructed to by KNIME Support. Database schema migrations are roll-forward only. Rolling services back may result in data loss or corruption.

Recommended Approach

1. Maintain at least two environments — Use a dev/staging environment and a production environment.
2. Upgrade dev first — Apply the new chart version to your dev environment, validate, and confirm the platform is healthy before upgrading production.
3. Review configuration changes — Before upgrading, compare your local-values.yaml to the updated default values shipped with the new version to check whether new or changed configuration options need to be addressed.

Upgrade Methods

Upgrades can be applied via Argo CD (recommended, using the App-of-Apps pattern) or directly via Helm. Detailed upgrade steps are provided by your Cloud Operations team in the configuration repository.

Post-Upgrade Checklist

After an upgrade:

1. Monitor sync status — Ensure all Argo CD Applications sync successfully.
2. Restart workloads if needed — Some pods may require a restart to pick up changes. If issues persist after 10–15 minutes, restart all StatefulSets and Deployments in the KNIME Business Hub namespace.
3. Re-sync applications — Trigger a full sync to re-run any jobs that may have failed during the upgrade.

Version Pinning

• Root chart: Pin via the targetRevision field in your Argo CD Application manifest (for example, a Git tag).
• Child charts: Pinned automatically by the root chart version. Individual child chart versions can be overridden in local-values.yaml when needed.

Secrets

KNIME Business Hub uses Kubernetes Secrets to manage credentials and sensitive configuration. This section describes the categories of secrets and how to rotate or replace them.

For specific secret names, key structures, and generation scripts, refer to the configuration repository provided by your Cloud Operations team.

Secret Categories

Bootstrap Secrets

Created once during installation. Changing them typically requires manual steps.

Secret	Rotatable?	Notes
License	No (requires new license)	Replace with new license file; restart workloads that use it
Image pull credentials	Yes	Update and restart pods in affected namespaces
PostgreSQL master credentials	Yes	Update secret and restart consuming pods
S3 credentials	Yes	Update secret and restart consuming pods
Secret store master key	No	If lost, secret store data is unrecoverable. Back up at installation time

Generated Credentials

KNIME Business Hub includes a secret generator component that creates per-database and per-service credentials during installation, which are then saved as Kubernetes Secrets in the cluster.

These credentials are:

• Rotatable — Services which reference the secrets will need to be restarted after rotation.
• Replaceable — You can disable secret generation for specific secrets and provide your own from an external source. The secret names and key structure must match what the charts expect.

Rotating Secrets

When rotating secrets:

1. Update the Kubernetes Secret with the new values.
2. Restart consuming workloads — Most services do not hot-reload secrets. Restart each affected StatefulSet or Deployment, or rely on Reloader which is enabled by default.
3. Verify — Check pod logs and application health after rotation.

Using External Secrets Managers

You can replace internally generated secrets with credentials from an external source (for example, AWS Secrets Manager or HashiCorp Vault):

1. Disable the relevant internal secret generation in the secret generator chart.
2. Create or sync secrets into the cluster with the exact names and keys expected by the charts.
3. Ensure secrets exist before the charts that consume them are deployed. When using in-cluster secret generation, sync waves handle ordering automatically. With an external sync, your secrets manager must run before or alongside the first sync wave.

Support Bundle

The support bundle collects cluster and application data for troubleshooting and support requests.

When to Run

Run the support bundle when:

• Opening a support ticket with KNIME
• Troubleshooting a failed upgrade or sync
• Diagnosing persistent pod or application failures
• Before and after significant configuration changes (for comparison)

How to Generate

Install the kubectl support-bundle plugin from troubleshoot.sh.

Detailed steps for generating the bundle — including the required configuration files that control what data is collected and what sensitive data is redacted — are provided by your Cloud Operations team in the configuration repository.

Sharing the Bundle

After generating the bundle, follow your organization's process for sharing diagnostic data with KNIME Support. Do not share unredacted bundles in public channels.