Try it free

Dynatrace Operator release notes version 1.11.0

  • Latest Dynatrace
  • Release notes

Release date: October 1, 2026

On this page, you'll find an overview of what's new and improved in Dynatrace Operator version 1.11.0.

Announcements

Dynatrace Operator now supports image volumes

Dynatrace Operator now supports image volume-based code modules injection, a more secure, storage-efficient, and reliable way to instrument application pods that replaces the CSI driver as the recommended approach. Using the native Kubernetes image volume feature, each worker node pulls the code modules image once and shares that single copy with every instrumented pod, requiring neither the dedicated DaemonSet of the CSI driver and its associated elevated privileges, nor a separate copy of the code modules image for every pod.

Switch your application pods to image volume-based injection. See migrate to image volumes for prerequisites and migration steps.

Auto-update for public registry images

Dynatrace Operator now supports automatic resolution and updates of container images for Dynatrace Kubernetes Node Configuration Collector, Dynatrace OTel Collector, and EdgeConnect, bringing the same seamless update experience to the full set of Dynatrace Operator managed components. This feature requires a newer Dynatrace SaaS version, currently planned for 1.352.

Supported public registries offer multi-arch images adhering to best practices for immutability and signing to strengthen supply chain security. For configuration details and prerequisites, see Use a public registry.

Expanding Kubernetes enrichment with workload and pod annotations and labels

In addition to namespace annotations and labels, the ingest enrichment configuration now supports workload and pod annotations and labels as sources for primary tags and Kubernetes tags. For more information including prerequisites, see Enrich Kubernetes telemetry with primary Grail fields and tags.

New features and enhancements

  • volumes and volumeMounts for the ActiveGate defined in the DynaKube are now user-configurable. For details, see Configure ActiveGate persistent volume.
  • The security context fields runAsUser and runAsGroup of the injected dynatrace-operator init container are now configurable. For details, see Configure init-container user and group identity.
  • The Dynatrace OTel Collector now propagates resource attributes defined in spec.resourceAttributes on the DynaKube to all metrics, traces, and logs.
  • Webhook certificate expiration, renewal, and how frequently Dynatrace Operator checks them are now configurable via .webhook.certs in Dynatrace Operator Helm chart.
  • The previously recommended split of two DynaKubes, one for Kubernetes monitoring and one for OneAgent routing and other features, addressed their differing resource profiles. That approach is now built directly into the DynaKube CRD itself. The new spec.kubernetesMonitoring section lets you size the two ActiveGate StatefulSets independently within a single DynaKube. Existing two-DynaKube setups keep working, and our migration guide walks you through switching to simplify long-term maintenance.
  • The support archive now includes node taint analysis to help diagnose scheduling issues where OneAgent or CSI driver pods are missing from nodes due to taint and toleration mismatches.

Resolved issues

  • Fixed an issue where the CSI driver cleanup could delete OneAgent code module binaries still in use by running pods. Without this fix, a container restart (for example, after an out-of-memory termination) could leave the application without its OneAgent files, so the application would no longer be monitored.
  • Fixed an issue where oversized metadata.dynatrace.com annotation values could cause the Kubernetes API to reject pods. Dynatrace Operator now enforces a default limit of 24Ki characters on these values unless configured otherwise.
  • Fixed an issue in the nodes controller where a OneAgent pod in a pending or unschedulable state could cause a missing IP address in DynaKube.status.oneagent.instances, which would trigger a retry loop when sending the mark-for-termination event.
  • Fixed an issue where the DynaKube status Tokens condition would list a missing scope multiple times instead of once.
  • Fixed an issue where the Dynatrace Operator init container - responsible for configuration and code module delivery to customer's applications - did not clean up previous code module ZIP download attempts when restarted due to too low resource limits. This only affects deployments using ephemeral storage (without CSI). Each restart left behind partially downloaded files, causing ephemeral storage to accumulate. Old download files are now removed before starting a fresh download.
  • Fixed an issue where the troubleshoot command returned a 401 error for DynaKubes using a customPullSecret. The command now checks all relevant pull secrets in the namespace instead of only one.
  • Fixed an issue where bootstrapper secrets could be replicated to an unauthorized namespace under specific conditions following a temporary service disruption.

Known issues

  • Since Dynatrace Operator 1.9.0, a RuntimeDefault seccomp profile is applied to the Dynatrace init container by default. On OpenShift, this can interfere with SecurityContextConstraints (SCCs) — such as anyuid, restricted, or nonroot — that prevent seccomp profile usage, causing the system to fall back to a different SCC (for example restricted-v2). This may render application pods unschedulable or cause workload degradation.

    Disable seccomp profile for Dynatrace init containers if you are affected.

Removal and deprecation notices

  • Removed DynaKube API version v1beta4: The v1beta4 version has been removed from the DynaKube CRD. Applying DynaKube resources that still use v1beta4 will fail. Migrate your DynaKube resources to v1beta6 before upgrading to this version. For details, see DynaKube API version migration.

    To prevent potential disruptions, we strongly advise keeping your DynaKube API version up to date. Once a version is deprecated and removed, updates may become significantly more complex.

  • The Helm repository located in dynatrace/helm-charts is archived and no longer receives updates. If you still install or upgrade Dynatrace Operator from it, switch to the OCI registry:

    helm upgrade dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
      --version <version> \
      --namespace dynatrace \
      --reset-then-reuse-values \
      --install

    If you can't use OCI, point your Helm repository to dynatrace/dynatrace-operator instead:

    helm repo remove dynatrace
    helm repo add dynatrace https://raw.githubusercontent.com/Dynatrace/dynatrace-operator/main/config/helm/repos/stable

    For details, see Migrate from the legacy Helm repository.

Upgrade Dynatrace Operator

Minimum operator version required for direct upgrade: 1.6.0

When upgrading, review the release notes and breaking changes section for each minor version between your current version and this version (1.11), not just this version itself. Skipping this step may cause you to miss a breaking change introduced in an intermediate release.

Direct upgrades from versions older than 1.6.0 are not supported. See Upgrade from older versions for further guidance.

Upgrade from Dynatrace Operator version 1.10

Important: In Dynatrace Operator version 1.11, the DynaKube API version v1beta4 is removed from the CRD. If any DynaKube resource in your cluster still uses v1beta4, applying it will fail after the upgrade, and depending on your current version, upgrading directly to 1.11 may not be possible until the migration is done. Before upgrading, update all DynaKube manifests to v1beta6. For details, see Migration guide for DynaKube API versions.