lander.log

K8s CPU와 메모리 Limit 정책

5 min read

K8s CPU와 메모리 Limit 정책

Referenced by

정의 (Definition)

Kubernetes에서 CPU는 스케줄링(쓰로틀링)으로 조절 가능한 자원(compressible) 인 반면,메모리는 한계 초과 시 강제 종료(OOM)로 귀결되는 자원(non-compressible) 이기 때문에, 일반적으로 CPU limit과 메모리 limit의 운영 전략은 대칭이 아닙니다.

문제가 되는 배경 (Problem Context)

  • CPU를 많이 쓰는 워크로드는 “느려지지만 살아있는” 상태로 조절할 수 있습니다.
  • 메모리를 많이 쓰는 워크로드는 “느려지기”보다 “죽음(OOM)”으로 수렴하기 쉽습니다. 이 차이를 무시하고 동일한 방식으로 limit을 운영하면, CPU는 불필요한 쓰로틀로 지연이 증가하고, 메모리는 노드 전체 OOM/축출로 장애 반경이 커질 수 있습니다.

핵심 메커니즘 (How it Works)

  • CPU limit: CFS quota 등으로 실행 시간을 제한해 “쓰로틀링”이 발생합니다. 프로세스는 계속 실행되지만 지연이 증가할 수 있습니다.
  • 메모리 limit: cgroup의 상한을 넘으면 커널 OOM 경로로 들어가 컨테이너/프로세스가 종료될 수 있습니다.
  • QoS와 결합: request/limit 구성은 파드의 QoS 클래스를 결정하고(관련: K8s QoS 클래스), 노드 압박 시 축출 우선순위와 커널 OOM score 조정에 영향을 줍니다.

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

  • 보장: CPU는 limit을 걸면 “사용량이 제한(쓰로틀)”됩니다.
  • 보장: 메모리는 limit을 넘으면 “강제 종료(OOM)”로 이어질 수 있습니다.
  • 비보장: CPU limit이 있다고 해서 latency SLO가 만족된다고 보장할 수는 없습니다.

비유 (Analogy)

  • CPU는 “도로의 속도 제한”에 가깝습니다(느려지지만 이동은 계속).
  • 메모리는 “좌석 수 제한”에 가깝습니다(초과하면 탑승 불가/퇴장).

실무적 함의 (Operational Implications)

  • 메모리: limit을 명시해 “문제 파드 내부에서 OOM이 발생하도록” 장애를 국소화하는 전략이 자주 사용됩니다.
  • CPU: limit을 과도하게 낮게 걸면 쓰로틀로 지연이 증가할 수 있으므로, 워크로드 특성과 SLO에 따라 “limit 미설정 + request로만 회계” 같은 전략이 선택될 수 있습니다.
  • QoS 목표가 있으면 먼저 정한다: Guaranteed가 필요하면 CPU/메모리 request=limit이라는 구조적 제약을 받아들여야 합니다.

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

  • CPU limit을 “안전장치”로만 생각하면, 실제로는 쓰로틀로 tail latency를 악화시키는 경우가 있습니다.
  • 메모리 limit을 두지 않으면, 개별 파드가 노드 전체를 끌어내리는 형태로 장애가 확대될 수 있습니다.

References

Recent Posts