Deploy Dynatrace OneAgent on Kubernetes with DynaKube (2026)

You can deploy Dynatrace OneAgent on Kubernetes using the DynaKube custom resource, which is the recommended and most flexible method.

Let’s see it in action. Imagine you have a Kubernetes cluster and you want to monitor a microservice deployed within it. Instead of manually installing the OneAgent on each pod, you’ll use DynaKube to declaratively define how the agent should be deployed and managed.

Here’s a typical DynaKube manifest:

apiVersion: dynatrace.com/v1beta1
kind: DynaKube
metadata:
  name: my-dynakube
  namespace: dynatrace
spec:
  # Your Dynatrace Environment ID
  dtEnvironmentId: "<your-environment-id>"
  # The Dynatrace API token with install environment permissions
  # It's recommended to use a Kubernetes secret for this.
  # Example: kubectl create secret generic dynatrace-api-token --from-literal=apiToken='<your-api-token>' -n dynatrace
  tokens: dynatrace-api-token
  # The Dynatrace Ingest API URL. Usually auto-detected, but can be specified.
  # apiURL: "https://{your-environment-id}.s1.dynalabs.io/api"
  # Enable Node Monitoring to deploy OneAgent on each Kubernetes node.
  # This is crucial for full visibility into your cluster infrastructure.
  nodeMonitoring:
    enabled: true
    # Specify the image for the OneAgent daemonset.
    # Use a specific version for predictability.
    image: "quay.io/dynatrace/oneagent:1.270.123.20240515-143202"
    # Resource requests and limits for the OneAgent daemonset pods.
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "500m"
  # Enable Application Monitoring to inject OneAgent into your application pods.
  # This allows Dynatrace to trace requests within your services.
  applicationMonitoring:
    enabled: true
    # Specify the image for the OneAgent injection webhook.
    # Use a specific version.
    webhookImage: "quay.io/dynatrace/oneagent-webhook:1.270.123.20240515-143202"
    # Resource requests and limits for the OneAgent webhook pods.
    resources:
      requests:
        memory: "128Mi"
        cpu: "50m"
      limits:
        memory: "256Mi"
        cpu: "200m"
  # Optional: Enable Istio integration if you are using Istio service mesh.
  # istio:
  #   enabled: true
  #   # Specify the Istio injection namespace if it's not the default.
  #   injectionNamespaces:
  #     - "default"
  #     - "staging"
  # Optional: Enable Kubernetes API monitoring.
  # kubernetesMonitoring:
  #   enabled: true
  #   # Specify the image for the Kubernetes API monitoring component.
  #   image: "quay.io/dynatrace/kubernetes-monitoring:1.270.123.20240515-143202"
  #   resources:
  #     requests:
  #       memory: "64Mi"
  #       cpu: "25m"
  #     limits:
  #       memory: "128Mi"
  #       cpu: "100m"

When you apply this DynaKube manifest using kubectl apply -f your-dynakube.yaml, the Dynatrace Operator, which you would have installed previously, reads this configuration. It then orchestrates the deployment of several Kubernetes resources:

• DaemonSet for Node Monitoring: If nodeMonitoring.enabled is true, the operator creates a DaemonSet. This ensures that a OneAgent pod runs on every node in your Kubernetes cluster. This pod has host-level privileges and monitors all processes and network traffic on that node.
• Deployment for Admission Controller (Webhook): If applicationMonitoring.enabled is true, the operator deploys a Kubernetes validating admission controller. This controller intercepts pod creation requests. When a pod is about to be created in a monitored namespace, the webhook injects the OneAgent into the pod’s environment (e.g., by adding environment variables or mounting volumes), enabling automatic instrumentation.
• Deployment for Kubernetes API Monitoring: If kubernetesMonitoring.enabled is true, a separate component is deployed to collect Kubernetes API metrics, events, and metadata.

The DynaKube resource acts as a single source of truth for your Dynatrace OneAgent deployment. You declare your desired state, and the operator ensures that Kubernetes conforms to it. This means you can update the agent version, change resource limits, or enable/disable features simply by modifying the DynaKube manifest and reapplying it. The operator handles the rollout and reconciliation.

What problem does this solve? Traditionally, deploying monitoring agents across a dynamic and ephemeral environment like Kubernetes was a chore. You’d need to manage DaemonSets, ConfigMaps, and potentially complex init containers or sidecars. The DynaKube approach abstracts all of this complexity. It leverages Kubernetes-native concepts like Custom Resource Definitions (CRDs) and operators to provide a declarative, automated, and robust deployment mechanism. It ensures that your monitoring is always up-to-date and correctly configured without manual intervention.

The most surprising thing most people don’t realize is that the DynaKube resource itself doesn’t deploy the agent. It instructs the Dynatrace Operator, which is a separate Kubernetes deployment, on how to deploy and manage the agent. The operator acts as the brain, constantly watching the DynaKube resource and comparing its spec to the actual state of the cluster, making adjustments as needed.

The next logical step is to explore how to manage specific OneAgent features, like network zone configurations or custom process group detection, directly through the DynaKube resource.