Kubernetes Deployments Monitoring: Availability and CPU

The Deployments view shows aggregated resource usage across all pods in each deployment.

Deployments List Page Columns

Deployment Name

This column is derived from the resource attribute k8s.deployment.name.
Identifier of the Kubernetes Deployment.
Click the name to open the deployment detail page and drill into CPU/memory vs request/limit charts, network activity, logs, and events for the deployment's pods.

Namespace Name

This column is derived from the resource attribute k8s.namespace.name.
Namespace the Deployment belongs to.
Use it to filter the list to a specific tenant or team and to navigate to the namespace-level view for aggregate workload status across Deployments, StatefulSets, DaemonSets, and Jobs.

Pod Replicas

A combined, always-visible summary of the deployment's pod replica counts: Available (green) and Desired (blue) shown side by side. Both are described in full in the Available and Desired sections below. At a glance: Available equal to Desired means the rollout is complete and healthy; Available below Desired means a rollout, scaling event, or degraded state is in progress.
This summary is display-only and cannot be sorted. To sort the list by replica count, enable the dedicated Available Pods and Desired Pods columns (both hidden by default) from the Columns selector.

Available

This column relies on the OTel metric k8s.deployment.available from the k8s_cluster receiver, defined as "Total number of available pods (ready for at least minReadySeconds) targeted by this deployment".
This is the K8s .status.availableReplicas field: pods that pass readiness checks and have been ready for at least minReadySeconds. Available < Desired during a rollout is expected; if it stays low after the rollout window, the deployment is degraded.
A persistent Available < Desired means new pods are failing to start or pass readiness: kubectl rollout status deployment/<name> and the pod events surface the root cause (image-pull failure, failing readiness probe, insufficient cluster capacity).

Desired

This column relies on the OTel metric k8s.deployment.desired from the k8s_cluster receiver: the .spec.replicas field of the Deployment.
Number of pods the Deployment controller intends to maintain. A Horizontal Pod Autoscaler (HPA) attached to the Deployment will mutate .spec.replicas, so this value changes when the HPA scales up or down.
Compare against Available to assess deployment health: equal → rollout complete and healthy; not equal → rollout in progress, scaling event, or degraded state.

CPU Req Usage (%)

This column relies on the OTel metric k8s.pod.cpu_request_utilization from the kubeletstats receiver, averaged across the deployment's pods.
Average ratio of pod CPU usage to the sum of its containers' CPU requests across the deployment's pods, expressed as a percentage. Values consistently >100% mean pods are using more CPU than reserved (allowed, but a signal requests are under-provisioned); values well below 50% indicate over-provisioned reservations.
Use this to detect under-/over-provisioning at the deployment level: adjust the pod spec's resources.requests.cpu to pack the cluster better and reduce scheduling friction.
Color of the in-table progress bar reflects the value: amber below 50% (request likely over-provisioned, wasted capacity), green between 50% and 100% (healthy), red between 100% and 150% (request under-provisioned), and dark red above 150%.

CPU Limit Usage (%)

This column relies on the OTel metric k8s.pod.cpu_limit_utilization from the kubeletstats receiver, averaged across the deployment's pods.
Average ratio of pod CPU usage to the sum of its containers' CPU limits across the deployment's pods, expressed as a percentage. Per K8s docs, "when a container approaches its cpu limit, the kernel restricts access to the CPU": values near 100% indicate active or imminent throttling.
Sustained high values mean the deployment's pods are throttling under load and either need a higher limits.cpu or more replicas to absorb the work.
Color of the in-table progress bar reflects the value: green below 60% (healthy headroom), light amber between 60% and 80% (caution), amber between 80% and 95% (high, throttling becoming likely), and red above 95% (critical, at or beyond the limit).

CPU Usage (cores)

This column relies on the OTel metric k8s.pod.cpu.usage from the kubeletstats receiver, summed across the deployment's pods.
Total CPU consumed by all of the Deployment's pods in CPU-core units: a value of 1.0 means one full core in use across the deployment.
Use this for absolute capacity planning when you need the deployment's raw CPU draw rather than a ratio; pair with the chart on the detail page to see how the cores trend against the deployment's aggregate requests/limits.

Mem Req Usage (%)

This column relies on the OTel metric k8s.pod.memory_request_utilization from the kubeletstats receiver, averaged across the deployment's pods.
Average ratio of pod memory usage to the sum of its containers' memory requests across the deployment's pods, expressed as a percentage. As with CPU, sustained values >100% mean pods are using more memory than reserved; values well below 50% indicate over-provisioned reservations.
Use this to right-size the deployment's resources.requests.memory; consistently low values free up scheduling capacity for other workloads.
Color of the in-table progress bar reflects the value: amber below 50% (request likely over-provisioned, wasted capacity), green between 50% and 100% (healthy), red between 100% and 150% (request under-provisioned), and dark red above 150%.

Mem Limit Usage (%)

This column relies on the OTel metric k8s.pod.memory_limit_utilization from the kubeletstats receiver, averaged across the deployment's pods.
Average ratio of pod memory usage to the sum of its containers' memory limits across the deployment's pods, expressed as a percentage. Per K8s docs, "when a container uses more than its memory limit, the kernel may terminate it" via an OOMKill: values near 100% indicate sustained OOMKill risk.
Sustained values approaching 100% mean a single pod in the deployment is on the verge of an OOMKill; raise limits.memory, fix the memory leak, or add replicas to spread load.
Color of the in-table progress bar reflects the value: green below 60% (healthy headroom), light amber between 60% and 80% (caution), amber between 80% and 95% (high, OOMKill becoming likely), and red above 95% (critical, at or beyond the limit).

Mem Usage (WSS)

This column relies on the OTel metric k8s.pod.memory.working_set from the kubeletstats receiver, summed across the deployment's pods.
Total Working Set Size across the Deployment's pods: anonymous + active file pages, excluding reclaimable inactive file pages (the value the kubelet uses for eviction).
Sustained high WSS without explicit limits.memory on the deployment's containers means individual pods can grow until the kubelet evicts them under node MemoryPressure; set explicit limits or add a LimitRange to the namespace.

Pod Counts by Phase

This column relies on the OTel metric k8s.pod.phase from the k8s_cluster receiver, encoded 1 = Pending, 2 = Running, 3 = Succeeded, 4 = Failed, 5 = Unknown.
Counts of the Deployment's pods grouped by their latest observed lifecycle phase within the selected window, per the Kubernetes pod-lifecycle spec.
A persistent Pending count means the Deployment's pods can't be scheduled (insufficient capacity, taints blocking placement, or a ResourceQuota); Failed / Unknown spikes warrant inspecting kubectl describe deployment and the failing pods' events.

Pod Counts by Status

This column relies on the OTel metric(s): k8s.pod.phase, k8s.pod.status_reason, and k8s.container.status.reason from the k8s_cluster receiver. The latter two are disabled by default in the upstream receiver but enabled by default in the k8s-infra chart; all three must be flowing for this column to be populated.
Counts of the Deployment's pods grouped by their kubectl-style display status within the selected window. The status is derived exactly as on the Pods view; see Pod Status for the full priority cascade, the statuses it surfaces, and the statuses it cannot derive.
Any CrashLoopBackOff / OOMKilled / ImagePullBackOff count is a failing-rollout signal: the new ReplicaSet's pods aren't coming up; read it alongside the Available vs Desired counts and confirm with kubectl rollout status deployment/<name>.

Deployment Detail Page

Click a Deployment name to open the detail page. The header shows Deployment Name, Cluster Name, and Namespace Name. The detail page includes five tabs: Metrics, Logs, Traces, Events, and Pod Metrics.

Deployments Metrics - Charts and Panels

CPU Usage, Request, Limits

This chart relies on the OTel metrics k8s.pod.cpu.usage, k8s.container.cpu_request, and k8s.container.cpu_limit from the kubeletstats receiver, aggregated across the Deployment's pods and containers.
Plots three series, all averaged within the step interval and summed across the Deployment's pods: the Deployment's total CPU Usage in cores, container CPU Requests, and container CPU Limits. Usage approaching Limits means the kernel is throttling the Deployment's CPU; Usage well below Requests means the Deployment is reserving more capacity than it consumes.
Use this to right-size the Deployment's requests.cpu and limits.cpu and to confirm whether high CPU Limit Usage (%) on the list page corresponds to a real throttling pattern: if Usage hugs the Limits line, throttle events are happening.

Memory Usage, Request, Limits

This chart relies on the OTel metrics k8s.pod.memory.usage, k8s.container.memory_request, and k8s.container.memory_limit from the kubeletstats receiver, aggregated across the Deployment's pods and containers.
Plots three series, all averaged within the step interval and summed across the Deployment's pods: the Deployment's total Memory Usage in bytes, container Memory Requests, and container Memory Limits. Note that this uses k8s.pod.memory.usage (which includes reclaimable page cache), so it reads higher than the working-set value the kubelet uses for eviction decisions.
Use this alongside the Mem Limit Usage (%) column on the list page: Usage approaching Limits is a leading indicator for OOMKills, and inspecting whether it's a slow climb (leak) or a sudden spike (workload change) shapes the fix.

Network IO

This chart relies on the OTel metric k8s.pod.network.io from the kubeletstats receiver: a cumulative Sum in bytes with attributes direction and interface, shown as a per-second rate and aggregated across the Deployment's pods.
One line per direction :: interface combination, showing transmit/receive throughput across all pods of the Deployment.
Use this to detect whether the Deployment is the source of unusual network load on a node: sudden throughput spikes, sustained saturation near the underlying NIC's rated bandwidth, or a discontinuity in the receive-vs-transmit pattern that doesn't track an explained workload change are the signals worth investigating. "No Data" means none of the pods are reporting per-pod network metrics.

Network Error Count

This chart relies on the OTel metric k8s.pod.network.errors from the kubeletstats receiver: a cumulative Sum with attributes direction and interface, shown as a per-second increase and aggregated across the Deployment's pods.
One line per direction :: interface combination, sourced from the kubelet's per-pod-interface error counters.
Sustained non-zero values warrant attention: common causes are misconfigured CNI plugins, MTU mismatches, or faulty NICs on the underlying nodes; correlate with the Node Detail → Network Errors chart on the specific node(s) hosting the Deployment's pods.

Pod Metrics

The Pod Metrics tab breaks resource utilization down per pod across every pod in the Deployment. All charts are scoped to this Deployment (filtered by k8s.cluster.name, k8s.namespace.name, and k8s.deployment.name), grouped by k8s.pod.name (one line per pod), averaged within each step interval, and expressed as a percentage.

CPU Limit Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.cpu_limit_utilization from the kubeletstats receiver: a pod's CPU usage as a fraction of the sum of its containers' CPU limits, emitted directly as a ratio.
Plots one line per pod in the Deployment, each showing that pod's CPU usage against its CPU limit; values near 100% mean the kernel is actively throttling that pod's CPU.
Use it to pinpoint which replica is throttled: a single line hugging 100% while the rest sit low points to a hot pod or uneven load balancing, whereas all pods running high means the Deployment's limits.cpu is too low.

CPU Request Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.cpu_request_utilization from the kubeletstats receiver: a pod's CPU usage as a fraction of the sum of its containers' CPU requests.
Plots one line per pod in the Deployment, each showing usage against its CPU request; values above 100% mean the pod is using more CPU than it reserved (allowed, but a sign the request is low).
Use it to judge reservation accuracy per replica: pods consistently far below 100% are over-provisioned, pods above it are under-requested; uneven values across identical replicas usually indicate skewed traffic rather than a sizing problem.

Memory Limit Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.memory_limit_utilization from the kubeletstats receiver: a pod's memory usage as a fraction of the sum of its containers' memory limits.
Plots one line per pod in the Deployment, each showing that pod's memory usage against its memory limit; a line at or near 100% is a pod on the verge of an OOMKill.
Use it to isolate the replica at risk: a steady per-pod climb is a memory-leak signature confined to that pod; raise limits.memory or fix the leak rather than scaling the whole Deployment.

Memory Request Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.memory_request_utilization from the kubeletstats receiver: a pod's memory usage as a fraction of the sum of its containers' memory requests.
Plots one line per pod in the Deployment, each showing usage against its memory request; values above 100% mean the pod exceeds its reservation.
Use it to right-size requests.memory per replica and catch imbalance: pods well below 100% reserve memory they never use, while pods above it risk eviction first under node memory pressure.

FileSystem Usage Percentage By Pod Name

This chart is derived from two kubeletstats metrics: k8s.pod.filesystem.usage (bytes used) divided by k8s.pod.filesystem.capacity (total bytes); only the computed ratio is plotted, not the raw metrics.
Plots one line per pod in the Deployment, each showing that pod's local/ephemeral filesystem fill level as a percentage of its capacity.
Watch any pod trending toward 100%: its ephemeral storage is filling (unrotated logs, cached artifacts, temp files) and writes will start failing or the pod may be evicted; a single climbing line isolates the culprit replica.

Next steps

Kubernetes Monitoring: back to the Kubernetes Monitoring overview.
Setup Kubernetes Metrics: configure the receivers this page's metrics depend on.
Pods and Namespaces: drill into individual replicas or roll up to the namespace.