Configure node image pull

  • 6min
  • Published Apr 08, 2025

Dynatrace Operator version 1.5.0

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:

  • Application monitoring works in combination with the public signed images
  • applicationMonitoring Combination of non-CSI and CSI-based Dynatrace code module injection (for details, see Enforce CSI-less application monitoring)
    • 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

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 requirements for more information.

Prerequisites

When using a private registry, your nodes must be authenticated to the registry, or you must use the customPullSecret field.

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

The option without CSI driver is currently only supported in application monitoring mode. 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.

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.
  • applicationMonitoring Without CSI driver - 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.

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>

Please use Dynatrace code modules version 1.311.72 or newer. Example:

public.ecr.aws/dynatrace/dynatrace-codemodules:1.311.72.20250423-112851

For more details on repositories and tag information, explore our supported public registries.

Enforce CSI-less application monitoring

applicationMonitoring

Known issue

Due to a known issue, please refrain from using the feature flag oneagent.dynatrace.com/technologies. See Dynatrace Operator version 1.5.1 release notes for details.

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