[Kubernetes] Pod Resource 에 관한 정리 - CPU

1. Request / Limit

1-1. 정의

• Pod는 배포가 될때 Linux 의 cgroups를 바탕으로 Pod의 여러가지 대상 (CPU / Memory / humanpage / ephemeral ... etc) 에 대한 리소스 사용량을 지정할 수 있다.
• 주로 CPU/Memory 를 컨트롤 하며, 자원을 효율적으로 컨트롤 할 수 있다.

 

1-2. Request

• kubernetes (이하 k8s)는 Pod를 스케쥴링할 때 CPU의 Request 를 고려하여 적절한 Node에 배치하도록 도와준다.
• CPU Request는 해당 Pod가 정상적으로 실행되기 위해 필요한 최소한의 CPU 자원을 정의하며, k8s는 이 값을 바탕으로 자원을 할당한다.
• 또한 Node의 자원이 부족할 경우 CFS(Completely Fair Scheduler)는 CPU Request을 사용하여 CPU 시간을 비례적으로 적용한다.
  • Request 가 더 클 수록 CPU Share 계산에 따라 더 큰 우선순위를 가지게 된다.
  • 다만 이경우에는 뒤에 설명할 QOS(Quality of Service)에 따라 우선순위가 달라질 수 있다.
    • Guaranteed
    • Burstable
    • BestEffort

 

1-3. Limit

• k8s의 Pod는 CPU/Memory의 Limit에 따라 Pod가 사용할 수 있는 자원에 제한을 건다.
• CPU Limit의 경우 Limit를 지정한 모든 컨테이너의 CFS 할당량 및 기간 구성 값에 의해 적용하여 CPU 시간에 대한 상한선을 정의 한다.
  • period(이하 주기) 마다 리눅스 커널은 quota(제한)이 초과 되었는지 확인 하고 초과 되었다면 cgroup을 재개하지 않고 대기한다.이를 throttling(이하 스로틀링) 이라고 부른다.

---

2. QOS

2-1. 종류

• QOS의 경우 CPU Resource 정의 방식에 따라 3가지 종류로 나누어지게 된다.
• Guaranteed ( request = limit )
  • CPU의 Request와 Limit가 동일할 경우
  • 반드시 해당 크기만큼 사용하도록 보장이 된다.
  • CPU MODE (none, static)에 따라 보장 방식이 다르다
    • none : CPU 시간의 비율 -> CPU Shares 기반으로 작동
    • static : 물리 코어의 수
  • limit 초과 사용 시 초과된 만큼 스로틀링이 발생 한다.
• Burstable ( request < limit 또는 request > 0 || limit = 0 )
  • CPU의 Request는 정의되어 있으나, Limit가 더 크거나 생략된 경우
  • Request 기준으로 최소 자원이 예약되며, 노드에 여유 자원이 있을 경우 limit 또는 그 이상까지 CPU를 사용 가능
  • Limit가 설정되어 있다면 초과 사용 시 스로틀링이 발생함
  • Limit가 없을 경우, Burst 사용이 가능하며 스로틀링은 발생하지 않음
  • Guaranteed보다는 우선순위가 낮아, 자원 부족 시 성능저하(slowdown)이 발생할 수 있음
• BestEffort ( request = 0 && limit = 0 )
  • CPU의 request와 limit가 모두 설정되지 않은 경우
  • Kubernetes 스케줄러가 리소스를 보장하지 않으며,
    다른 파드의 리소스 사용 상황에 따라 CPU를 가장 나중에 할당받음
  • cpu.shares 값이 2로 매우 낮게 설정되어 있어,
    다른 파드가 리소스를 점유하고 있을 경우 거의 CPU를 사용하지 못함
  • 자원이 여유 있을 때만 사용 가능하며, 우선순위가 가장 낮음
  • CPU 뿐 아니라 Memory QoS 측면에서도 OOM(Out of Memory) 시 가장 먼저 종료 대상이 됨
  • 테스트용, 비중요 작업용, sidecar 중 일부 경량 작업에만 사용하는 것이 일반적

---

•  

예시

• 4core 노드에서 system(kubelet, systemd 등)이 0.5core를 사용 중인 상황에서, 다음과 같은 3개의 파드가 스케줄링되었다.
  • Pod1 → cpu request: 500m (Burstable QoS)
  • Pod2 → cpu request: 400m (Burstable QoS)
  • Pod3 → cpu request: 1.5 / limit: 1.5 (Guaranteed QoS)
    
    
  ex1)  Pod1이 CPU time 1800ms, Pod2가 1100ms, Pod3가 1000ms를 사용한 경우: 
  • Pod1과 Pod2는 Burstable QoS로 동작하며, 사용 가능한 CPU 자원 중에서 request 값을 기준으로 계산된 cpu.shares 비율에 따라 자원을 분배받는다.
  • Pod1과 Pod2는 CPU limit가 설정되어 있지 않기 때문에, 사용량이 많더라도 limit 기반의 스로틀링은 발생하지 않는다
  • 다만 사용하려는 CPU 양이 cpu.shares로 할당된 비율을 초과할 경우, CFS 스케줄러에 의해 처리량이 제한되며 지연이 발생할 수 있다.
  • 참고로, Guaranteed 파드가 요청한 리소스를 실제로 사용하지 않더라도, 해당 자원을 다른 파드가 사용할 수 있는지 여부는 CPU Manager의 정책에 따라 달라진다.
    • 예를 들어, static 정책일 경우 Guaranteed 파드에 고정된 코어는 다른 파드가 절대 사용할 수 없는 전용 코어로 설정되며,
    • 반면 none 정책일 경우에는 남은 리소스를 Burstable이나 BestEffort 파드가 공유하여 사용할 수 있다.

예시1

 

 

ex2)  Pod1이 CPU time 1000ms, Pod2가 800ms, Pod3가 2000ms를 사용한 경우:

 

• Pod3는 1.5core limit으로 인해 2000ms 중 1500ms까지만 사용하고, 나머지 500ms는 cgroup에 의해 스로틀링 됨
• Pod1, Pod2는 요청량보다 조금 더 적은 CPU만 사용하려 했기 때문에, 남은 2000ms 내에서 모두 충족됨
• 이 경우는 전체적으로 slowdown 없이 모든 파드가 요청량을 충족했고,
  단지 Pod3만 limit에 의해 강제로 제어(throttling)된 케이스

예시2

 

 

---

 

참고

https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Pod Quality of Service Classes

https://kubernetes.io/ko/docs/tasks/configure-pod-container/assign-cpu-resource/

컨테이너 및 파드 CPU 리소스 할당

 

https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/

파드 및 컨테이너 리소스 관리

https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/

Kubernetes CPU limits and requests: A deep dive | Datadog

https://www.datadoghq.com/blog/rightsize-kubernetes-workloads/#the-kubernetes-scheduler

Practical tips for rightsizing your Kubernetes workloads | Datadog