k8s docker환경에서의 cpu request, limit

요약

kubernetes pod requests.cpu와 limits.cpu가 사용하는 docker의 설정이 다르다.
cpu limit을 치는 상황에는 app container의 cpu가 throttle되어 requested는 보장하나, 실제 퍼포먼스가 저하될 수 있다.
서비스의 퍼포먼스가 영향받지 않으려면 liveness health check를 쓰는 것을 권고한다.

pod의 request/limit of cpu

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run

CPU 리소스는 절대적인 수치. CPU 리소스 0.1이라는 수치는 single core, dual core, 48 core 머신에서 모두 동등한 양의 리소스를 의미.
어떻게 pod 리소스 제한은 동작하는가?
requests와 limit이 사용하는 docker 옵션이 다르다.

• requests.cpu

    docker run —cpu-shares=max(requests.cpu*1024, 2)

• limits.cpu
  limits.cpu * 100ms 가 컨테이너가 100ms 이내에 최대로 사용할 수 있는 cpu time으로 이를 넘어서는 안됨. docker 옵션의 —cpus (—cpu-period, —cpu-quota)
  기본 quota period: 100ms이고 최소 resolution은 1ms

A Container might or might not be allowed to exceed its CPU limit for extended periods of time. However, it will not be killed for excessive CPU usage.

과도한 cpu usage로 killed 되지는 않는다.

docker의 리소스 제약사항

https://docs.docker.com/config/containers/resource_constraints/
기본적으로, 각 컨테이너는 호스트머신의 cpu cycle을 제한 없이 접근할 수 있음. (namespace에 설정이 있는 경우 적용됨)

• 현재 dkosv3에서 설치되는 Docker version은 17.03.2-ce 이므로 1.13보다 높다.

• docker 1.13이후에는 realtime scheduler를 사용할 수 있다.

    docker run -it --cpus=".5" ubuntu /bin/bash

만약 1 cpu를 가지고 있을 때, 위와 같이 설정 되어있는 경우 매 초 최대 CPU의 50%를 보장한다. (guarantees the container at most 50% of the CPU every second).

cpus와 cpu-perios, cpu-quota의 관계는 아래와 같다. 

-—cpus="1.5" == -—cpu-period="100000" -—cpu-quota="150000"

--cpu-period 디폴트는 100micro seconds이고, 1.13이후로는 --cpus를 쓰라고 되어있다.

 

앞서 설명한 것처럼 requests.cpu는 cpu-shares옵션을 쓰게 되는데, cpu-share 옵션은 구체적인 cpu접근을 보장하거나 예약하는 옵션은 아니다. 가용 cpu cycle에서 컨테이너 cpu 리소스 우선순위를 잡아주는 것. 기본값은 1024이고, 2048로 설정해주면 2배의 가중치를 가져간다.

docker run —-cpu-shares=max(requests.cpu*1024, 2)

cpu-share의 이해를 위해 예를 들어보자.

1 core 이고, cpus=0(unlimited)이라고 가정 했을 때

docker run —cpu-share=1024 # 1 
docker run —cpu-share=512 # 2 
docker run —cpu-share=512 # 3

이렇게 3개의 컨테이너를 띄우면 1번 컨테이너가 cpu의 50%의 cpu time을 가져간다.

여기에 아래와 같이 cpu-share=1024인 4번째 컨테이너를 하나 더 추가하면, 1번 컨테이너는 33%의 cpu time을 가져간다.

docker run —cpu-share=1024 # 4

resource requests and limit에 관한 kubernetes best practice

https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-resource-requests-and-limits

app이 특별히 multicore에 이롭게 디자인된 것이 아니라면 cpu request를 1 이하로 설정하고, replicas를 늘리는 것이 flexible하고 reliable하다.
cpu limit 상태가 되면, cpu는 compressible 리소스가 된다. app이 cpu limit을 치면 kubernetes는 app container를 throttling하기 시작한다. cpu가 인위적으로 제한되고, 앱이 잠재적으로 더 나쁜 퍼포먼스를 낼 수 있다. 하지만 죽이지는 않음. 퍼포먼스에 영향받지 않으려면 liveness health check를 써라.

만약 어떤 노드의 컨테이너의 limit의 합이 실제 리소스 가용량보다 높은 경우, kubernetes는 overcommitted state로 들어가게 된다. cpu는 compressed되기 때문에, k8s는 container의 requested cpu를 보장하지만 나머지를 throttle함. 메모리는 compressed 될 수 없기 때문에, k8s는 node가 oom상태 일때 어떤 컨테이너를 종료시킬지 결정해야함. 이 때 사용되는 것이 pod's priority(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-api.md) 이고, 가장 낮은 우선순위를 가진 pod를 종료시킨다.