Skip to main content

Uninstall

This page removes the Momento Valkey Operator from a Kubernetes cluster: Valkey clusters, then export and release retained metering records, then the operator and CRDs, in that order. The order matters: reversing it can leave resources stuck or remove retained billing records before export. It is written for platform teams decommissioning the operator entirely; to remove one Valkey cluster and keep the operator, delete only that ValkeyCluster.

Match your installed version before you start​

The commands below reference release manifest URLs pinned to a version. Use the URLs for the version you actually installed, not necessarily the latest release. An operator manifest from a different version than your CRDs can leave the CRD schema and the running operator's expectations out of sync during teardown.

Check the deployed image tag:

kubectl -n valkey-operator get deployment valkey-operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

The tag in the output (for example, gomomento/valkey-operator:v0.9.0) tells you which release's crds.json and operator.yaml to reference throughout this page.

1. Delete all ValkeyClusters first​

kubectl delete valkeycluster --all -A

Deleting a ValkeyCluster triggers the operator's cleanup finalizer, which relies on Kubernetes cascade-delete of everything owned by the cluster: its ValkeyNode resources, their Pods and ConfigMaps, the headless Service, the operator auth Secret, and the ACL ConfigMap. That finalizer only clears with the operator running and reconciling. Wait for the clusters to actually disappear before moving on:

kubectl get valkeycluster -A

Confirm the list is empty before proceeding. If a cluster stays Terminating, do not continue to the next step: the operator must still be running to finish the cleanup. See the stuck-Terminating entry in Troubleshooting if it doesn't clear.

2. Export and release metering records​

With every cluster deleted and the operator still running, export the records:

kubectl get valkeymeteringrecords -n valkey-operator -o json > usage-final.json
warning

This export is your retained copy. Records for deleted clusters cannot be reconstructed. Confirm that the export succeeded before releasing them.

Release the records while the operator is still available to process the annotation:

kubectl annotate valkeymeteringrecords -n valkey-operator --all \
  valkey.gomomento.com/release=true

The command makes one request per record and can take minutes for a large fleet. It is safe to rerun. Releasing records before deleting clusters lets the operator recreate them; removing the operator first leaves no controller to process release. See Usage metering.

3. Delete the operator​

kubectl delete -f https://github.com/momentohq/valkey-operator/releases/download/v0.9.0/operator.yaml

Use the manifest URL matching the version you installed. This removes the operator's Deployment, ServiceAccount, ClusterRole, ClusterRoleBinding, ConfigMap, and namespace.

4. Delete the CRDs​

kubectl delete -f https://github.com/momentohq/valkey-operator/releases/download/v0.9.0/crds.json
warning

Deleting a CustomResourceDefinition cascades deletion of every custom resource of that kind, cluster-wide. If any ValkeyCluster (on this or another operator installation sharing the same CRDs) still exists at this point, deleting the CRDs deletes it too, bypassing the finalizer-driven cleanup from step 1. Confirm step 1 is complete across every namespace you care about before running this.

This removes the Operator CRDs, including ValkeyImage, ValkeyConfig, ValkeyRole, ValkeyCluster, ValkeyMeteringRecord, and ValkeyNode.

Verify cleanup​

Confirm nothing tagged for the operator or its clusters remains:

kubectl get crd | grep valkey.gomomento.com   # expect no output
kubectl get namespace valkey-operator          # expect NotFound
kubectl get pods -A -l app.kubernetes.io/name=valkey   # expect no output

The pod label app.kubernetes.io/name=valkey is guaranteed on every Valkey pod the operator ever created, so an empty result here is strong evidence step 1 completed everywhere. Services, ConfigMaps, and Secrets belonging to a cluster follow naming patterns rather than a shared label ({cluster}, {cluster}-operator-auth, {cluster}-acl, {node}-config). See Labels and annotations for the full taxonomy if you need to search a namespace by hand for anything a partially-completed finalizer left orphaned.

Wrong order​

If you deleted the operator or the CRDs before deleting your ValkeyCluster resources, see Cluster stuck Terminating: the fix is to restore the operator so cleanup can complete, not to force-delete resources by hand.