DevOps/Kubernetes

Kubernetes QoS(Qualitu Of Service)와 Pod Eviction의 상관 관계

Jen'_' 2023. 3. 25. 18:52
반응형

QoS(Qualitu Of Service) 클래스 타입

Kubernetes는 노드에 리소스가 부족할 때 Pod의 우선순위에 따라서 Pod를 Eviction 한다.

이때 Pod의 우선순위는 QoS 클래스 타입에 따라 정해진다.

QoS 클래스 타입에는 아래 3가지가 있다.

  1. Guaranteed: Resources 항목에서 Request Limit의 값이 완전히 동일한 경우
  2. Burstable: Guaranteed, BestEffort에 속하지 않는 모든 경우 ( e.g. Resources 항목에서 Limit Request보다 클 경우)
  3. BestEffort: Resources 항목을 아예 사용하지 않을 경우

 

노드에  리소스가 부족해지면 우선순위가 가장 낮은 Pod나 프로세스가 먼저 종료된다.

우선순위는 Guaranteed > Burstable > BestEffort 순서이다.

 

BestEffort QoS Pod는 항상 kubelet의 Eviction 대상이 된다.
Burstable QoS Pod의 경우에는 CPU, Memory 둘 다 Request 값을 설정하고 실제 CPU, Memory Resource 사용량이 Request 값보다 작은 경우에는 kubelet의 Eviction 대상에서 벗어나지만, 그 외의 경우에는 kubelet의 Eviction 대상이 된다.

Guaranteed QoS Pod는 언제나 kubelet의 Eviction 대상에서 벗어난다.

 

Resources를 정의할 때 Request Limit을 너무 차이가 크게 설정하면 Pod Eviction 대상이 되기 때문에 Request와 Limit를 비슷하게 설정하거나 동일하게 설정하는 것을 추천한다.

Kubernetes Scheduler는 Request 값을 기준으로 Pod Scheduling을 수행하기 때문에 kubelet은 CPU, Memory Resource 부족시 Request 값보다 실제로 더 많이 리소스를 사용하는 Pod를 Eviction 대상으로 선정하기 때문이다.

 

쿠버네티스에서는 CPU를 압축 가능한(compressible) 리소스라고 부릅니다.
Request보다 더 많은 CPU를 사용해 CPU경합이 발생하더라도 컨테이너의 CPU 사용량을 스로틀(throttle)을 통해 억제할 수 있기 때문입니다.

이와 반대로 Memory나 Storage는 압축 불가능한(incompressible) 리소스라고 부릅니다.
컨테이너 간 Memory 사용의 경합이 발생하면 우선순위가 낮은 컨테이너의 프로세스가 먼저 종료되기 때문입니다.

 

Pod Qos Class 확인 방법

kubectl get pod {POD_NAME} -o jsonpath='{ .status.qosClass}{"\n"}'

 

 

 

참고

https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

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

https://no-easy-dev.tistory.com/entry/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-Pod-%EC%9E%90%EC%9B%90%EA%B4%80%EB%A6%AC-QoS

https://ssup2.github.io/theory_analysis/Kubernetes_Pod_Eviction/

 

 

 

반응형