dt-obs-kubernetes
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
By dynatrace · 1,978 installs
npx skills add dynatrace/dynatrace-for-ai --skill dt-obs-kubernetes
Source repository · Upstream listing
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)
1. Cluster Inventory → references/cluster inventory.md Clusters,
namespaces, resource distribution
2. Node Monitoring Node capacity, CPU/memory usage, pod density
3. Pod Monitoring Pod CPU, memory, lifecycle events
4. Workload Monitoring Deployment, StatefulSet, DaemonSet resources
Advanced Topics
1. Configuration Analysis → references/labels annotations.md Parse
k8s.object, labels, annotations
2. Scheduling & Placement → references/pod node placement.md Node
selectors, affinity, taints, HA
3. Cost Optimization Right sizing, waste detection, efficiency scoring
4. Security & Compliance Privileged containers, security contexts
Key Concepts
Entity Types
Workloads: K8S DEPLOYMENT , K8S STATEFULSET , K8S DAEMONSET ,
K8S JOB , K8S CRONJOB , K8S HORIZONTALPODAUTOSCALER
Infrastructure: K8S CLUSTER , K8S NAMESPACE , K8S NODE , K8S POD
Configuration: K8S SERVICE , K8S CONFIGMAP , K8S SECRET ,
K8S PERSISTENTVOLUMECLAIM , K8S PERSISTENTVOLUME , K8S INGRESS ,
K8S NETWORKPOLICY
Query Types
smartscapeNodes Query K8s entities:
timeseries Monitor metrics over time:
fetch logs Analyze log events:
Core Fields
k8s.cluster.name , k8s.namespace.name , k8s.pod.name , k8s.node.name
k8s.workload.name , k8s.workload.kind , k8s.container.name
k8s.object Full JSON configuration for deep inspection
tags[label] Access labels and annotations
Available Metrics
CPU: dt.kubernetes.container.cpu usage , cpu throttled , limits cpu ,
requests cpu
Memory: dt.kubernetes.container.memory working set , limits memory ,
requests memory
Operations: dt.kubernetes.container.restarts , oom kills
Node: dt.kubernetes.node.pods allocatable , cpu allocatable ,
memory allocatable , dt.kubernetes.pods
Entity Disambiguation
K8S POD vs CONTAINER : these are different entity types in Dynatrace.
K8S POD — K8s native entities with k8s.object JSON, scheduling state, conditions, and K8s metrics. Use this skill.
CONTAINER — Host level container inventory (image, lifetime, host assignment). Use dt obs hosts skill instead.
The smartscape edge is CONTAINER (is part of) K8S POD . To reach containers from a pod, traverse backward:
Service → K8S POD Correlation
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](references/pod debugging.md service pod drill down) in references/pod debugging.md for the full two step pattern.
Common Workflows
1. Cluster Health Check
List all clusters:
Check node capacity:
Identify pods in non Running state:
2. Resource Optimization
Find over provisioned pods (usage < 30%):
Identify containers without limits:
3. Troubleshooting Pod Issues
Pod troubleshooting benefits from combining metrics (timeseries) with
Kubernetes events (event stream) for a complete picture.
Metrics Based Troubleshooting
Find pods with OOMKills:
Analyze pod restart patterns:
Event Based Troubleshooting
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:
1. Use the events tool to get the event details (what happened, when, why)
2. 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:
Filter for specific event reasons:
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.
4. Security Assessment
Identify privileged containers:
Find containers running as root:
5. Scheduling Analysis
Verify pod distribution (HA compliance):
6. DAVIS Problems affecting K8s Entities
Find active DAVIS problems affecting K8s entities:
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
1. Filter early Apply cluster/namespace filters immediately
2. Use specific entity types Avoid wildcards
3. Limit result sets Use limit for exploration
4. Cache cluster lists Store in variables
Monitoring Recommendations
1. Set resource limits on all containers
2. Monitor OOMKills and adjust memory limits
3. Track CPU throttling and adjust CPU limits
4. Review resource efficiency regularly (target 70 80%)
5. Implement security best practices (non root, read only filesystem)
6. Use specific image tags (avoid :latest)
Configuration Standards
1. Use labels for organization (app, environment, team)
2. Set resource requests and limits
3. Configure health checks (liveness/readiness probes)
4. Use TLS for all ingress resources
5. Document with annotations
Troubleshooting
Problem Cause Solution
No pod data returned Wrong entity type or missing cluster filter Use K8S POD (not POD ); add k8s.cluster.name filter
k8s.object parsing errors Complex JSON structure Use parse k8s.object, "JSON:config" then access nested fields
Pod network metrics unavailable Not available in Grail Use service mesh metrics or host level network metrics
Large result sets No time range or cluster filter Add time range and filter by cluster/namespace early
Missing labels in output Labels accessed incorrectly Use tags[label name] to access labels
Limitations
Unavailable Metrics:
Pod network metrics (rx bytes, tx bytes) are NOT available in Grail
Workaround: Use service mesh metrics or host level network metrics
Query Considerations:
Minimize result set size: Do not include the k8s.object field if not necessary
Keep result set as simple as possible: Parsing k8s.object increases query complexity
Large clusters may require pagination or time range limits
Some K8s status fields update asynchronously
When to Load References
Load cluster inventory.md when:
Performing cluster, namespace, or resource distribution analysis
Auditing workload counts across clusters
→ [references/cluster inventory.md](references/cluster inventory.md)
Load labels annotations.md when:
Filtering by labels or annotations
Parsing k8s.object for detailed configuration inspection
→ [references/labels annotations.md](references/labels annotations.md)
Load pod node placement.md when:
Analyzing scheduling constraints (affinity, taints, tolerations)
Verifying HA compliance and pod distribution
→ [references/pod node placement.md](references/pod node placement.md)
Load pod debugging.md when:
Investigating pod exit codes, crash loops, or init container failures
Diagnosing image pull errors or service to pod connectivity issues
Drilling down from a service problem to pod level details
→ [references/pod debugging.md](references/pod debugging.md)
Load workload health.md when:
Investigating degraded deployments or stuck rollouts
Checking node conditions, CPU throttling, or HPA scaling
Analyzing StatefulSet ordering or DaemonSet coverage
→ [references/workload health.md](references/workload health.md)
Load pv pvc.md when:
Working with persistent storage (PVC/PV lifecycle, orphaned volumes)
Checking StorageClass configurations
→ [references/pv pvc.md](references/pv pvc.md)
Load ingress.md when:
Analyzing ingress routing rules or TLS certificates
Auditing ingress controller configurations
→ [references/ingress.md](references/ingress.md)
Load network policies.md when:
Listing or auditing network policies
Checking namespace isolation configurations
→ [references/network policies.md](references/network policies.md)
References
[cluster inventory.md](references/cluster inventory.md) — Cluster, namespace, and resource distribution analysis
[labels annotations.md](references/labels annotations.md) — Label/annotation filtering and k8s.object parsing
[pod node placement.md](references/pod node placement.md) — Scheduling, affinity, taints, and HA patterns
[pod debugging.md](references/pod debugging.md) — Exit codes, pod conditions, init containers, image pull errors, logs, service to pod drill down
[workload health.md](references/workload health.md) — Degraded deployments, stuck rollouts, node conditions, CPU throttling, HPA, StatefulSet ordering
[pv pvc.md](references/pv pvc.md) — PVC/PV lifecycle, phase reference, orphaned volumes, StorageClass
[ingress.md](references/ingress.md) — Routing rule parsing, TLS audit
[network policies.md](references/network policies.md) — Policy listing, namespace isolation audit
Related Skills
dt obs problems — For problems associated with Kubernetes cluster