Migrate from OneAgent Operator to Dynatrace Operator
Understand and configure the DynaKube custom resource
The DynaKube custom resource (CR) replaces the OneAgent custom resource. The DynaKube CR follows the "don't repeat yourself" (DRY) principle to deploy a number of different components to your Kubernetes cluster.
Each section includes an illustration of the differences between the two custom resources, what changes from the old custom resource to the new one (marked with green), and what stays the same in both custom resource (marked with blue).
Changing operators will change the host ID calculations for monitored hosts, which will lead to monitoring anomalies in the Dynatrace UI.
Classic full-stack migration
Follow the instructions below to migrate from OneAgent Operator to Dynatrace Operator for classic full-stack injection.
Application-only migration
Follow the instructions below to migrate from OneAgent Operator to Dynatrace Operator for automatic application-only injection.
ActiveGate migration
As of OneAgent version 1.231, containerized ActiveGates can run multiple capabilities in the same container. The ActiveGate migration works automatically, but to take advantage of this functionality you have to make some changes manually.
Basic functionality
The DynaKube API v1alpha1 is automatically migrated to DynaKube API v1beta1:
This way you get two pods with a single capability each.
Full functionality
After migration, you need to make the following conversion in the DynaKube custom resource manually:
This way you get multiple capabilities in the same pod.
Migrate from OneAgent Operator to Dynatrace Operator
You can migrate from the deprecated OneAgent Operator to the new Dynatrace Operator that manages the lifecycle of several Dynatrace components such as OneAgent, routing, and Kubernetes API Monitor. Additional components will be added as new observability features become available.
Select one of the following options, depending on your deployment methods.