Kubernetes - Pod - Qos Classes

Qos Classes

Node에 자원이 있고 Node위에 Pod가 3개 만들어져서 균등하게 자원을 사용하고 있다고 가정해보자.
이 상태에서 Pod1이 추가적인 자원을 더 사용해야 하는 상황이 발생했다.

문제

Node에는 추가적으로 할당받을 수 있는 자원이 없기 때문에 Node1이 Resource 부족으로 에러가 발생하고 다운이 되야 할까 아니면 Pod2나 Pod3에 하나를 다운시키고 Pod1에 필요한 만큼 자원을 지원해야 할까?

쿠버네티스에서는 App의 중요도에 따라 자원을 관리할 수 있도록 3가지 단계로 Qos Classes를 지원해주고 있다.
지금 이 상태에서는 BestEffort가 부여된 Pod가 가장 먼저 다운이 되서 자원이 반환이 되고 Pod1은 필요한 양의 자원을 사용할 수 있게 된다.

만약 Node에 어느정도 자원이 남아있지만 Pod2에서 그보다 많은 자원을 요구하는 상황이 발생했다면 Burstable가 부여된 Pod가 다음으로 다운이 되면서 자원이 회수된다.

Guaranteed가 부여된 Pod가 마지막까지 Pod를 안정적으로 유지시켜 줄 수 있다.

Qos는 특정한 설정이 있는 것이 아니고

kind: Pod
spec:
  containers:
    - resources:
        requests:
          memory: 1G
          cpu: 2
        limits:
          memory: 2G
          cpu: 4

Container에 Resources 설정이 있는데 여기에 Requests와 Limits를 어떻게 설정하느냐에 따라서 결정이 된다.

Guaranteed

Pod에 여러 Container가 있다면 각각의 Container마다 Requests와 Limits가 있어야 한다.
그리고 그 안에 Memory와 Cpu가 둘 다 설정이 되어 있어야 한다.
그리고 각 Container안에 설정된 Memory와 Cpu는 Requests와 Limits가 같아야 한다.
이 규칙이 모두 맞아야 쿠버네티스는 이 Pod를 Guaranteed 클래스로 판단한다.

BestEffort

Container안에 어떠한 Requests와 Limits가 설정되지 않은 상태이다.

Burstable

각 Container마다 Request와 Limits는 설정되어 있지만 Requests의 수치가 더 작은 경우,
Requests만 설정되어 있고 Limits는 설정되지 않은 경우,
Pod에 Container가 2개인데 하나는 완벽하게 설정이 되어있지만 하나는 설정 되어 있지 않은 경우
쿠버네티스는 이 Pod를 Burstable 클래스로 판단한다.

Burstable 등급의 여러 Pod들이 있을 경우 누가 먼저 삭제 될지 판단하는 근거는 OOM Score(OutOfMemoryScore)를 통해 결정한다.
만약 Pod2의 Request 메모리가 5G, Pod3의 Request 메모리가 8G고 그 안에 돌아가고 있는 App에 실제 돌아가고 있는 메모리가 똑같이 4G라면
Pod2의 메모리 사용량은 75%, Pod3의 메모리 용량은 50%다.
OOM Score가 Pod2(75%)가 더 크기 때문에 쿠버네티스는 OOM Score가 더 큰 Pod2를 먼저 삭제한다.