조금 평범한 개발 이야기

k8s 리소스 제한 하기 본문

개발/docker & k8s

k8s 리소스 제한 하기

jogeum 2021. 7. 24. 02:05

리소스 오버커밋

k8s에 파드를 띄울때 리소스 제한을 설정하지 않으면 파드는 워커 vm 에 있는 cpu, memory 를 서로 공유 하게 됩니다.

즉 파드 하나가 worker 의 모든 자원을 사용할 수도 있다는 이야기 입니다.

일반적인 경우에는 문제가 없으나 일순간 파드들이 동시에 많은 cpu, memory 자원을 사용하려고 할때 문제가 발생 됩니다.

CPU

CPU 의 경우 워커 vm 이 가지는 최대 Core 를 넘어서는 요청이 들어오면 오버커밋 상황이 되며 기대하는 응답 보다 느리게 동작이 됩니다. 이 경우에는 초과되는 요청을 한 파드가 퇴거(evict) 대상으로 지정되지 않으며 단지 워커가 전체적으로 느리게 동작이 될 뿐입니다.

MEMORY

메모리의 경우 이와 다르게 최대 메모리 를 넘어서는 오버커밋 상황이 되면 OOM 이 발생한 파드나 퇴거 대상인 파드들 부터 순차적으로 종료 시킵니다. 경우에 따라 워커 자체가 멈추거나 응답이 없는 경우도 있습니다.

SPRING CLOUD 를 사용 중이라면 eureka 가 자가 보존 모드가 활성화 되어 있어 하트비트를 수신하지 않는 서비스도 리스트에 유지하기 때문에 이를 참조하고 있는 zuul, hystrix, feign 에서는 아직 유효한 서비스로 보고 요청 전달을 시도 합니다.

때문에 유효하지 않는 서비스에 전달된 요청의 응답이 재시도로 지연되거나 실패할 수도 있습니다. 내부적으로 hystrix 의 서킷이 열리거나 eureka 에서 응답없는 서비스가 제거되기 전까지는 이런 상황이 지속될 수 있습니다.


파드 리소스 제한 하기

오버커밋 상황을 미연에 방지하기 위해서는 디플로이먼트를 설정 할때 가능하면 리소스 제한을 정의하는게 좋습니다.

리소스는 request, limit 로 나눠지는데 request 는 파드가 사용할 수 있는 리소스의 최소값이고 limit 는 파드 최대값을 의미 합니다.

resources:
  requests:
    cpu: 2
    memory: 2Gi
  limits:
    cpu: 2
    memory: 2Gi

파드를 생성할 때 다음 3개의 QoS 클래스 중 하나를 k8s 가 할당 합니다.

  • Guaranteed : request 와 limit 설정이 동일한 경우
  • Burstable : request 와 limit 설정이 동일하지 않은 경우
  • BestEffort : 아무 설정이 되지 않은 경우

만약 worker 가 자원이 부족해 파드를 퇴거하려 할때 BestEffort > Burstable > Guaranteed 순서로 퇴거를 진행 합니다. 그러니 가능하면 request 와 limit 설정을 동일하게 맞춰 Guaranteed QoS 상태를 유지하는게 좋습니다.


요약

  • k8s 디플로이먼트 설정을 할때 리소스 제한을 하자.
  • 리소스 제한 설정을 할때 request, limit 는 동일하게 맞추자.

참고

 

Comments