3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events

Section 3.3 covered how the Dynatrace Operator gets instrumentation into a cluster. That is only half of the exam's Kubernetes Infrastructure topic. The score report treats Kubernetes as its own scored area, and the questions that appear there are overwhelmingly about analysis: which object owns a metric, why a pod restarted, where an event is displayed, and how requests and limits relate to what you see. This section covers that half.

---

The Kubernetes Object Hierarchy in Dynatrace

The Kubernetes app presents an Explorer view whose sidebar groups every discovered object by type. Understanding the hierarchy is the prerequisite for every other question.

Cluster
  └── Node                (a machine; also a Dynatrace Host entity)
  └── Namespace           (logical tenancy boundary)
        └── Workload      (Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet)
              └── Pod     (scheduling unit)
                    └── Container
  └── Service             (stable network endpoint in front of pods)

Two modelling facts matter for the exam:

1. A Kubernetes node is also a Dynatrace host. The same machine appears in the Kubernetes app as a node and in Infrastructure & Operations as a host, with the same CPU, memory, disk, and network metrics. Questions that imply these are two separate monitored entities are wrong.
2. Workload is the unit you usually alert and report on, not the pod. Pods are ephemeral; a Deployment that restarts fifty pods per day is still a single workload entity with continuous history.

---

Cluster and Namespace Analysis

The cluster page answers capacity and health questions across the whole estate: node count and readiness, aggregate CPU and memory requests versus allocatable capacity, running versus pending pods, and cluster-level events.

The namespace unified analysis page is where multi-tenant governance happens. It exposes:

• Properties — labels, annotations, and cluster membership
• Problems — Davis problems scoped to workloads in this namespace
• Resource requests and limits — aggregate CPU and memory reservations
• Workload analysis — every workload in the namespace with its pod counts
• Quotas — Kubernetes ResourceQuota consumption
• Events — Kubernetes events for objects in the namespace

A typical exam scenario: a platform team must show a tenant that their namespace is requesting far more CPU than it uses. The namespace page's requests-versus-usage comparison is the intended answer, not a hand-built DQL query.

---

Workload Analysis

The workload unified analysis page is the densest screen in the Kubernetes app, and it deliberately fuses several data types:

That last row is the reason Dynatrace positions Kubernetes as more than infrastructure monitoring: the same page shows a CrashLoopBackOff event, the memory limit that caused it, and the vulnerable library running inside the image.

---

Kubernetes Event Monitoring

Kubernetes emits events — Scheduled, Pulled, Killing, BackOff, FailedScheduling, OOMKilling, Unhealthy — that explain why the cluster did something. Dynatrace ingests them, but not by default in every configuration.

To monitor Kubernetes events you must ensure Monitor Kubernetes namespaces, services, workloads, and pods is turned on in the cluster's monitoring settings. Once enabled, pod events are displayed on the cluster, namespace, workload, and pod detail pages — the same event appears at every level of the hierarchy that contains it.

This is high-yield exam material because it is counter-intuitive: candidates assume that installing the Operator automatically produces events. The correct sequence is Operator deployed → cluster connected → namespace/workload/pod monitoring enabled → events visible. You can additionally create event-driven alerting so that specific event reasons raise Dynatrace events.

---

Requests, Limits, and the Two Classic Failure Modes

Almost every Kubernetes performance question on the exam reduces to requests versus limits.

• Requests are what the scheduler reserves. Too-high requests waste cluster capacity and cause FailedScheduling ("Insufficient cpu") even when nodes look idle.
• Limits are hard ceilings enforced at runtime, and the two resources behave completely differently when a limit is hit:

Worked scenario: a Java service shows response times climbing from 200 ms to 1.4 s every weekday afternoon, with zero pod restarts and node CPU at 40%. Because there are no restarts, memory is not the constraint; because node CPU is low, the node is not saturated. The answer is CPU throttling against the container's CPU limit — the workload page's utilization-versus-limit chart shows usage pinned at the limit. Raising the CPU limit, not adding nodes, is the fix.

Contrast that with a pod whose restart count increments every few hours and whose events include OOMKilling. That is a memory limit problem, and the fix is a higher memory limit or a genuine heap leak investigation via the PurePath memory diagnostics covered in Chapter 6.

---

Cloud-Managed Kubernetes

Dynatrace treats EKS, AKS, GKE, and OpenShift as clusters like any other, but on managed services the control plane is not a customer host. You will not see kube-apiserver as a monitored process on EKS. Questions that expect control-plane process metrics on a managed offering are testing whether you understand that boundary.