Dynatrace Operator version 1.5
cloudNativeFullStack applicationMonitoring
The node image pull feature introduces new capabilities for image pulling of the Dynatrace code modules image, along with enhanced performance and security in the Dynatrace Operator. These enhancements enable the following improvements and use-cases:
Cloud-native full-stack monitoring works independently of the CSI driver 1
Application monitoring works in combination with the public signed images
Combination of non-CSI and CSI-based Dynatrace code module injection (for details, see Enforce CSI-less application monitoring) 1
Deployments using the cloud-native full-stack mode require Dynatrace Operator version 1.6+ and OneAgent version 1.317+.
With the node image pull feature enabled, Kubernetes-native integration into supply chain security tooling is greatly simplified. Additionally, the feature configures the operator to always pull images via the Kubernetes nodes, reducing the need for a customPullSecret
when sourcing images from private registries.
Dynatrace Operator deployments that do not utilize the CSI driver have increased storage requirements due to current Kubernetes concepts. Please refer to Storage optimization without CSI driver to learn how to minimize storage consumption.
When using a private registry, you must ensure that all nodes are authenticated to access the registry. Alternatively, you can specify a customPullSecret
to provide the necessary credentials for image pulls.
Note that the following configurations are not supported:
We have identified an issue with cloud-native full-stack without using the CSI driver with details provided in the Dynatrace Operator version 1.5.1 release notes.
This issue has been resolved with Dynatrace Operator version 1.6.0 and OneAgent version 1.317+.
The feature is activated via a feature flag on DynaKube. The following two points outline the behavior and benefits of the feature based on whether the CSI driver has been deployed as part of the operator:
With CSI driver - Instead of downloading the code modules into the CSI driver pod, Dynatrace code modules images are directly pulled through the node. Each CSI driver pod creates a job for the node to download the code modules to the host filesystem, where they will be used by the CSI driver as usual. This approach reduces the need for a customPullSecret
when sourcing images from private registries.
Without CSI driver 1 - If the CSI driver is not installed in your cluster, you can leverage the node image pull feature with the code modules image to improve injection performance and resiliency. This approach prioritizes injection performance for a faster and more resilient injection over storage optimizations enabled by the CSI driver.
Deployments using the cloud-native full-stack mode require Dynatrace Operator version 1.6+ and OneAgent version 1.317+.
Please refer to Storage optimization without CSI driver to learn how to minimize storage consumption.
Refer to the following DynaKube snippet for configuring the feature flag and specifying a Dynatrace code modules image from a supported public or private registry:
apiVersion: dynatrace.com/v1beta4kind: DynaKubemetadata:name: dynakubeannotations:feature.dynatrace.com/node-image-pull: "true"spec:oneAgent:# example, can also be used with `applicationMonitoring`cloudNativeFullStack:codeModulesImage: <dynatrace-codemodules-image>
There is a known issue with OneAgent versions >= 1.313.0 to < 1.313.45. Please use Dynatrace code modules version 1.313.45+.
Example image tag for codeModulesImage
field:
public.ecr.aws/dynatrace/dynatrace-codemodules:1.313.45.20250521-164818
For more details on repositories and tag information, explore our supported public registries.
OneAgent version 1.315+
Without the CSI driver, code module injection consumes ephemeral storage for each injection. To minimize storage consumption, you can either annotate individual application pods or configure this setting at the DynaKube level, as appropriate. These annotations should specify the application technology (e.g., Java), allowing precise control over code module injection into application containers and preventing unnecessary code module binaries from being copied.
If storage optimization is not configured (i.e., the oneagent.dynatrace.com/technologies
annotation is missing), storage consumption will follow the guidelines outlined in the storage requirements.
Each configured technology, whether specified individually or as a comma-separated list, will be copied into a shared volume, consuming ephemeral storage.
Here is a list of the identifiers you can use per technology:
To reduce the data copied into application pods, you can specify which OneAgent technologies are relevant for your application. Annotate your application pods as shown in the pod snippet below:
...metadata:annotations:oneagent.dynatrace.com/technologies: "java,nginx"
When specifying a comma-separated list of technology identifiers, ensure there are no whitespace characters within the annotation value.
Annotation values must use the exact technology identifiers listed in the table above.
If no oneagent.dynatrace.com/technologies
is provided, all technologies will be copied to application pods.
If a single technology is used across your cluster, or if you want to set a default technology for Dynatrace code module injection, you can configure it at the DynaKube level to apply to all injected application pods.
Modify your DynaKube configuration by enabling the feature and restricting it to a specific technology or a set of multiple technologies:
apiVersion: dynatrace.com/v1beta4kind: DynaKubemetadata:name: dynakubeannotations:feature.dynatrace.com/node-image-pull: "true"oneagent.dynatrace.com/technologies: "java"spec:...
When specifying a comma-separated list of technology identifiers, ensure there are no whitespace characters within the annotation value.
For more details on repositories and tag information, explore our supported public registries.
applicationMonitoring OneAgent version 1.315+
If the CSI driver is deployed, you can selectively configure Dynatrace code module injection without involving the CSI driver. This approach allows you to combine the best of both methods: the storage optimizations provided by the CSI driver and the performance gains and enhanced resiliency of injection without the CSI driver.
Example scenarios:
The following pod snippet outlines how to selectively configure code module injection without involving the CSI driver by specifying the volume type to use:
metadata:annotations:oneagent.dynatrace.com/volume-type: "ephemeral" # no CSI driver involvedoneagent.dynatrace.com/technologies: "nginx" # minimize storage consumption