Skip to main content

Preview the plan

The uninstall script is published alongside the installer, so it can be run without a repository checkout. It supports dry-run mode:
For a specific context and namespace:

Before you uninstall

The release owns the KubeBlocks definitions that every deployment references. Once they are gone, KubeBlocks can no longer reconcile or heal a deployment, so the script refuses to run while FalkorDB deployments exist. Delete them first, after copying any data you need to object storage. Pass --force only to uninstall anyway; the deployments keep running, but nothing manages them. The script keeps:
  • The backup repository (BackupRepo) and the backups in it. Reinstalling under the same release name and namespace adopts it again. Delete it with kubectl delete backuprepos.dataprotection.kubeblocks.io <name> when you no longer need the backups.
  • The bootstrap admin user Secret and the <release>-initial-admin-password Secret, unless --delete-namespaces deletes the namespace they are in.
When the installer made its bundled csi-hostpath-sc the default StorageClass, the script makes the original default StorageClass the default again.

Uninstall Enterprise only

This removes the FalkorDB Enterprise Helm release and retained FalkorDB addon resources. KubeBlocks is kept.
For automation:

Also uninstall KubeBlocks

--uninstall-kubeblocks removes the KubeBlocks release and the snapshot-controller release the installer put in the same namespace. The Snapshot Controller goes last, after any namespaces and CRDs the uninstall deletes, so it can still clean up the volume snapshots in them. If you installed the Snapshot Controller under another release name (SNAPSHOT_CONTROLLER_RELEASE), pass the same name with --snapshot-controller-release.

Delete namespaces

If --uninstall-kubeblocks is not provided, --delete-namespaces deletes only the Enterprise namespace. Before it removes anything, the script deletes the VolumeGroupSnapshot and then the VolumeSnapshot objects in the namespaces it will delete. It does this while the Snapshot Controller and the bundled CSI driver’s snapshotter, which the Enterprise release removes, can still remove their finalizers. Their VolumeSnapshotContent objects follow their own deletionPolicy, so snapshots set to Retain keep their data. If a snapshot is still there after --crd-delete-timeout, the script names it and stops with everything still installed. KubeBlocks marks the snapshots its backups take so that they are deleted only with their Backup, and the script keeps backups. If such a snapshot is in the cleanup scope of --delete-namespaces or --delete-crds, the script lists it with its Backup and stops before changing anything. Delete those backups first if you no longer need them, or uninstall without those flags. A namespace that is still terminating after --crd-delete-timeout is reported and the uninstall continues. Any other error deleting a namespace stops the uninstall.

Delete CRDs

Deleting CRDs removes the KubeBlocks, VolumeSnapshot and VolumeGroupSnapshot API definitions from the cluster. This can affect other workloads that use those APIs. --delete-crds removes every snapshot in the cluster with its CRD. So the script first deletes all group snapshots, snapshots and their contents, the same way and at the same point as for namespaces above. Contents set to Delete remove their snapshot data; contents set to Retain keep it. With --uninstall-kubeblocks, the script also deletes every ParamConfigRenderer and Restore, while the KubeBlocks controllers are still running to remove their finalizers. Left behind, for example by an older addon version, they would keep their CRDs from being deleted. If any of them is still there after --crd-delete-timeout, the script names them and stops, leaving KubeBlocks installed so a re-run can finish the cleanup. Each CRD deletion waits at most --crd-delete-timeout (default 5m). If a CRD is still there after that, the script stops and lists the objects that hold it, with their finalizers. It does not remove finalizers itself: reinstall the controller that owns them so it can finish the cleanup, or remove the finalizers by hand once you are sure nothing else needs those objects.

Verify removal

If KubeBlocks was removed:
If namespaces were deleted: