As Kubernetes clusters mature, managing resource contention at the kernel level becomes critical. Modern container runtimes rely on Cgroup v2 to enforce limits, but standard metrics often fail to capture the hidden latency caused by memory pressure. Pressure Stall Information provides a direct view into the duration of stalled execution caused by resource starvation.

Understanding PSI Metrics in Cgroup v2

The kernel tracks stalled time across different resource classes, such as memory, I/O, and CPU. By inspecting the memory.pressure file within a pod’s specific Cgroup directory on the host node, engineers can quantify exactly how long processes were unable to progress due to reclaim activity or swapping.

cat /sys/fs/cgroup/kubepods.slice/kubepods-pod<ID>.slice/memory.pressure

• some indicates the percentage of time at least one task was stalled
• full indicates the percentage of time all non-idle tasks were stalled
• avg10, avg60, and avg300 represent the moving averages over specific windows

Operationalizing PSI for Proactive Scaling

Integrating PSI data into your observability stack allows for trigger-based autoscaling before OOMKills occur. By monitoring the full stall metric, you can identify pods that are genuinely hitting memory hard limits, distinguishing them from pods that simply have high resident set sizes but are not currently performance-degraded.

Leveraging these internals enables a shift from reactive troubleshooting to predictive resource optimization, ensuring high-traffic workloads maintain sub-millisecond latency under sustained memory load.