Update or uninstall Dynatrace Operator

• Latest Dynatrace
• 12-min read
• Updated on May 05, 2026

This page provides detailed instructions on how to update or uninstall Dynatrace Operator in Kubernetes and OpenShift environments.

Dynatrace Operator manages the deployment and lifecycle of all Dynatrace components in your Kubernetes clusters (for example, OneAgent, ActiveGate, and code modules). Dynatrace Operator itself needs to be updated either by applying new manifests or by using Helm charts.

We recommend using an up-to-date Dynatrace Operator version (at least version n-2) and always using the latest patch version (for example, 1.7.3 instead of 1.7.0).

Update Dynatrace Operator

To update Dynatrace Operator, select one of the following options, depending on your deployment approach:

Manifest

Helm

Manifest

For classicFullStack, applicationMonitoring, or hostMonitoring without CSI driver execute the following command.

kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/kubernetes.yaml

oc apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/openshift.yaml

If you're using the CSI driver, use this command instead:

kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/kubernetes-csi.yaml

oc apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/openshift-csi.yaml

Helm

Update ActiveGate pods

Typically, ActiveGate pods are updated automatically on pod restart whenever there is a new version available (unless the image already specifies a certain version). However, if you need to manually restart ActiveGate pods, run the command below.

kubectl -n dynatrace rollout restart statefulset/<ACTIVEGATE-STATEFULSET-NAME>

oc -n dynatrace rollout restart statefulset/<ACTIVEGATE-STATEFULSET-NAME>

Update Access tokens

If you need to update your Dynatrace access tokens, follow the steps below.

Find current tokens

Delete your secret

Create new tokens

Create a new secret with updated tokens

Delete the old tokens

Find current access tokens

Find and save your currently used tokens.

After generating new tokens, you'll need to delete the old ones.

kubectl -n dynatrace get secrets <dynakube-name> -o yaml | yq '.data.apiToken' | base64 -d

oc -n dynatrace get secrets <dynakube-name> -o yaml | yq '.data.apiToken' | base64 -d

Delete your secret

To delete the secret, run one of the commands below.

In Kubernetes, used tokens are stored in a secret named dynakube by default. If the DynaKube custom resource has a different name, or the tokens field in DynaKube is set, make sure that the new secret has the same name as defined there.

kubectl -n dynatrace delete secret dynakube

oc -n dynatrace delete secret dynakube

Create new access tokens

For instructions on how to create the tokens, see Access tokens and permissions.

Create a new secret with updated access tokens

To create a new secret with the updated tokens, run one of the commands below, making sure to replace the placeholders with the new tokens.

Dynatrace Operator picks up the updated secrets in approximately five minutes. Removing DynaKube and reapplying it forces an instant reconciliation.

Delete the old access token

After the new tokens are in place, delete the old ones.

Uninstall Dynatrace Operator

The following guide outlines the recommended steps for a clean uninstallation of Dynatrace Operator.

Remove Dynatrace Operator–managed components

Optional Restart your monitored applications

Remove Dynatrace Operator

Optional Cleanup nodes

Remove Dynatrace Operator–managed components

Delete DynaKube custom resources to allow Dynatrace Operator to fully delete all related Dynatrace Operator–managed components from your Kubernetes cluster. Wait for those components to be removed to make sure the cleanup is completed successfully.

kubectl delete dynakube -n dynatrace --all
kubectl delete edgeconnect -n dynatrace --all
kubectl -n dynatrace wait pod --for=delete -l app.kubernetes.io/managed-by=dynatrace-operator --timeout=300s
kubectl -n dynatrace wait edgeconnect --for=delete --all --timeout=300s

oc delete dynakube -n dynatrace --all
oc delete edgeconnect -n dynatrace --all
oc -n dynatrace wait pod --for=delete -l app.kubernetes.io/managed-by=dynatrace-operator --timeout=300s
oc -n dynatrace wait edgeconnect --for=delete --all --timeout=300s

Optional If you used the CSI driver: Restart your monitored applications

To ensure that CSI volumes are properly unmounted and disconnected from the CSI driver before proceeding with the uninstallation, use the following command to identify applications that use the CSI driver and need to be restarted.

The output will show a list of pods in the format namespace pod for each application that uses the CSI driver.

kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.volumes[*].csi.driver=="csi.oneagent.dynatrace.com")]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

oc get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.volumes[*].csi.driver=="csi.oneagent.dynatrace.com")]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Remove Dynatrace Operator

After all Dynatrace Operator–managed components have been successfully removed, you can safely uninstall Dynatrace Operator.

Clean up nodes

Depending on the monitoring mode, OneAgent and CSI driver data might remain on the node. To ensure a clean state, use a cleanup script to remove unnecessary data.

The script deploys a DaemonSet that runs a cleanup procedure on all Linux nodes in the cluster (amd64, arm64, ppc64le, s390x).

curl -O https://raw.githubusercontent.com/Dynatrace/dynatrace-operator/refs/tags/v1.9.0/hack/cluster/cleanup-node-fs.sh

chmod +x cleanup-node-fs.sh

./cleanup-node-fs.sh

By default, the script uses the dynatrace namespace. To specify a different namespace, pass it as an argument:

./cleanup-node-fs.sh <namespace>

The script performs the following actions:

After all cleanup pods complete successfully, the DaemonSet is automatically deleted. If any cleanup fails, the DaemonSet remains for investigation.

Upgrade from older versions

If you have ever run a Dynatrace Operator version older than 1.4 in your cluster - regardless of which version you're on today - you must upgrade to version 1.7.3 first before going to the latest release. From 1.7.3, the Operator handles the necessary DynaKube conversion and CRD cleanup automatically.

To find out whether you're affected and if a version jump is possible, see Check your current versions.

Check your current versions

Check your current Dynatrace Operator version.

helm list -n dynatrace -o json | jq -r '.[].app_version'

kubectl get deployment dynatrace-operator -n dynatrace \
  -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}'

Check your current DynaKube API version:

kubectl get dynakubes -n dynatrace -o custom-columns='NAME:.metadata.name,API VERSION:.apiVersion'

Check which API versions have ever been used to store DynaKubes in this cluster:

kubectl get crd dynakubes.dynatrace.com -o jsonpath='{.status.storedVersions}'

Every API version listed in .status.storedVersions must still be served by the Dynatrace Operator version you're upgrading to. If an entry is no longer served, you must first upgrade to an intermediate Operator version that still supports it so the stored resources can be converted and the obsolete entry removed.

v1beta1 and v1beta2 are a special exception: if the output contains either of them, only Dynatrace Operator 1.7.3 can convert these resources and remove the entries. No other version will fix it - see Upgrade steps.

DynaKube API version overview

Upgrade steps

What happens during the upgrade to 1.7.3

When you follow the steps above, the Dynatrace Operator takes care of two concerns automatically: