Deploying an ActiveGate to monitor Kubernetes clusters is less about getting a new agent into your cluster and more about extending Dynatrace’s reach into a dynamic, ephemeral environment.
Here’s a look at the ActiveGate in action, monitoring a Kubernetes cluster. Imagine we have a simple Nginx deployment running in our cluster.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
When the Dynatrace Operator is installed in the cluster, it automatically provisions and configures an ActiveGate specifically for Kubernetes monitoring. This ActiveGate isn’t a traditional monolithic agent; it’s a lightweight component designed to understand Kubernetes’ API and topology.
The ActiveGate begins by connecting to the Kubernetes API server. It uses this connection to discover all the resources within the cluster: nodes, pods, services, deployments, namespaces, and their relationships. This discovery process is continuous; as pods scale up or down, or new services are created, the ActiveGate immediately picks up these changes.
For each discovered pod running an application instrumented by Dynatrace (either via automatic instrumentation or manual injection), the ActiveGate establishes a connection. It collects metrics from the Kubernetes environment itself – CPU and memory usage at the pod and node level, network traffic between pods, and Kubernetes-specific events.
This data is then enriched with the full-stack monitoring data collected by the OneAgent (if deployed) within the pods. The ActiveGate acts as a bridge, correlating the Kubernetes-native metrics with the application-level metrics. This allows Dynatrace to present a unified view, showing not just application performance but also its underlying infrastructure health and resource utilization within the Kubernetes context.
The key problem this solves is bridging the gap between traditional infrastructure monitoring and the dynamic, containerized world of Kubernetes. Without a specialized component like the ActiveGate, Dynatrace would struggle to understand the ephemeral nature of pods, their relationships, and the underlying Kubernetes control plane. The ActiveGate’s intelligence about Kubernetes API objects and their lifecycle is what enables Dynatrace to build a true topology of your cluster.
You control the ActiveGate’s behavior primarily through the Dynatrace Operator configuration. This includes specifying which namespaces to monitor, whether to enable specific features like network traffic analysis between pods, and how the ActiveGate should connect to your Dynatrace cluster (SaaS or Managed). The Operator ensures the ActiveGate is deployed as a Kubernetes Deployment or DaemonSet, leveraging Kubernetes’ own scheduling and resilience capabilities.
The ActiveGate’s ability to automatically detect and instrument applications running in Kubernetes pods, even as they are created and destroyed, is a critical differentiator. It doesn’t rely on manual agent deployment for every new application instance; instead, it leverages the Kubernetes API to understand the application’s environment and inject monitoring capabilities dynamically.
The ActiveGate for Kubernetes doesn’t just collect metrics; it understands the meaning of those metrics within the Kubernetes ecosystem. For instance, it can differentiate between a pod failing due to an application error versus a pod being terminated because the node it was running on became unhealthy, or because Kubernetes decided to reschedule it. This nuanced understanding is crucial for accurate root-cause analysis in complex microservices architectures.
The next challenge you’ll likely encounter is understanding how Dynatrace leverages Kubernetes events to provide deeper insights into cluster behavior.