[EKS] POD 자원관리 (QoS) 및 OOM 킬러 우선 순위

우선적으로 QoS를 이해할려면 CPU Manager를 이해해야한다.

 

간단하게 설명하면 CPU Manager는 프로세스 실행을 위한 CPU리소스 할당을 처리 하고 전체 CPU 사용률을 최대화하는 정책이며 포드에 CPU Affinity를 설정할 수 있도록 지원하고 있어 cpu or memory를 할당할 수 있게 한다.

 

여기서 CPU Manager의 정책은 2가지로 아래와 같다.

• none: CPU 선호도 체계를 명시적으로 활성화
• static: 특정 리소스 특성을 가진 팟(Pod)이 노드에서 증가된 CPU 선호도 및 독점성을 부여받을 수 있습니다.

cpu or memory가 갑자기 급증하는 상황, 예상치 못한 상황이 발생할 때, 레이턴시가 갑자기 급증할때 등 많은 문제가 생긴다 이러한 문제를 해결하기 위해 static 정책을 사용하며 static은 QoS 클래스를 지원한다.

 

QoS클래스의 종류는 BestEffort, Burstable, Guaranteed 3가지가 존재하며

Pod의 Limit와 Request에 따라서 QoS 클래스를 지정합니다.

 

BestEffort

#besteffort.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-besteffort-pod
spec:
  containers:
  - name: nginx-besteffort-pod
    image: nginx:latest

위와 같이 Limit와 Request를 명시하지 않고 생성하는 모습이며

 

limit을 설정하지 않아 노드에 남는 자원이 있다면 제한 없이 모든 자원을 사용할 수 있지만

request를 설정하지 않아 확실하게 보장받을 수 있는 자원은 존재하지 않습니다.

 

즉, 때에 따라서는 노드에 존재하는 모든 자원을 사용할 수도 있지만, 자원을 전혀 사용하지 못할 수도 있습니다.

 

kubectl describe pod nginx-besteffort-pod | grep QoS

 

Guaranteed

apiVersion: v1
kind: Pod
metadata:
  name: nginx-guaranteed-pod
spec:
  containers:
  - name: nginx-guaranteed-pod
    image: nginx:latest
    resources:
      limits:
        memory: "100Mi"
        cpu: "1000m"
      requests:
        memory: "100Mi"
        cpu: "1000m"

위와 같이 Limit과 Request를 동일하게 할당해주는 방식으로 리소스의 오버커밋이 허용되지 않아 안정적으로 리소스 사용을 보장받을 수 있다.

(만약 멀티 컨테이너너 형식이라면 모든 컨테이너의 Request와 limit이 동일해야 Guaranteed로 분류되게 됩니다. )

 

Burstable

apiVersion: v1
kind: Pod
metadata:
  name: nginx-burstable-pod
spec:
  containers:
  - name: nginx-burstable-pod
    image: nginx:latest
    resources:
      limits:
        memory: "200Mi"
        cpu: "2000m"
      requests:
        memory: "100Mi"
        cpu: "1000m"

위와 같이 resources 항목에서 limits가 requests보다 클 경우 Burstable로 분류되며

Guaranteed와 BestEffort에 속하지 않는 모든 Pod는 Burstable로 분류된다.

 

-------------------------------

 

Out of Resource

 

쿠버네티스는 효율적인 자원 활용을 위해 오버커밋을 지원하는데 만약 어떤 파드가 리소스를 Limit보다 덜 사용하고 있다면 다른 포드가 리소스를 더 많이 사용할 수 있는 것이 오버커밋의 핵심이다. 

 

예를 들어, 아래의 그림처럼 위에 파드가 리소스를 전부 사용하지 않아 아래 파드가 위에 파드의 리소스를 더 많이 사용하고 있는 상황을 가정해보자.

 

이 때, 위에 파드가 자신의 requests만큼 리소스를 사용하려고 시도한다면  위 아래 파드들은 자원 사용에 있어 충돌이 발생하고, 둘 중 하나는 리소스를 원하는 만큼 사용하지 못하는 상황에 직면하게 된다.

이처럼 파드 간에 리소스 경합이 발생하거나, 노드의 리소스 자체가 부족한 현상을 Out of Resource라고 부른다.

여기서 구분지어야하는 부분이 쿠버네티스에서는 리소스 종류를 압축 가능한 리소스와 압축이 불가능한 리소스로 분류한다.

 

• 압축 불가능한 (incompressible) 리소스 : 메모리, 스토리지 등
• 압축 가능한 (compressible) 리소스 : CPU

 

압축 가능한 리소스인 CPU의 오버커밋 때문에 포드 간의 리소스 경합이 발생할 경우, 포드 내부의 프로세스의 CPU 사이클에 쓰로틀이 발생할 뿐 애플리케이션에 큰 문제가 발생하지는 않는다.

 

하지만 압축 불가능한 리소스인 메모리나 스토리지의 경우에는 압축이 불가능하기 때문에 Out of Resource에 직면하며

메모리가 오버커밋으로 인한 자원 경합이 발생할 경우 포드 내부의 프로세스에 OOM (Out of Memory) 가 발생할 수도 있다.

 

 

Out of Resource를 해결주는 OOM 킬러

 

쿠버네티스에는 Out of Resource로 인해 노드 자체가 Fail하는 것을 방지하기 위해서 Hard Eviction Threshold 라는 옵션을 기본적으로 사용하고 있다.

 

쉽게 풀어서 이야기하자면, "현재 노드의 가용 리소스가 Hard Eviction Threshold보다 적다면 반드시 무엇인가 조치를 취해야만 한다" 라고 이해하면 된다. 예를 들어 kubelet에 기본적으로 설정되어 있는 메모리의 Hard Eviction Threshold는 100Mi이며, 해당 노드에서 할당 가능한 메모리 총량에서 100Mi 만큼은 애초에 제외되어 있다.

 

 

kubelet은 node의 resource 상황을 표현하기 위해, 하나 이상의 eviction signal을 node에 매핑하는 Node Condition을 제공하는데

kubectl describe nodes {node_name} | grep -A9 Conditions

MemoryPressure는 default로 노드의 가용 메모리가 100Mi 이하일 때 발생하도록 kubelet에 설정돼 있습니다.

 

만약 노드의 가용 메모리가 100Mi 보다 낮아지면 노드의 상태 정보 (Conditions) 에서 MemoryPressure 의 값이 true로 설정되며, 

해당 노드는 스케줄링 대상에서 제외되어 포드가 더 이상 할당되지 않는다.

OOM을 유발한 포드는 Eviction API을 통해 종료되며, 해당 포드가 레플리카셋 등의 컨트롤러에 의해 생성되었다면 다른 노드로 옮겨가게 된다.

또한 해당 노드에서 실행 중이던 모든 Pod에 대해 순위를 매긴 다음, 가장 우선순위가 낮은 Pod를 다른 노드로 퇴거(Evict)시키게 됩니다.

 

kubelet에는 다음과 같은 기본 강제 퇴거 임계값이 있습니다.

• memory.available<100Mi
• nodefs.available<10%
• imagefs.available<15%
• nodefs.inodesFree<5%(리눅스 노드)

nodefs : dead pod들과 그 pod에 속한 container들을 삭제함

imagefs : 사용되지 않는 image들을 삭제함

 

이때 Pod의 우선순위는 QoS 클래스 및 메모리 사용량에 따라 정렬되어 매겨지고 우선 순위는 아래와 같다.

 

Guaranteed > Burstable > BestEffort

Burstable과 BestEffort 간에는 메모리의 사용량에 따라 우선순위가 바뀔 수 있다.

 

+추가

리소스 쿼터 (ResourceQuota) 

오브젝트로 정의되며 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다.

 

리밋레인지 (Limit Range)

하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책

 

 

 

참조

https://m.blog.naver.com/PostView.naver?blogId=alice_k106&logNo=221676471427&targetKeyword=&targetRecommendationCode=1 

187. [Kubernetes] 메모리와 스토리지의 Out of Resource : OOM Killer과 포드의 우선순위에 대하여

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

쿠버네티스 | Pod 자원관리 (QoS)