Memory QoS Is Not Resource Governance
Kubernetes Memory QoS can improve how Linux handles containers during memory pressure. That does not make memory behavior a solved platform concern.
The feature provides enforcement mechanisms. Reliable operation still depends on consistent workload classification, realistic resource declarations, node policy, and clear ownership of performance trade-offs.
What matters
- Workload classes: Platform teams need defined service tiers. Not every workload deserves the same protection or throttling behavior.
- Request quality: Memory protection derived from inaccurate requests preserves bad assumptions and can reduce capacity available to better-sized workloads.
- Node-wide policy: Reservation settings affect every Pod on a node. Mixed workload pools therefore require deliberate placement and compatible expectations.
- Pressure visibility: Teams must observe throttling, reclaim, out-of-memory events, and application latency together. A healthy Pod phase is insufficient evidence.
- Explicit ownership: The platform owns safe defaults and node configuration. Service teams own sizing, load behavior, and application-level recovery.
Recommendation
Adopt Memory QoS as part of a small set of documented workload classes, not as an isolated kubelet switch. Validate each class under realistic contention and make its guarantees and failure modes visible to service owners.
Kernel controls can make memory pressure more predictable. Governance determines whether that predictability is useful.