Get started with Kubernetes platform monitoring

  • Latest Dynatrace
  • 7-min read

Deploy Dynatrace Operator to gain visibility into your Kubernetes cluster–from cluster and workload health to resource optimization, anomaly alerts, and events.

Explore use cases

With Kubernetes platform monitoring deployed, you can use the Kubernetes (new) Kubernetes to:

If you’re looking to gain deeper insights into your Kubernetes environment, check out the deployment overview to learn about Application observability and Full-Stack observability. You can further expand your Kubernetes observability on Log Analytics, Digital Experience, and Application Security.

Who is this for?

This tutorial is intended for platform engineers, site reliability engineers (SREs), and Kubernetes administrators.

What will you learn?

By the end of this tutorial, you'll have Dynatrace monitoring your Kubernetes cluster. Along the way, you'll:

  • Install Dynatrace Operator via Helm or manifest.
  • Configure the DynaKube custom resource.
  • Verify your deployment.

Before you begin

Before installing Dynatrace on your Kubernetes cluster, ensure that you meet the following requirements:

  • Your kubectl CLI is connected to the Kubernetes cluster that you want to monitor.
  • You have sufficient privileges on the monitored cluster to run kubectl or oc commands.

Cluster setup and configuration

  • 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.

Supported versions

See supported Kubernetes/OpenShift platform versions and distributions.

Licensing

Kubernetes platform monitoring requires Dynatrace Platform Subscription (DPS) and is licensed by number of pods per hour (pod-hours).

Get started with Kubernetes platform monitoring

Select the installation method that works best for you: Helm or manifest.

Install with Helm Helm

Dynatrace Operator version 0.8.0+

Kubernetes
  1. Install Dynatrace Operator

    The following command works for both default installations and installations using an OCI registry. If you're using Helm 4.0+, replace --atomic with --rollback-on-failure.

    helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
    --set "csidriver.enabled=false" \
    --create-namespace \
    --namespace dynatrace \
    --atomic

    When upgrading your Kubernetes observability setup to include application monitoring, we recommend that you install Dynatrace Operator CSI driver for improved efficiency. If you plan to expand towards cloud-native full-stack mode, installation of the CSI driver becomes mandatory.

    Installation with additional configuration of the Helm chart

    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
  2. Create a secret named dynakube for the Dynatrace Operator token obtained in Tokens and permissions required.

    kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"
  3. Create your DynaKube custom resource file.

    DynaKube custom resource sample for Kubernetes platform monitoring

    You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.

    apiVersion: dynatrace.com/v1beta5
    kind: DynaKube
    metadata:
    name: dynakube
    namespace: dynatrace
    annotations:
    feature.dynatrace.com/k8s-app-enabled: "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/api
    metadataEnrichment:
    enabled: true
    activeGate:
    capabilities:
    - kubernetes-monitoring
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1.5Gi
  4. 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.

    Installation with sensitive data monitoring
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    labels:
    rbac.dynatrace.com/aggregate-to-monitoring: "true"
    name: dynatrace-kubernetes-monitoring-sensitive
    rules:
    - apiGroups:
    - ""
    resources:
    - configmaps
    - secrets
    verbs:
    - 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.

  5. Apply the DynaKube custom resource

    kubectl apply -f <your-DynaKube-CR>.yaml
  6. Optional Verify deployment

    Verify that your DynaKube is running and all Pods in your Dynatrace namespace are running and ready.

    > kubectl get dynakube -n dynatrace
    NAME APIURL STATUS AGE
    dynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s

    In this DynaKube configuration, you should see the following Pods:

    > kubectl get pods -n dynatrace
    NAME READY STATUS RESTARTS AGE
    dynakube-activegate-0 1/1 Running 0 50s
    dynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s
OpenShift
  1. Install Dynatrace Operator

    The following command works for both default installations and installations using an OCI registry. If you're using Helm 4.0+, replace --atomic with --rollback-on-failure.

    helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
    --set "csidriver.enabled=false" \
    --create-namespace \
    --namespace dynatrace \
    --atomic \
    Installation with additional configuration of the Helm chart

    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:

    oc apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/dynatrace-operator-crd.yaml
  2. Create a secret named dynakube for the Dynatrace Operator token obtained in Tokens and permissions required.

    oc -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"
  3. Create your DynaKube custom resource file.

    DynaKube custom resource sample for Kubernetes platform monitoring

    You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.

    apiVersion: dynatrace.com/v1beta5
    kind: DynaKube
    metadata:
    name: dynakube
    namespace: dynatrace
    annotations:
    feature.dynatrace.com/k8s-app-enabled: "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/api
    metadataEnrichment:
    enabled: true
    activeGate:
    capabilities:
    - kubernetes-monitoring
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1.5Gi
  4. 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.

    Installation with sensitive data monitoring
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    labels:
    rbac.dynatrace.com/aggregate-to-monitoring: "true"
    name: dynatrace-kubernetes-monitoring-sensitive
    rules:
    - apiGroups:
    - ""
    resources:
    - configmaps
    - secrets
    verbs:
    - 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.

  5. Apply the DynaKube custom resource

    oc apply -f <your-DynaKube-CR>.yaml
  6. Optional Verify deployment

    Verify that your DynaKube is running and all Pods in your Dynatrace namespace are running and ready.

    > oc get dynakube -n dynatrace
    NAME APIURL STATUS AGE
    dynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s

    In this DynaKube configuration, you should see the following Pods:

    > oc get pods -n dynatrace
    NAME READY STATUS RESTARTS AGE
    dynakube-activegate-0 1/1 Running 0 50s
    dynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s

Install with manifest

Kubernetes
  1. Create a dynatrace namespace

    kubectl create namespace dynatrace
  2. Install Dynatrace Operator

    kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/kubernetes.yaml

    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
  3. Create a secret named dynakube for the Dynatrace Operator token obtained in Tokens and permissions required.

    kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"
  4. Create your DynaKube custom resource file.

    DynaKube custom resource sample for Kubernetes platform monitoring

    You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.

    apiVersion: dynatrace.com/v1beta5
    kind: DynaKube
    metadata:
    name: dynakube
    namespace: dynatrace
    annotations:
    feature.dynatrace.com/k8s-app-enabled: "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/api
    metadataEnrichment:
    enabled: true
    activeGate:
    capabilities:
    - kubernetes-monitoring
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1.5Gi
  5. 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.

    Installation with sensitive data monitoring
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    labels:
    rbac.dynatrace.com/aggregate-to-monitoring: "true"
    name: dynatrace-kubernetes-monitoring-sensitive
    rules:
    - apiGroups:
    - ""
    resources:
    - configmaps
    - secrets
    verbs:
    - 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.

  6. Apply the DynaKube custom resource

    kubectl apply -f <your-DynaKube-CR>.yaml
  7. Optional Verify deployment

    Verify that your DynaKube is running and all Pods in your Dynatrace namespace are running and ready.

    > kubectl get dynakube -n dynatrace
    NAME APIURL STATUS AGE
    dynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s

    In this DynaKube configuration, you should see the following Pods:

    > kubectl get pods -n dynatrace
    NAME READY STATUS RESTARTS AGE
    dynakube-activegate-0 1/1 Running 0 50s
    dynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s
OpenShift
  1. Add a dynatrace project

    oc adm new-project --node-selector="" dynatrace
  2. Install Dynatrace Operator

    oc apply -f https://github.com/Dynatrace/dynatrace-operator/releases/download/v1.9.0/openshift.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
  3. Create a secret named dynakube for the Dynatrace Operator token obtained in Tokens and permissions required.

    oc -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"
  4. Create your DynaKube custom resource file.

    DynaKube custom resource sample for Kubernetes platform monitoring

    You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.

    apiVersion: dynatrace.com/v1beta5
    kind: DynaKube
    metadata:
    name: dynakube
    namespace: dynatrace
    annotations:
    feature.dynatrace.com/k8s-app-enabled: "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/api
    metadataEnrichment:
    enabled: true
    activeGate:
    capabilities:
    - kubernetes-monitoring
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1.5Gi
  5. 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.

    Installation with sensitive data monitoring
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    labels:
    rbac.dynatrace.com/aggregate-to-monitoring: "true"
    name: dynatrace-kubernetes-monitoring-sensitive
    rules:
    - apiGroups:
    - ""
    resources:
    - configmaps
    - secrets
    verbs:
    - 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.

  6. Apply the DynaKube custom resource

    oc apply -f <your-DynaKube-CR>.yaml
  7. Optional Verify deployment

    Verify that your DynaKube is running and all Pods in your Dynatrace namespace are running and ready.

    > oc get dynakube -n dynatrace
    NAME APIURL STATUS AGE
    dynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s

    In this DynaKube configuration, you should see the following Pods:

    > oc get pods -n dynatrace
    NAME READY STATUS RESTARTS AGE
    dynakube-activegate-0 1/1 Running 0 50s
    dynatrace-operator-7dc8dc7d8c-wmh4z 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-l8fsq 1/1 Running 0 2m59s
    dynatrace-webhook-7bb6957fb5-rqnqk 1/1 Running 0 2m59s

Congratulations!

You've successfully deployed Dynatrace Operator for Kubernetes platform monitoring. In this tutorial, you:

  • Installed Dynatrace Operator on your cluster.
  • Configured and applied a DynaKube custom resource.

Next steps