Upgrade and uninstall

MetaDefender Cluster upgrades are Helm upgrades. Because the deployment is split across two releases, you can upgrade the core services and the MetaDefender Cluster Worker instances independently — and in most cases, you should.

Before you upgrade

Upgrade services before instances. The MetaDefender Cluster Control Center orchestrates the MetaDefender Cluster Workers, so it should be running the newer version when the MetaDefender Cluster Workers roll.

Every upgrade in this guide uses --reuse-values: it takes the previous release's values as the base and merges your --set overrides on top, so you name only what changed rather than restating your whole configuration.

Upgrade the core services

To upgrade MetaDefender Cluster Control Center, MetaDefender Cluster File Storage and MetaDefender Cluster Identity Service together:

helm upgrade services ./md-cluster-services --reuse-values \ --set MDCLS_VERSION=<new_version>

To upgrade a single component, pin its version instead of the chart-wide tag:

# component = control-center | file-storage | identity-service helm upgrade services ./md-cluster-services --reuse-values \ --set <component>.version=<new_version>

control-center.version moves the installers initContainer image with it, since the installer bundle shares the MetaDefender Cluster Control Center's tag.

Expect a brief orchestration outage. The MetaDefender Cluster Control Center rolls out with maxSurge: 0, so its old pod is terminated before the new one starts — two MetaDefender Cluster Control Centers never run at once. MetaDefender Cluster Workers already running keep serving traffic and reconnect when it returns.

Upgrade the MetaDefender Cluster Worker instances

From the MetaDefender Clusterworker image, and the instance it deploys (MetaDefender Core, API Gateway or Callback Service). These upgrade separately.

Instances only

To upgrade the deployed instances without replacing the MetaDefender Cluster Worker image, use the MetaDefender Cluster Control Center's own instance upgrade flow — no Helm involved. See Upgrade Instances.

This has a precondition. The versions the MetaDefender Cluster Control Center offers are the ones it has staged from its installers initContainer image, whose tag follows the MetaDefender Cluster Control Center's own. A newer instance version therefore only becomes available after you have upgraded the services release. That is also the real reason for upgrading services first: not just that the MetaDefender Cluster Control Center should be newer, but that it must stage the new installers before any MetaDefender Cluster Worker can be told to use them.

MetaDefender Cluster Worker image and instances together

Set the new image version and opt in to the pre-upgrade Jobs:

helm upgrade instances ./md-cluster-instances --reuse-values \ --set MDCLS_VERSION=<new_worker_image_version> \ --set upgradeInstances=true

For one instance type only:

# instance_type = ometascan | api-gateway | callback-service helm upgrade instances ./md-cluster-instances --reuse-values \ --set workers.<instance_type>.version=<new_version> \ --set workers.<instance_type>.upgradeInstances=true

What `upgradeInstances` does

When enabled, the chart renders a Kubernetes Job per MetaDefender Cluster Worker instance type, marked as a Helm pre-upgrade hook. Each Job runs the new MetaDefender Cluster Worker image in pre-upgrade mode, which triggers the instance upgrade through the MetaDefender Cluster Control Center and then exits.

The Job runs before the StatefulSet rollout, so the instance upgrade is registered with the MetaDefender Cluster Control Center first. It only submits the request, though — the Job exits as soon as the MetaDefender Cluster Control Center accepts it, without waiting for the instances to finish upgrading. New MetaDefender Cluster Worker pods can therefore start while instances are still mid-upgrade. That is expected: each new pod undeploys and redeploys its instance anyway.

Each Job upgrades only the instance type it was rendered for. Enabling upgradeInstances globally renders one Job per type, and they all run concurrently.

Uninstall

Order matters here.

# 1. Remove the worker instances first — they unregister on the way out helm uninstall instances # 2. Wait for the worker pods to finish shutting down # 3. Remove the core services helm uninstall services

Uninstall instances before services. MetaDefender Cluster Worker shutdown ends by deleting the Worker's own entry in the MetaDefender Cluster Control Center, which is what lets the MetaDefender Cluster Control Center reclaim its license activation. If the MetaDefender Cluster Control Center is deleted first, the MetaDefender Cluster Workers have nothing to unregister from and those entries — with their activations — are never cleaned up. see Licensing in Kubernetes.

Persistent volumes survive

helm uninstall deliberately leaves your data behind:

The PostgreSQL PVC carries helm.sh/resource-policy: keep, so Helm never deletes it.
The MetaDefender Cluster File Storage PVCs come from a StatefulSet volume claim template, which Kubernetes never garbage-collects.

kubectl get pvc kubectl get pv

Keep them to reinstall with your data intact — a reinstall reattaches to the same volumes. To decommission fully, delete them explicitly:

kubectl delete pvc postgres kubectl delete pvc -l app=file-storage

Last updated on

Was this page helpful?