Deploy Dynatrace Operator to gain complete visibility into your Kubernetes environment–from cluster health and resource usage to application performance and infrastructure details.
With Kubernetes platform monitoring + Full-Stack observability deployed, you can use the
Kubernetes to:
You can further expand your Kubernetes observability on Digital Experience and Application Security.
This tutorial is intended for platform engineers, site reliability engineers (SREs), and Kubernetes administrators.
By the end of this tutorial, you'll have full-stack observability across your Kubernetes cluster. Along the way, you'll:
Before installing Dynatrace on your Kubernetes cluster, ensure that you meet the following requirements:
kubectl CLI is connected to the Kubernetes cluster that you want to monitor.kubectl or oc commands.You must allow egress for Dynatrace pods (default: Dynatrace namespace) to your Dynatrace environment URL.
For OpenShift Dedicated, you need the cluster-admin role.
Helm installation Use Helm version 3.
See supported Kubernetes/OpenShift platform versions and distributions.
If you're deploying to OpenShift, configure SCC before proceeding–it's required for cloudNativeFullStack deployments with the CSI driver.
By default, Dynatrace Operator injects OneAgent in all namespaces, but you can configure it to monitor only specific namespaces and exclude others. For details, see Configure monitoring for namespaces and pods.
Kubernetes platform monitoring + Full-Stack observability requires Dynatrace Platform Subscription (DPS) and is licensed by the sum of host memory (GiB-hours).
Select the installation method that works best for you: Helm or manifest.
Dynatrace Operator version 0.8.0+
These instructions use Dynatrace's Helm chart from an OCI registry. If you have the Dynatrace repository in your local Helm repositories, you can remove it before proceeding:
helm repo remove dynatrace
Install Dynatrace Operator
The following command works for installations using an OCI registry, which is the default way. If you're using Helm version 4.0+, replace --atomic with --rollback-on-failure.
helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \--create-namespace \--namespace dynatrace \--atomic
Edit the values.yaml sample from GitHub, and then run the install command, passing the YAML file as an argument:
helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \--create-namespace \--namespace dynatrace \--atomic \-f values.yaml
If installCRD is set to false, you need to create the custom resource definition manually before starting the Helm installation:
kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/dynatrace-operator-crd.yaml
VMware Tanzu Kubernetes (TKGI) and IBM Kubernetes Service (IKS) require additional configuration.
Create a secret named dynakube for the Dynatrace Operator token and data ingest token obtained in Tokens and permissions required.
kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>" --from-literal="dataIngestToken=<DATA_INGEST_TOKEN>"
Create your DynaKube custom resource YAML file.
You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.
For PPC64le architecture, additional configuration is required. For details, see ActiveGate container image.
apiVersion: dynatrace.com/v1beta5kind: DynaKubemetadata:name: dynakubenamespace: dynatraceannotations:feature.dynatrace.com/k8s-app-enabled: "true"feature.dynatrace.com/injection-readonly-volume: "true"spec:# For detailed instructions on DynaKube parameters in the spec section, visit https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parameters# Dynatrace apiUrl including the /api path at the end.# Replace 'ENVIRONMENTID' with your environment ID.# For instructions on how to determine the environment ID and how to configure the apiUrl address, see https://www.dynatrace.com/support/help/reference/dynatrace-concepts/environment-id/.apiUrl: https://ENVIRONMENTID.live.dynatrace.com/apimetadataEnrichment:enabled: trueoneAgent:cloudNativeFullStack:tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/masteroperator: Exists- effect: NoSchedulekey: node-role.kubernetes.io/control-planeoperator: ExistsactiveGate:capabilities:- routing- kubernetes-monitoringresources:requests:cpu: 500mmemory: 512Milimits:cpu: 1000mmemory: 1.5Gi
Optional Monitor potentially sensitive data
To monitor potentially sensitive data such as Secrets (values are masked before ingest) and ConfigMaps, you need to create a ClusterRole that allows access to these resources. Add the following snippet at the end of your DynaKube custom resource YAML file.
---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:labels:rbac.dynatrace.com/aggregate-to-monitoring: "true"name: dynatrace-kubernetes-monitoring-sensitiverules:- apiGroups:- ""resources:- configmaps- secretsverbs:- list- watch- get
In Dynatrace Operator version 1.8.x, the role is automatically bound to the dynatrace-kubernetes-monitoring ClusterRole via aggregation rules. For more information, see ClusterRole aggregation documentation. Starting with Dynatrace Operator version 1.9.0, aggregated ClusterRoles are no longer used. Create a ClusterRoleBinding to bind this ClusterRole to the dynatrace-activegate service account directly.
Apply the DynaKube custom resource
Run the command below to apply the DynaKube custom resource, making sure to replace <your-DynaKube-CR> with your actual DynaKube custom resource file name. A validation webhook will provide helpful error messages if there's a problem.
kubectl apply -f <your-DynaKube-CR>.yaml
Optional Verify deployment
Verify that your DynaKube is running and all pods in your Dynatrace namespace are running and ready.
> kubectl get dynakube -n dynatraceNAME APIURL STATUS AGEdynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s
In a default DynaKube configuration, you should see the following pods:
> kubectl get pods -n dynatraceNAME READY STATUS RESTARTS AGEdynakube-activegate-0 1/1 Running 0 50sdynakube-oneagent-b88rn 1/1 Running 0 50sdynakube-oneagent-m5jm4 1/1 Running 0 50sdynakube-oneagent-qhd9u 1/1 Running 0 50sdynatrace-oneagent-csi-driver-qxfwx 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-xk5c4 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-mz6ch 4/4 Running 0 2m49sdynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s
Because OneAgent and the CSI driver are deployed as a DaemonSet, you should have a OneAgent and CSI driver pod on each node.
Create a dynatrace namespace
kubectl create namespace dynatrace
Install Dynatrace Operator
kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/kubernetes-csi.yaml
VMware Tanzu Kubernetes (TKGI) and IBM Kubernetes Service (IKS) require additional configuration.
Run the following command to see when Dynatrace Operator components finish initialization:
kubectl -n dynatrace wait pod --for=condition=ready --selector=app.kubernetes.io/name=dynatrace-operator,app.kubernetes.io/component=webhook --timeout=300s
Create a secret named dynakube for the Dynatrace Operator token and data ingest token obtained in Tokens and permissions required.
kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>" --from-literal="dataIngestToken=<DATA_INGEST_TOKEN>"
Create your DynaKube custom resource YAML file.
You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.
apiVersion: dynatrace.com/v1beta5kind: DynaKubemetadata:name: dynakubenamespace: dynatraceannotations:feature.dynatrace.com/k8s-app-enabled: "true"feature.dynatrace.com/injection-readonly-volume: "true"spec:# For detailed instructions on DynaKube parameters in the spec section, visit https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parameters# Dynatrace apiUrl including the /api path at the end.# Replace 'ENVIRONMENTID' with your environment ID.# For instructions on how to determine the environment ID and how to configure the apiUrl address, see https://www.dynatrace.com/support/help/reference/dynatrace-concepts/environment-id/.apiUrl: https://ENVIRONMENTID.live.dynatrace.com/apimetadataEnrichment:enabled: trueoneAgent:cloudNativeFullStack:tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/masteroperator: Exists- effect: NoSchedulekey: node-role.kubernetes.io/control-planeoperator: ExistsactiveGate:capabilities:- routing- kubernetes-monitoringresources:requests:cpu: 500mmemory: 512Milimits:cpu: 1000mmemory: 1.5Gi
Optional Monitor potentially sensitive data
To monitor potentially sensitive data such as Secrets (values are masked before ingest) and ConfigMaps, you need to create a ClusterRole that allows access to these resources. Add the following snippet at the end of your DynaKube custom resource YAML file.
---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:labels:rbac.dynatrace.com/aggregate-to-monitoring: "true"name: dynatrace-kubernetes-monitoring-sensitiverules:- apiGroups:- ""resources:- configmaps- secretsverbs:- list- watch- get
In Dynatrace Operator version 1.8.x, the role is automatically bound to the dynatrace-kubernetes-monitoring ClusterRole via aggregation rules. For more information, see ClusterRole aggregation documentation. Starting with Dynatrace Operator version 1.9.0, aggregated ClusterRoles are no longer used. Create a ClusterRoleBinding to bind this ClusterRole to the dynatrace-activegate service account directly.
Run the command below to apply the DynaKube custom resource, making sure to replace <your-DynaKube-CR> with your actual DynaKube custom resource file name. A validation webhook will provide helpful error messages if there's a problem.
Apply the DynaKube custom resource
kubectl apply -f <your-DynaKube-CR>.yaml
Optional Verify deployment
Verify that your DynaKube is running and all pods in your Dynatrace namespace are running and ready.
> kubectl get dynakube -n dynatraceNAME APIURL STATUS AGEdynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s
In a default DynaKube configuration, you should see the following pods:
> kubectl get pods -n dynatraceNAME READY STATUS RESTARTS AGEdynakube-activegate-0 1/1 Running 0 50sdynakube-oneagent-b88rn 1/1 Running 0 50sdynakube-oneagent-m5jm4 1/1 Running 0 50sdynakube-oneagent-qhd9u 1/1 Running 0 50sdynatrace-oneagent-csi-driver-qxfwx 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-xk5c4 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-mz6ch 4/4 Running 0 2m49sdynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s
Because OneAgent and the CSI driver are deployed as a DaemonSet, you should have a OneAgent and CSI driver pod on each node.
Add a dynatrace project
oc adm new-project --node-selector="" dynatrace
Install Dynatrace Operator
oc apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/openshift-csi.yaml
Run the following command to see when Dynatrace Operator components finish initialization:
oc -n dynatrace wait pod --for=condition=ready --selector=app.kubernetes.io/name=dynatrace-operator,app.kubernetes.io/component=webhook --timeout=300s
Create a secret named dynakube for the Dynatrace Operator token and data ingest token obtained in Tokens and permissions required.
oc -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>" --from-literal="dataIngestToken=<DATA_INGEST_TOKEN>"
Create your DynaKube custom resource YAML file.
You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.
apiVersion: dynatrace.com/v1beta5kind: DynaKubemetadata:name: dynakubenamespace: dynatraceannotations:feature.dynatrace.com/k8s-app-enabled: "true"feature.dynatrace.com/injection-readonly-volume: "true"spec:# For detailed instructions on DynaKube parameters in the spec section, visit https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parameters# Dynatrace apiUrl including the /api path at the end.# Replace 'ENVIRONMENTID' with your environment ID.# For instructions on how to determine the environment ID and how to configure the apiUrl address, see https://www.dynatrace.com/support/help/reference/dynatrace-concepts/environment-id/.apiUrl: https://ENVIRONMENTID.live.dynatrace.com/apimetadataEnrichment:enabled: trueoneAgent:cloudNativeFullStack:tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/masteroperator: Exists- effect: NoSchedulekey: node-role.kubernetes.io/control-planeoperator: ExistsactiveGate:capabilities:- routing- kubernetes-monitoringresources:requests:cpu: 500mmemory: 512Milimits:cpu: 1000mmemory: 1.5Gi
Optional Monitor potentially sensitive data
To monitor potentially sensitive data such as Secrets (values are masked before ingest) and ConfigMaps, you need to create a ClusterRole that allows access to these resources. Add the following snippet at the end of your DynaKube custom resource YAML file.
---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:labels:rbac.dynatrace.com/aggregate-to-monitoring: "true"name: dynatrace-kubernetes-monitoring-sensitiverules:- apiGroups:- ""resources:- configmaps- secretsverbs:- list- watch- get
In Dynatrace Operator version 1.8.x, the role is automatically bound to the dynatrace-kubernetes-monitoring ClusterRole via aggregation rules. For more information, see ClusterRole aggregation documentation. Starting with Dynatrace Operator version 1.9.0, aggregated ClusterRoles are no longer used. Create a ClusterRoleBinding to bind this ClusterRole to the dynatrace-activegate service account directly.
Run the command below to apply the DynaKube custom resource, making sure to replace <your-DynaKube-CR> with your actual DynaKube custom resource file name. A validation webhook will provide helpful error messages if there's a problem.
Apply the DynaKube custom resource
oc apply -f <your-DynaKube-CR>.yaml
Optional Verify deployment
Verify that your DynaKube is running and all pods in your Dynatrace namespace are running and ready.
> oc get dynakube -n dynatraceNAME APIURL STATUS AGEdynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s
In a default DynaKube configuration, you should see the following pods:
> oc get pods -n dynatraceNAME READY STATUS RESTARTS AGEdynakube-activegate-0 1/1 Running 0 50sdynakube-oneagent-b88rn 1/1 Running 0 50sdynakube-oneagent-m5jm4 1/1 Running 0 50sdynakube-oneagent-qhd9u 1/1 Running 0 50sdynatrace-oneagent-csi-driver-qxfwx 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-xk5c4 4/4 Running 0 2m49sdynatrace-oneagent-csi-driver-mz6ch 4/4 Running 0 2m49sdynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59sdynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s
Because OneAgent and the CSI driver are deployed as a DaemonSet, you should have a OneAgent and CSI driver pod on each node.
You've achieved full-stack observability for your Kubernetes cluster! In this tutorial, you:
Monitor and optimize Kubernetes with Dynatrace. Get real-time insights and health for clusters and workloads.
Detailed description of installation and configuration options for specific use-cases
This page will assist you in navigating any challenges you may encounter while working with the Dynatrace Operator and its various components.
In-depth description on how the deployment on Kubernetes works.
Contains a reference page with configuration options for each Dynatrace component
Release notes for Dynatrace Operator
Upgrade and uninstallation procedures for Dynatrace Operator
Set resource limits for Dynatrace ActiveGates