[k8s] Pod의 품질과 Guaranteed Class Pod
쿠버네티스는 디스크나 메모리가 부족하면 Pod를 죽여서라도 전체적인 안정성을 유지하려는 성질이 있다.
근데 여기에도 Pod를 죽이는 우선순위가 존재한다. 이 우선순위 값을 QoS라고 하며, "Guaranteed" QoS를 가진 Pod를 가장 마지막에 죽인다.
그래서 가능하다면 Guaranteed 레벨로 Pod를 정의하는 것이 best practice에 가깝다.
2가지 제한 단위: request와 limit
쿠버에서 리소스 관리가 어지러운 이유 중 하나는, 소프트 리밋인 request와 하드리빗인 limit이 병존한다는 것이다. request는 리소스 분산의 단위가 되며, 초과해도 컨테이너를 죽이지 않는다. 그리고 limit은 초과할 경우 컨테이너를 죽인다. request보다 많은 리소스를 쓰는 것을 오버커밋(overcommit)이라 부른다.
이건 리소스 효율성을 끌어올리기 위한 방법이기도 하지만, 이 때문에 스케줄링이 복잡해지는 부분도 있다.
QoS의 종류
QoS 레벨에는 총 3가지가 있다. 모든 Pod는 다음 중 하나의 레벨을 할당받는다.
- Guaranteed: 최상위의 보장 레벨
- Burstable: 중간 레벨
- BestEffort: 가장 낮은 수준의 보장 레벨 (default)
쿠버는 자원이 부족해지면 아래에서부터 Pod를 죽여서 자원을 회수하려고 노력한다.
BestEffort를 먼저 죽이고, Burstable을 죽이고, 마지막에 Guaranteed를 죽인다.
단, 예외적인 상황은 있을 수 있다. Burstable과 BestEffort는 스코어에 따라 순서가 역전될 수도 있다.
Guaranteed를 받는법
조건이 좀 빡빡하다. 메모리와 CPU의 사용량이 완벽하게 통제되어야 한다.
- 유효한 memory limit/request를 갖고, limit=request여야 한다.
- 유효한 cpu limit/request를 갖고, limit=request여야 한다.
Burstable를 받는법
비교적 단순하다. request만 지정되면 Burstable을 받는다. limit은 없어도 된다.
참조
https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
https://blog.naver.com/alice_k106/221676471427