Kubernetes cluster, pod, node, and workload monitoring. Use when analyzing K8s health, resource optimization, pod failures, OOMKills, scheduling, or security posture. Also use for Kubernetes operational events like pod restarts, OOM events, evictions, and cluster event history. Trigger: "Kubernetes pods", "K8s cluster health", "OOMKill", "pod restarts", "container CPU", "namespace resource usage", "over-provisioned pods", "privileged containers", "pod placement", "K8s node capacity", "running containers by cluster", "workload scheduling", "pod evictions", "K8s labels and annotations", "kubernetes events", "pod restart events", "OOM events", "K8s event history". Do NOT use for explaining existing queries, product documentation questions, AWS-specific resource queries, service-level RED metrics, distributed tracing, or log analysis — use the relevant skill instead.
Kubernetes cluster, pod, node, and workload monitoring. Use when analyzing K8s health, resource optimization, pod failures, OOMKills, scheduling, or security posture. Also use for Kubernetes operational events like pod restarts, OOM events, evictions, and cluster event history. Trigger: "Kubernetes pods", "K8s cluster health", "OOMKill", "pod restarts", "container CPU", "namespace resource usage", "over-provisioned pods", "privileged containers", "pod placement", "K8s node capacity", "running containers by cluster", "workload scheduling", "pod evictions", "K8s labels and annotations", "kubernetes events", "pod restart events", "OOM events", "K8s event history". Do NOT use for explaining existing queries, product documentation questions, AWS-specific resource queries, service-level RED metrics, distributed tracing, or log analysis — use the relevant skill instead.
license
Apache-2.0
Infrastructure Kubernetes
Monitor and analyze Kubernetes infrastructure using Dynatrace DQL. Query
cluster resources, monitor workload health, analyze pod placement, optimize
costs, and assess security posture.
When to Use This Skill
Monitoring Kubernetes cluster health and capacity
Analyzing pod and container resource utilization
Investigating pod failures, OOMKills, evictions, or crash loops
Debugging degraded deployments, stuck rollouts, or node pressure
Optimizing Kubernetes resource costs
Assessing security posture and compliance
Troubleshooting workload scheduling and placement
Auditing ingress routing and network policies
Knowledge Base Structure
Core Monitoring (Start Here)
Cluster Inventory → references/cluster-inventory.md - Clusters,
namespaces, resource distribution
Node Monitoring - Node capacity, CPU/memory usage, pod density
Pod Monitoring - Pod CPU, memory, lifecycle events
No direct smartscape edge exists between SERVICE and K8S_POD. The correlation key is the shared dimension k8s.workload.name. See Service → Pod Drill-Down in references/pod-debugging.md for the full two-step pattern.
For operational events (pod restarts, OOM kills, evictions, scheduling failures),
Kubernetes events provide richer context than metrics alone — including event
reasons, messages, and timestamps.
When to use Kubernetes events over metrics:
User asks about recent operational events ("show me pod restart events")
User wants event details like reasons and messages
User asks about events in a specific time window ("last 48 hours")
User wants to correlate events with root causes
Kubernetes events are available through the get-events-for-kubernetes-cluster
tool. Prefer this tool when the user asks about OOM events, pod restarts,
evictions, or cluster-wide event history.
Important: distinguish event types when filtering results. Kubernetes events
cover many categories. When the user asks about a specific event type, filter
the results accordingly — do not report unrelated events:
User Asks About
Relevant Event Reasons
NOT Related
Pod restarts
BackOff, CrashLoopBackOff, Killing
Readiness probe failures, CPU throttling
OOM events
OOMKilling, OOMKilled
Memory pressure warnings
Evictions
Evicted, Preempting
Node pressure
Scheduling failures
FailedScheduling, Unschedulable
Resource quotas
For a complete answer, combine both approaches:
Use the events tool to get the event details (what happened, when, why)
Use timeseries metrics to show the quantitative impact (how many restarts,
OOM kill counts over time)
Fetch Kubernetes Events via DQL
Pod restart and operational events can also be queried via DQL from the events
table:
Field names in fetch events: Use event.reason and event.message — not
dt.kubernetes.event.reason. The dt.kubernetes.* prefix is for timeseries metrics,
not the events table. Queries using the wrong prefix return zero results.
smartscape.affected_entities is a record array; each record has id, type, and name. Use
[][id] to get the array of Smartscape IDs to look up the affected entity, or
[id] after expand smartscape.affected_entities. Without a preceding expand, [id] returns
null silently. A filter cannot take a bare iterative expression, so wrap it in iAny(...).
Best Practices
Choosing the Right Data Source
User Question
Best Approach
Why
"Show me OOM events"
Events tool + metrics
Events give reasons/messages; metrics show trends
"Show me pod restart events"
Events tool + timeseries metrics
Events reveal the reason (BackOff, Killing, CrashLoopBackOff); dt.kubernetes.container.restarts metric gives the actual restart counts
"How many pod restarts?"
Timeseries metrics
Quantitative data over time
"What happened to my pods in the last 48h?"
Events tool
Operational event history with context
"Which pods are using the most CPU?"
Timeseries metrics
Resource utilization analysis
"List all clusters/namespaces"
smartscapeNodes
Entity discovery and inventory
"Are there scheduling failures?"
Events tool
Event reasons explain why
Query Performance
Filter early - Apply cluster/namespace filters immediately
