lander.log

K8s MemoryQoS

4 min read

K8s MemoryQoS

Referenced by

정의 (Definition)

MemoryQoS 는 cgroup v2 메모리 컨트롤러를 이용해, kubelet이 컨테이너의 request/limit를 커널 수준의 보호/완충 파라미터(memory.min, memory.high 등)로 매핑 하려는 기능이며, QoS 클래스 자체를 대체하는 메커니즘은 아닙니다.

문제가 되는 배경 (Problem Context)

MemoryQoS가 꺼진 환경에서는 “메모리 request”가 커널의 하한 보호로 자동 연결되지 않을 수 있습니다. 즉, request를 줬더라도 노드 압박 시 reclaim이 발생해 성능이 흔들릴 수 있고, 결국 eviction/OOM으로 이어질 수 있습니다.

핵심 메커니즘 (How it Works)

MemoryQoS를 활성화하면 kubelet이 대략 다음 의도를 커널에 전달합니다.

  • memory.min: 컨테이너의 메모리 request를 기반으로 “회수되면 안 되는 최소치”를 설정
  • memory.high: 컨테이너가 limit 근처로 가면 “강제 종료 전에 완충(throttling)”을 시도

이 기능은 feature gate로 제어됩니다(환경에 따라 사용 가능 여부가 달라질 수 있음).

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: MemoryQoS는 “메모리 request/limit을 커널 메커니즘으로 더 직접 연결”하려는 시도입니다.
  • 비보장: 기능이 항상 안정적으로 동작한다거나(특히 livelock), 모든 플랫폼에서 사용 가능하다고 보장할 수는 없습니다.

비유 (Analogy)

기존 request/limit이 “장부상의 약속”에 가까웠다면, MemoryQoS는 그 약속을 커널에게 규칙(하한/완충)으로 직접 전달 하려는 장치입니다.

실무적 함의 (Operational Implications)

  • cgroup v2 환경에서 “request가 커널 보호로 연결되는지”는 관찰로 확인해야 합니다. (관찰: Memory ReqLim 실제 컨테이너 설정)
  • 관리형 서비스(EKS 등)에서는 알파 기능/feature gate 변경이 제한될 수 있으므로, 사용 가능 여부를 먼저 확인해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • MemoryQoS는 “OOM을 없애는 기능”이 아닙니다. 상한(limit)과 노드 압박은 여전히 존재합니다.
  • request를 줬다고 해서 자동으로 memory.min이 설정된다고 가정하면, 환경에 따라 틀릴 수 있습니다.

References

Recent Posts