Study guide
3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift
Key Takeaways Explain This Topic AI
The Dynatrace Operator automates cloud-native observability on Kubernetes and OpenShift by reconciling Custom Resources (DynaKube) to manage OneAgent and ActiveGate lifecycles.
CloudNativeFullStack is the cloud-native standard: it combines node infrastructure monitoring via DaemonSet with unprivileged application pod injection using the Mutating Webhook and CSI driver.
The Dynatrace OneAgent CSI driver caches agent binaries once on host node storage and binds them read-only into pods, eliminating image bloat and redundant network downloads.
ApplicationMonitoring mode is designed for serverless or restricted Kubernetes platforms (such as AWS Fargate) where node-level DaemonSets and root host access are prohibited.
Last updated: September 2026
Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift
Exam Focus: The Dynatrace Certified Associate exam places substantial emphasis on cloud-native deployment patterns, specifically the architecture of the Dynatrace Operator, the differences between the four primary DynaKube deployment modes, the operation of the Mutating Webhook admission controller, and the role of the Container Storage Interface (CSI) driver.
In modern container orchestration environments like Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), and Red Hat OpenShift, managing observability through traditional, static DaemonSets or manually altered Dockerfiles is anti-pattern. Ephemeral container lifecycles, autoscaling node groups, non-root security constraints, and immutable filesystems require an automated, declarative management approach.
The Dynatrace Operator embodies the official Kubernetes Operator pattern. It acts as an automated, in-cluster Site Reliability Engineer (SRE) that continuously reconciles the desired state of monitoring components against the cluster's actual state.
The Dynatrace Operator Architecture and the DynaKube Custom Resource
The Dynatrace Operator registers a Custom Resource Definition (CRD) called DynaKube ( apiGroup: core.dynatrace.com ). When a cluster administrator applies a DynaKube manifest, the Operator deploys, configures, and manages several specialized architectural components:
Operator Controller Manager ( dynatrace-operator ): The core control loop that reconciles DynaKube custom resources, coordinates agent updates, configures RBAC policies, and provisions routing to Dynatrace ActiveGates.
Mutating Webhook Controller ( dynatrace-webhook ): An admission controller registered with the Kubernetes API server ( kube-apiserver ). When pods are created in monitored namespaces, the webhook intercepts the pod creation requests, mutates the pod specifications, and injects the necessary environment variables and volume mounts required for OneAgent instrumentation.
CSI Driver DaemonSet ( dynatrace-oneagent-csi-driver ): A specialized Container Storage Interface (CSI) driver deployed across worker nodes. It downloads and caches OneAgent binaries once on the host node storage and binds them as read-only volumes into monitored application pods.
Host Monitoring DaemonSet: A lightweight node daemon responsible for gathering node-level infrastructure metrics, cgroup resource consumption, and container engine health.
Comprehensive Comparison of DynaKube Deployment Modes
A central focus of the certification exam is selecting the appropriate deployment mode within the DynaKube specification. Dynatrace provides four primary modes, each engineered for specific infrastructure topologies and security postures.
Feature / Dimension CloudNativeFullStack ClassicFullStack ApplicationMonitoring HostMonitoring
Target Environment Modern Kubernetes / OpenShift clusters with full node access Legacy Kubernetes or clusters matching traditional VM agent behavior Serverless K8s (AWS Fargate, Cloud Run, Azure Container Apps) Infrastructure-only clusters (e.g., database worker nodes)
Node Host Agent DaemonSet (infrastructure & cgroups only) Privileged DaemonSet (full OS + runtime injection) None (No DaemonSet scheduled) DaemonSet (infrastructure & cgroups only)
App Pod Injection Mutating Webhook + CSI Driver Injected directly into container runtimes from host Mutating Webhook (CSI driver or image pull) None (No application code injection)
Container Privileges Application pods remain completely unprivileged Host DaemonSet requires broad elevated privileges Application pods remain completely unprivileged Host DaemonSet requires host metrics access
Licensing Consumption Full-Stack (Host Units) Full-Stack (Host Units) DPS / Application Monitoring (Davis Data Units) Infrastructure Monitoring (Host Units)
Storage Efficiency Highest (Single cached binary per node via CSI) Moderate (Binaries shared via host filesystem) Variable (Uses CSI on nodes, or image pull per pod) Highest (No code modules stored or mounted)
- Code-Level PurePath Yes Yes Yes No
- Mode Details
CloudNativeFullStack: The official Dynatrace recommended standard for modern Kubernetes and OpenShift. It completely decouples node-level infrastructure monitoring from application runtime injection. Application pods are instrumented cleanly at admission time using the CSI driver, eliminating the need for privileged container runtime injection on the node.
ClassicFullStack: Mirrors traditional VM-based OneAgent deployment. A single privileged OneAgent container runs per node as a DaemonSet, discovers container runtimes via local sockets, and injects code modules into container processes from the host. This mode is used when clusters lack CSI driver support or when migrating existing VM environments to containerized architectures.
ApplicationMonitoring: Specifically engineered for serverless or tightly restricted environments where cluster administrators do not manage the underlying virtual machine worker nodes (such as AWS Fargate for EKS). Because DaemonSets cannot be scheduled on Fargate, this mode relies strictly on the Mutating Webhook to inject OneAgent into application containers at the pod level.
HostMonitoring: Deploys a DaemonSet focused strictly on collecting host node CPU, memory, storage, network, and container cgroup metrics. It does not inject code modules into application containers and does not capture PurePaths or database transactions. It consumes lower-cost Infrastructure Monitoring licensing.
The Mutating Webhook Admission Controller Deep Dive
To understand how OneAgent instruments containerized workloads in CloudNativeFullStack and ApplicationMonitoring modes, examine the step-by-step admission review lifecycle: 1. Developer Action ==> kubectl apply -f deployment.yaml
- 2. API Server Review ==> kube-apiserver receives Pod creation request
- 3. Webhook Dispatch ==> AdmissionReview sent to dynatrace-webhook service
- 4. Namespace Filter ==> Webhook checks namespace labels (e.g., oneagent.dynatrace.com/inject)
- 5. Pod Mutation ==> Webhook patches Pod spec: adds init-container, CSI mount, env vars
- 6. Node Scheduling ==> kube-scheduler assigns mutated Pod to worker node
- 7. CSI Volume Attach ==> CSI driver mounts cached agent binaries into /opt/dynatrace/oneagent-paas
- 8. Init Execution ==> install-oneagent container verifies configuration and certificates
- 9. App Container Start ==> Application boots with LD_PRELOAD loading OneAgent into memory
- Namespace Targeting and Opt-In / Opt-Out Mechanics
The Dynatrace Mutating Webhook does not blindly inject every pod across the entire cluster. By default, it inspects Kubernetes namespace labels. Administrators control injection scope through labeling: # Enable automatic injection for a namespace
kubectl label namespace production-ecommerce oneagent.dynatrace.com/inject=true
- # Disable injection explicitly for a namespace
- kubectl label namespace system-maintenance oneagent.dynatrace.com/inject=false
Individual workloads can override namespace defaults using pod annotations in their deployment manifests: metadata:
annotations:
- oneagent.dynatrace.com/inject: "false" # Opts this specific deployment out
- The Container Storage Interface (CSI) Driver Architecture
Prior to the introduction of the Dynatrace CSI driver, monitoring containerized applications required either baking OneAgent binaries into every base Docker image (causing massive image bloat) or executing an init container that downloaded the 200MB+ OneAgent installer from Dynatrace SaaS every time a pod scaled up. During rapid autoscaling events or node failovers, dozens of pods simultaneously downloading installer packages would exhaust network bandwidth and delay pod startup times by minutes.
The dynatrace-oneagent-csi-driver solves this problem permanently:
It runs as a lightweight DaemonSet on each worker node.
It connects to the Dynatrace cluster, downloads the required OneAgent code modules once, and stores them in a local cache on the host node storage.
When a newly scheduled application pod is mutated by the webhook, a CSI volume is attached to the pod.
The CSI driver binds the pre-cached OneAgent binaries directly into the application container's filesystem as a read-only volume mounted at /opt/dynatrace/oneagent-paas .
Container startup is nearly instantaneous (sub-second), image bloat is completely eliminated, and external egress traffic is reduced by orders of magnitude.
Red Hat OpenShift Integration and Security Context Constraints (SCC)
Red Hat OpenShift enforces stringent security boundaries through Security Context Constraints (SCC) . By default, OpenShift prohibits pods from running as the root user, mounting host filesystems, or accessing host namespaces.
The Dynatrace Operator is fully certified for OpenShift and available directly through the OpenShift OperatorHub . During deployment, the Operator automatically creates and configures the required SCC bindings:
The CSI driver and node-monitoring daemonsets are granted the necessary privileged or custom SCCs required to mount storage volumes and inspect node cgroups.
Monitored application pods remain completely unprivileged, running under OpenShift's standard restricted-v2 SCC without violating enterprise compliance.
The Operator seamlessly configures OpenShift Routes for secure ActiveGate communication across clusters.
Cluster Verification, Lifecycle Upgrades & Troubleshooting
Administering the Dynatrace Operator requires proficiency with diagnostic and status verification commands:
- Verifying Deployment Health # Check the status of the DynaKube custom resource
- kubectl get dynakube -n dynatrace
- # Detailed inspection of DynaKube conditions, phase, and agent version
- kubectl describe dynakube <dynakube-name> -n dynatrace
- # Verify all operator, webhook, and CSI pods are running
- kubectl get pods -n dynatrace -o wide
- Troubleshooting Mutating Webhook Injection Failures
If application pods in a target namespace are running but lack OneAgent code modules (no PurePaths or services appearing in Dynatrace):
Verify Namespace Labeling: Confirm that the namespace contains the exact label oneagent.dynatrace.com/inject=true using kubectl get ns --show-labels .
Check Webhook Configuration: Verify that the mutating webhook configuration is registered and active: kubectl get mutatingwebhookconfiguration dynatrace-webhook -o yaml
Inspect Pod Init Container Logs: If the webhook mutated the pod but injection failed during startup, inspect the OneAgent init container output: kubectl logs <pod-name> -c install-oneagent -n <application-namespace>
Review Operator Logs: Inspect the central operator controller logs for admission review rejections, certificate synchronization issues, or ActiveGate routing errors: kubectl logs -n dynatrace -l app.kubernetes.io/name=dynatrace-operator --tail=200