lander.log

K8s Kubelet 메모리 관리

4 min read

K8s Kubelet 메모리 관리

Referenced by

정의 (Definition)

Kubelet 메모리 관리는 컨테이너 런타임/cgroup 설정과 연계해 메모리 상한(limit), 노드 압박 감지(eviction), OOM 처리 가 어떻게 이어지는지에 대한 노드-로컬 동작 특성을 의미하며, “request가 곧바로 커널 보장”으로 이어진다고 가정할 수 없다는 점이 핵심입니다.

문제가 되는 배경 (Problem Context)

운영에서 자주 발생하는 오해는 “request를 줬으니 보호된다”입니다. 하지만 MemoryQoS가 비활성인 cgroup v2 환경에서는 request 기반 하한이 적용되지 않을 수 있고, 결국 eviction/OOM으로 이어질 수 있습니다.

핵심 메커니즘 (How it Works)

  • limit → memory.max: 일반적으로 컨테이너의 메모리 limit은 cgroup 상한으로 적용됩니다.
  • request 하한은 환경 의존: MemoryQoS가 꺼져 있으면 memory.min/low가 0으로 남을 수 있습니다. (관찰: Memory ReqLim 실제 컨테이너 설정)
  • 노드 압박은 eviction으로 완충: 노드가 붕괴하기 전에 kubelet eviction이 먼저 작동하도록 설계합니다. (관련: K8s 파드 축출(Eviction) 정책)
  • QoS와 결합: 압박 시 어떤 파드가 먼저 희생되는지는 QoS와 결합됩니다. (관련: K8s QoS 클래스)

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

  • 보장: limit 상한은 강제 경계로 작동합니다.
  • 비보장: request가 커널 하한으로 자동 반영된다고 보장할 수 없습니다.

비유 (Analogy)

limit은 “천장”이고, eviction은 “건물 붕괴를 막기 위한 선제적 차단기”입니다. request는 “장부상의 몫”에 가깝고, 커널이 그 몫을 반드시 지켜준다고 가정할 수 없습니다.

실무적 함의 (Operational Implications)

  • 메모리 문제를 다룰 때는 “파드 OOM”과 “노드 압박/축출”을 분리해서 관측해야 합니다.
  • EKS 같은 환경에서는 기능(예: MemoryQoS) 지원 여부가 제한될 수 있으므로, 지원 범위를 먼저 확인해야 합니다.

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

  • “MemoryQoS를 켜면 끝”이 아닙니다. 기능 성숙도/플랫폼 지원이 경계 조건입니다.
  • OOM이 났다는 사실만으로 request/limit이 잘못됐다고 단정하면, 누수/캐시/GC 같은 애플리케이션 요인을 놓칠 수 있습니다.

References

Recent Posts