PerfMonitoring
Home / Tutorials / How to Monitor Kubernetes with Dynatrace
Tutorial · Dynatrace

How to Monitor Kubernetes with Dynatrace

Connect Kubernetes to Dynatrace with the current Operator workflow, choose observability options, verify workloads, and troubleshoot RBAC or connectivity.

By PerfMonitoring · Published September 10, 2026 · Last verified September 10, 2026 · Editorial Policy

Last verified: September 10, 2026
By: PerfMonitoring

Dynatrace's current Kubernetes onboarding uses the Dynatrace Operator and a generated DynaKube configuration. For a new cluster in Latest Dynatrace, the official quickstart directs you to the Kubernetes app, where you select the distribution and observability options, generate tokens, download dynakube.yaml, and execute the installation commands provided for that cluster. [1]

That generated workflow matters because Dynatrace Kubernetes deployment details are actively evolving. Documentation updated in September 2026 already reflects Operator permission changes that differ from older tutorials. This guide therefore does not publish a static token Secret, hard-coded Operator version, or hand-built RBAC manifest as the default. It teaches the durable workflow and verification steps instead. [2]

What You'll Accomplish

You will:

  1. verify Kubernetes and Dynatrace prerequisites;
  2. choose the observability options that match the cluster's purpose;
  3. generate a current DynaKube configuration and Operator token securely;
  4. execute Dynatrace's generated installation commands;
  5. verify the DynaKube and Dynatrace pods from Kubernetes;
  6. confirm that the cluster is connected in Dynatrace; and
  7. troubleshoot Operator, RBAC, registry, token, and egress failures.

Prerequisites

Dynatrace's current Kubernetes quickstart requires:

  • kubectl connected to the cluster you want to monitor;
  • sufficient Kubernetes privileges to run the required commands;
  • egress from Dynatrace pods in the monitoring namespace to your Dynatrace environment URL;
  • a supported Kubernetes/OpenShift version and distribution; and
  • Helm 3 when you use the Helm installation path. [1]

The new Kubernetes experience in Latest Dynatrace also has platform/licensing/permission requirements. Current documentation lists a Dynatrace SaaS environment powered by Grail and AppEngine, the Kubernetes Platform Monitoring capability under DPS, appropriate application permissions, and a sufficiently current ActiveGate. [3]

If your environment does not meet those requirements, Dynatrace continues to expose Kubernetes Classic paths. Do not write a runbook that assumes every Dynatrace tenant has the same Kubernetes UI. [3]

Quick Answer

In Latest Dynatrace, open Kubernetes, select Add cluster, choose the distribution and observability options, enter a cluster name, generate the Operator token, and download the generated dynakube.yaml. Protect that file because it includes a Kubernetes Secret with generated tokens. Run the install commands Dynatrace provides, then verify kubectl get dynakubes -n dynatrace shows Running and use kubectl get pods -n dynatrace to check Operator/ActiveGate/OneAgent components. Finally, wait for the connection signal in Dynatrace and open the new cluster. [1][4]

Step 1: Confirm the Cluster Context and Permissions

Start by proving that your kubectl context points to the intended cluster:

kubectl config current-context
kubectl cluster-info

These are standard Kubernetes checks, not Dynatrace-specific commands. The purpose is to prevent an Operator from being installed into the wrong cluster because an administrator had a different context selected.

Dynatrace requires sufficient privileges for the installation. If you are not using the cluster-admin role, use the current Dynatrace deployment-permissions documentation for the exact RBAC requirements. [1]

This is particularly important in 2026 because Operator permission patterns have changed across versions. Current Dynatrace deployment docs note changes beginning with Operator 1.9.0 for certain ClusterRole bindings. Do not copy an old RBAC block merely because it still appears in a search result. [2]

Step 2: Verify Network Egress

Dynatrace's quickstart states that Dynatrace pods—by default in the dynatrace namespace—must be able to reach the Dynatrace environment URL. [1]

Before installation, review:

  • outbound HTTPS firewall policy;
  • corporate proxy requirements;
  • private registry/proxy rules if you mirror images;
  • DNS resolution from cluster nodes/pods; and
  • TLS interception or custom CA requirements.

A Kubernetes manifest can apply successfully while the Operator still cannot reach the environment. Treat “kubectl accepted the YAML” and “Dynatrace is connected” as separate checkpoints.

Step 3: Add the Cluster from the Current Dynatrace Kubernetes App

In Latest Dynatrace, the current quickstart is:

  1. open Kubernetes;
  2. select Add cluster;
  3. choose your Kubernetes distribution;
  4. select the observability options;
  5. configure the cluster name and recommended network metadata; and
  6. proceed to the Install Dynatrace Operator step. [1]

The current onboarding enables several observability options by default depending on distribution. Review them rather than accepting every option automatically.

Possible choices include Full-Stack observability, log management/analytics, application observability, extension-based Prometheus metric collection, and telemetry ingest endpoints. Availability depends on the cluster/distribution and your Dynatrace environment. [1]

If you do not need application injection or cluster-wide log ingestion, disable those options before generating the configuration instead of collecting data merely because a default was enabled.

Step 4: Generate Tokens and Download dynakube.yaml

In the Operator installation step, generate the Dynatrace Operator token and any additional ingest token required by the selected options. Current Latest environments may generate a platform token through this workflow. [1]

Then select Download dynakube.yaml.

Dynatrace's documentation explicitly says the downloaded file contains both the DynaKube specification and a Kubernetes Secret with the generated tokens. [1]

Treat the file accordingly:

  • do not commit it to a public repository;
  • do not paste it unredacted into a support forum;
  • do not attach it to a tutorial screenshot with Secret data visible;
  • restrict local filesystem access while it exists; and
  • use your organization's secret-handling process for long-term GitOps management.

This is a meaningful security distinction from ordinary Kubernetes YAML.

Step 5: Execute the Generated Operator Installation Commands

Use the commands shown by your Dynatrace onboarding screen. They reflect the current Operator deployment path and generated configuration.

If your workflow asks you to apply a DynaKube file, the stable Kubernetes operation is:

kubectl apply -f <your-DynaKube-CR>.yaml

Dynatrace uses this pattern throughout its current deployment documentation and notes that its validation webhook can surface configuration errors. [2][5]

Do not replace <your-DynaKube-CR> with a filename copied from this article. Use the file generated for your environment.

Keep the terminal output. An admission/webhook error at this stage is much more useful for diagnosis than a later “cluster not visible” symptom.

Step 6: Verify the DynaKube Resource

Dynatrace's quickstart gives a direct verification command:

kubectl get dynakubes -n dynatrace

The expected healthy status is Running. [1]

If you used a non-default namespace generated by your own supported deployment path, substitute that namespace consistently. Do not mix resources from dynatrace and another namespace during troubleshooting.

A Running DynaKube is a strong deployment signal, but it is not the only one. Next check the individual components.

Step 7: Verify Dynatrace Pods

Run:

kubectl get pods -n dynatrace

The exact pod set varies with the selected deployment mode. Current Dynatrace examples can include Operator, ActiveGate, OneAgent, CSI driver, and webhook pods for full-stack deployments. [4][5]

Look for:

  • Running/Ready components;
  • repeated restarts;
  • ImagePullBackOff or registry failures;
  • pending pods caused by scheduling/security policy;
  • webhook failures; and
  • OneAgent DaemonSet coverage when Full-Stack host monitoring is selected.

Do not hard-code an expected pod count in your alerting/runbook. Different observability options legitimately create different resources.

Step 8: Use the Dynatrace Operator Troubleshooter

Current Dynatrace troubleshooting documentation provides an Operator troubleshoot subcommand:

kubectl exec deploy/dynatrace-operator -n dynatrace -- \
  dynatrace-operator troubleshoot

It checks areas such as namespace/resource presence, DynaKube configuration, token Secret expectations, environment reachability, and image registry access. [4]

If your DynaKube resource has a custom name, the current docs support adding:

--dynakube <your_dynakube_name>

Use this diagnostic before randomly deleting and reinstalling the Operator.

For Operator logs, Dynatrace also documents:

kubectl -n dynatrace logs -f deployment/dynatrace-operator

And for a failing pod:

kubectl describe pod <pod-name> -n dynatrace
kubectl logs <pod-name> -n dynatrace

The final two are standard Kubernetes diagnostics; inspect events first when the pod never starts.

Step 9: Verify the Cluster in Dynatrace

The current quickstart lets you wait for a successful connection signal and then open the new cluster. [1]

In Dynatrace, verify:

  • the expected cluster name is present;
  • cluster data timestamps are current;
  • nodes/namespaces/workloads appear according to your selected capabilities;
  • the ActiveGate/Operator connection is healthy; and
  • application/log visibility matches what you enabled.

If the cluster connects but some data is absent from the new Kubernetes experience, check the specific experience prerequisites rather than reinstalling everything. Dynatrace's current documentation notes that newer Kubernetes views can depend on ActiveGate/Operator versions and permissions even when Classic views still show data. [3]

Verify the Setup

The onboarding is complete only when all of the following are true:

  1. kubectl was confirmed against the intended cluster;
  2. the generated token/YAML were handled as secrets;
  3. kubectl get dynakubes -n dynatrace reports the expected DynaKube as Running;
  4. required Dynatrace pods are Ready for the chosen deployment mode;
  5. the Operator troubleshooter does not report an unresolved reachability/configuration failure; and
  6. fresh cluster/workload telemetry is visible in the intended Dynatrace Kubernetes experience.

This end-to-end check distinguishes a successful Kubernetes deployment from a successful observability connection.

Common Problems and Fixes

Problem: DynaKube is not Running

Likely causes: invalid DynaKube configuration, missing/incorrect Secret, API URL problem, or Operator communication failure.

Fix: run the Operator troubleshooter, inspect the DynaKube resource, and read Operator logs. Use the admission/validation error from kubectl apply if one was returned. [4]

Problem: Operator pod is running but the environment is unreachable

Likely causes: egress firewall, proxy, DNS, TLS/CA, or wrong generated environment endpoint.

Fix: confirm cluster egress to the Dynatrace environment URL and run the troubleshooter, which explicitly checks environment reachability from the Operator pod. [1][4]

Problem: Pods are stuck in ImagePullBackOff

Likely causes: registry access, pull-secret configuration, proxy restrictions, or image policy.

Fix: inspect kubectl describe pod ... events and run the Operator troubleshooter's image/registry checks. Do not disable image security controls globally just to make the deployment proceed.

Problem: RBAC errors appear after following an older tutorial

Likely cause: Operator permissions changed between versions.

Fix: return to the current Dynatrace deployment-permissions documentation and generated onboarding workflow. In particular, current September 2026 docs describe permission changes beginning with Operator 1.9.0 in some deployment paths. [2]

Problem: Cluster is connected but data is missing from the new Kubernetes view

Likely causes: the new-experience platform requirements, ActiveGate/Operator version, application permission, or policy boundary is not satisfied.

Fix: check the current Getting started with Kubernetes experience prerequisites and troubleshooting notes. Dynatrace maintains Kubernetes Classic as a separate path for environments not yet meeting the new-experience requirements. [3]

Problem: OneAgent pods are not present on every node

This may be expected if you did not choose a Full-Stack/host-monitoring deployment mode. If you did choose it, current full-stack documentation says OneAgent/CSI components are deployed as DaemonSets and should cover nodes accordingly. [5]

Check node selectors, taints, pod security, DaemonSet status, and events before changing the DynaKube spec.

Best Practices

Use the generated configuration as the source of truth for initial onboarding. It reflects current tokens, environment URLs, supported Operator workflow, and selected observability options.

Review default observability options. More data is not automatically better. Enable logs, application injection, sensitive Kubernetes objects, and extra telemetry endpoints only when they have a clear use case.

Treat dynakube.yaml as sensitive. Current quickstart output can embed a Secret. Redact it before sharing.

Do not freeze old RBAC examples. Operator permission behavior evolves. Recheck current deployment permissions during upgrades.

Verify from both sides. Kubernetes says whether resources are healthy; Dynatrace says whether useful telemetry actually arrived.

Plan Operator upgrades. Store your sanitized/customized configuration in version control using a secure secret pattern and review Dynatrace upgrade notes rather than letting an old generated file become permanent undocumented infrastructure.

Related PerfMonitoring Resources

When This Setup Makes Sense

Use the Dynatrace Operator path for Kubernetes clusters where you want platform monitoring and, optionally, application observability, logs, or host-level Full-Stack monitoring.

For ordinary VMs or physical servers outside Kubernetes, use the companion OneAgent server installation tutorial instead. For tool evaluation rather than setup, see the Dynatrace software profile, infrastructure monitoring guide, server monitoring category, and Datadog vs Dynatrace comparison.

FAQ

Do I need the Dynatrace Operator for Kubernetes monitoring?

Dynatrace's current Kubernetes quickstart uses the Dynatrace Operator for onboarding new clusters. Use the current generated workflow for your supported distribution rather than following a legacy manual deployment. [1]

Why is the cluster connected but some workloads are missing?

First compare the missing data with the observability options you selected. Then check namespace/resource restrictions, Operator/ActiveGate versions, permissions, and whether you are viewing the new Kubernetes experience or Classic. [1][3]

Which Kubernetes permissions does Dynatrace need?

The required permissions depend on the selected capabilities and Operator version. If you do not grant cluster-admin, follow Dynatrace's current deployment-permissions documentation; do not copy an old ClusterRole from another article. [1][2]

Conclusion

Current Dynatrace Kubernetes onboarding is safest when you let the platform generate the Operator tokens, DynaKube specification, and installation commands for the cluster you are actually connecting. Then verify DynaKube state, pod health, Operator diagnostics, and finally fresh telemetry in Dynatrace.

That approach is more durable than publishing a static manifest that can become obsolete as the Operator, RBAC model, or Kubernetes experience changes.

References

  1. Dynatrace Docs — Quickstart: Deploy Dynatrace Operator on Kubernetes — https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/quickstart — updated August 4, 2026; accessed September 10, 2026.
  2. Dynatrace Docs — Get started with Kubernetes platform monitoring — https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/deployment/platform-observability — updated September 8, 2026 in the retrieved current result; accessed September 10, 2026.
  3. Dynatrace Docs — Getting started with Kubernetes experience — https://docs.dynatrace.com/docs/observe/infrastructure-observability/kubernetes-app/enable-k8s-experience — updated August 31, 2026; accessed September 10, 2026.
  4. Dynatrace Docs — Kubernetes troubleshooting — https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/deployment/troubleshooting — updated July 10, 2026; accessed September 10, 2026.
  5. Dynatrace Docs — Get started with Kubernetes platform monitoring + Full-Stack observability — https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/deployment/full-stack-observability — current result retrieved September 10, 2026.

Editorial note: This tutorial was fact-checked against current Latest Dynatrace Kubernetes documentation. No live Kubernetes cluster or Dynatrace tenant was used to claim hands-on test results.