Depending ony our Dynatrace Operator Version, different apiVersion's of the DynaKube are supported. This page collects the migration guides for each apiVersion considering the version of the Operator.
| DynaKube API version | Introduced | Deprecated | Removed | Migration guides |
|---|---|---|---|---|
| v1beta5 | 1.6.0 | |||
| v1beta4 | 1.5.0 | to v1beta5 | ||
| v1beta3 | 1.3.0 | 1.6.0 | to v1beta5, to v1beta4 | |
| v1beta2 | 1.2.0 | 1.6.0 | 1.7.0 | to v1beta5, to v1beta4 |
| v1beta1 | 0.3.0 | 1.6.0 | 1.7.0 | to v1beta5, to v1beta4 |
Each version of the Dynatrace Operator converts the deployed DynaKubes with an older apiVersion to the latest apiVersion supported by that Dynatrace Operator version.
DynaKubes to v1beta5.So when you are checking, using kubectl what apiVersion you are using, you will always see the latest apiVersion that is supported by that Dynatrace Operator version. You can facilitate this mechanism instead of doing a manual conversion.
Download the converted version of your DynaKube. The following command will give you the DynaKube converted to the latest supported apiVersion:
kubectl get dynakubes -n <namespace> <dynakube-name> -o yaml
Cleanup the downloaded DynaKube, only keep this sections
.metadata section.spec sectionFirst, check the version of the Operator that is currently deployed. If you don't know which version you're running, here are some ways to find out.
Using Helm:
helm list command, the APP VERSION field tells you the version of the installed Dynatrace Operator.
> helm list -n dynatrace -o json | jq -r '.[].app_version'`1.6.2
Using kubectl:
app.kubernetes.io/version label on the Dynatrace Operator Deployment that shows the version used.
> kubectl get deployment dynatrace-operator -n dynatrace -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}'1.6.2
Then check the apiVersion of the DynaKube used and follow the matching migration guide in the overview above.
The Dynatrace Operator follows a structured deprecation process to ensure smooth transitions between DynaKube API versions while providing adequate time for migration.
Pre-deprecation notice: An announcement is made in the release notes at least one Dynatrace Operator release before the deprecation takes effect.
Deprecation marking: The API version is officially marked as deprecated in the subsequent release, but remains fully functional and supported.
Continued support: The deprecated API version continues to be fully supported and functional during the deprecation period.
Migration encouragement: Users are strongly encouraged to migrate to the newer API version during this time using the provided migration guides.
Automatic conversion: The Operator automatically converts deprecated API versions to the latest supported version in the background, ensuring compatibility.
API serving disabled: After the support period ends, the deprecated API version is marked as served: false in the Custom Resource Definition (CRD).
Conversion-only mode: The API version schema is retained in the CRD for conversion purposes only, allowing existing resources to be read and converted.
Migration deadline: Users must complete their migration to the newer API version before this phase to ensure continued functionality of their DynaKube resources.
Schema removal: The deprecated API version schema is completely removed from the CRD in a future Operator release.
No conversion support: After removal, no conversion or compatibility support is available for the deprecated API version.