ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 쿠버네티스 | Pod 자원관리 (QoS)
    kubernetes 2021. 7. 25. 16:21

    이번 시간에는 쿠버네티스에서는 노드에 메모리 자원이 부족해지면 어떤 포드나 프로세스가 먼저 종료되는지(우선순위)에 대해서 알아보도록 하겠습니다.

     

    쿠버네티스에서는 지정된 Limit와 Request에 따라 내부적으로 우선순위를 계산합니다.

     

    그리고 Pod의 우선순위를 구분하기 위해 3종류의 QoS(Qualitu Of Service) 클래스를 명시적으로 Pod에 설정합니다.

     

    쿠버네티스 OOM(Out Of Memory)


    쿠버네티스의 노드에는 각종 노드의 이상 상태 정보를 의미하는 Conditions라는 값이 존재합니다.

    kubectl describe nodes {node_name} | grep -A9 Conditions

     

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

     

    MemoryPressure가 발생하면 쿠버네티스는 해당 노드에서 실행 중이던 모든 Pod에 대해 순위를 매긴 다음, 가장 우선순위가 낮은 Pod를 다른 노드로 퇴거(Evict)시키게 됩니다.

     

    뿐만 아니라 MemoryPressure가 True인 노드에는 더 이상 Pod를 할당하지 않습니다.

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

     

    QoS


    쿠버네티스에서는 Pod의 LimitRequest에 따라서 QoS 클래스를 지정합니다.

    QoS클래스의 종류는 BestEffort, Burstable, Guaranteed 3가지가 존재합니다.

     

    그렇다면 각각 QoS클래스에 대해서 알아보도록 하겠습니다.

     

    BestEffort

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

    위의 yaml 파일처럼 resources 항목을 아예 사용하지 않을 경우 BestEffort로 분류됩니다.

     

    kubectl describe pod nginx-besteffort-pod | grep QoS

     

     

    BestEffort는 limit을 설정하지 않았기 때문에 노드에 유휴 자원이 존재한다면 제한 없이 모든 자원을 사용할 수 있습니다.

    또한 request를 설정하지 않았기 때문에 보장받을 수 있는 자원은 존재하지 않습니다.

     

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

     

    Guaranteed

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

     

    위의 yaml 파일처럼 resources 항목에서 limits와 request의 값이 완전히 동일한 경우 Guaranteed로 분류됩니다.

     

    kubectl describe pod nginx-guaranteed | grep QoS

     

    Guaranteed로 분류된 Pod는 Request와 limit이 동일하여 자원의 오버커밋이 허용되지 않기 때문에 자원 사용을 안정적으로 보장받을 수 있다고 생각할 수 있습니다.

    • Guaranteed 클래스 내부에서 실행되는 프로세스들은 모두 기본 OOM 점수(oom_score_adj)가 -998로 설정됩니다.
    • Pod 내 여러 개의 컨테이너가 존재한다면 모든 컨테이너의 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: "1024Mi"
            cpu: "1000m"
          requests:
            memory: "256Mi"
            cpu: "500m"

     

    위의 yaml 파일처럼 resources 항목에서 limits가 requests보다 클 경우 Burstable로 분류됩니다.

    kubectl describe pod nginx-burstable | grep QoS

     

    간단히 생각하면 Request의 지정된 만큼 리소스를 보장받을 수 있지만, 상황에 따라서는 limit까지 사용 가능한 Pod라고 생각할 수 있습니다.

     

    또한 Guaranteed와 BestEffort에 속하지 않는 모든 Pod는 Burstable로 분류됩니다.

     

    QoS 우선순위


    처음 주제로 노드에 메모리 자원이 부족해지면 우선순위가 가장 낮은 포드나 프로세스가 먼저 종료된다고 했었습니다.

    그리고 Pod의 우선순위는 QoS 클래스 및 메모리 사용량에 따라 정렬되어 매겨진다고 했었습니다.

     

    그렇다면 QoS 클래스 간의 우선순위는 어떻게 되는지 알아보도록 하겠습니다.

     

    기본적으로 Pod의 우선순위는 Guaranteed 가 가장 높으며, 그 뒤로 Burstable 그리고 BestEffort 순입니다.

     

    하지만 위의 우선순위는 항상 절대적이지 않습니다.

     

    위에서 말한 것 저럼 Burstable, BestEffort 클래스의 Pod들은 현재 메모리를 얼마나 사용하고 있는지에 따라서 우선순위가 역전될 수도 있습니다. ( 즉 , Pod가 메모리를 많이 사용할수록 우선순위가 낮아집니다. )

    다시 한번 정리하면 우선순위는 Guaranteed > Burstable > BestEffort 순이지만 Burstable과 BestEffort 간에는 
    메모리의 사용량에 따라 우선순위가 바뀔 수 있습니다.

     

     

     

Designed by Tistory.