Skip to main content
daily-triage/cgroup-v2-page-cache-accounting-triggers-conflicting-oomkilled-alerts.md
Daily Triage Briefing

Cgroup v2 Page Cache Accounting Triggers Conflicting OOMKilled Alerts in a Kubernetes Checkout Service

Impact Summary

A fictional Kubernetes triage exercise in which a checkout-service pod is OOMKilled while node-level dashboards report normal memory, and the reveal traces the contradiction to cgroup v2 page cache accounting.

SeveritySEV-3
StatusResolved simulation
PlatformKubernetes & Containers
Incident TypeKubernetes & Containers
Published5 Aug 2026
Technologies Involved
Kubernetes

Simulation Label

Fictional simulation. This exercise is a bounded, invented training scenario for practising operational reasoning. No real organisation, incident, telemetry, credentials or production identifiers are involved or implied.

Operational Summary

Root Cause

Cgroup v2 memory.max accounting counted an unbounded logging sidecar's page cache against the checkout-service container's memory limit, triggering a cgroup-level OOMKill despite low application RSS and ample node-wide memory, producing two apparently contradictory alerts.

Detection Method

Evidence-led guided investigation

Current Status

Resolved simulation

Affected Services

Kubernetes

Incident Overview

Meridian Foods, a fictional grocery retailer, runs its checkout-service deployment on a fictional Kubernetes cluster. The scenario assumes Kubernetes 1.28 with the kubelet cgroup driver set to systemd and cgroup v2 enabled on all nodes u2014 an environmental assumption stated explicitly because the reveal depends on it.

During a routine evening peak, on-call engineer Priya notices two alerts firing within the same three-minute window: one reporting the checkout-service pods as OOMKilled and restarting repeatedly, and a second reporting that node-level memory pressure is normal. The alerts appear to contradict each other, and Priya must decide whether to raise container memory limits, restart infrastructure, or investigate further before changing anything.

Investigation Options

Review the available operational moves and select the best immediate action.

A

Increase the checkout-service container memory limit until OOMKilled events stop.

B

Inspect cgroup memory.stat and container_memory_working_set_bytes versus container_memory_rss to confirm whether sidecar page cache is being counted against the memory limit before changing any limits.

C

Restart the node's kubelet service to clear the alert state.

D

Disable the log-tailing sidecar entirely in production without further investigation.

Tags:Kubernetes