Configure node image pull

  • 6-min read
  • Published Apr 08, 2025

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

    • Cloud-native full-stack monitoring can be deployed via OpenShift OperatorHub

  • 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

    • for mixed setups with/without node access like AWS Elastic Kubernetes Service with EC2 nodes and Fargate
    • for leveraging the benefits of the CSI driver, with specific exceptions for NGINX instrumentation
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.

Prerequisites

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.

Limitations

Note that the following configurations are not supported:

  • Due to GKE Autopilot's dynamic provisioning of nodes and their sizes based on the aggregated resource requests of Pods to optimize resource utilization, GKE Autopilot is not suitable for the node image pull feature in combination with the CSI driver.
    • We recommend using the feature without the CSI driver on GKE Autopilot systems or, alternatively, using the CSI driver in a standard setup with node image pull disabled.

Behavior and configuration

Known issue in Dynatrace Operator version 1.5

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.

1

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.

DynaKube configuration

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/v1beta4
kind: DynaKube
metadata:
  name: dynakube
  annotations:
    feature.dynatrace.com/node-image-pull: "true"
spec:
  oneAgent:
    # example, can also be used with `applicationMonitoring`
    cloudNativeFullStack:
      codeModulesImage: <dynatrace-codemodules-image>
Known issue

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.

Storage optimization without CSI driver

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.

Technology identifiers

Here is a list of the identifiers you can use per technology:

TechnologyIdentifier
Javajava
.NET, .NET Core and .NET Frameworkdotnet
Node.jsnodejs
Pythonpython
PHPphp
Gogo
Apache, IBM HTTP Serverapache
NGINXnginx

Annotate the application pod

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/v1beta4
kind: DynaKube
metadata:
  name: dynakube
  annotations:
    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.

Enforce CSI-less application monitoring

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:

  • NGINX instrumentation and prior injection are recommended without the CSI driver for higher resiliency, while other workloads can be injected using the CSI driver, thus eliminating the need for any vendor-specific annotations.
  • Mixed setups with and without node access, such as AWS Elastic Kubernetes Service (EKS) with EC2 nodes and Fargate, can be accommodated. Ensure the CSI driver is available on all nodes where code module injection based on CSI driver might occur.

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 involved
    oneagent.dynatrace.com/technologies: "nginx"    # minimize storage consumption